3 ms·
About this, I have a old frontend for mame in python2 (and old pygame): https://gitlab.com/tres-14159/pyretro https://gitlab.com/tres-14159/pyretro More or le
by mdtrooper 3y ago
About this, I have a old frontend for mame in python2 (and old pygame):
https://gitlab.com/tres-14159/pyretro https://gitlab.com/tres-14159/pyretro
More or less in 2011 we made a arcade cabinet for a public social center and I was looking for a frontend for mame for public spaces (not home or private spaces), unsupervised. I did not find one. Well I thought "I am going make a new mame frontend" and yes, I made it (but now it need a lot of work for update to python3 an pygame3).
PyRetro has the next features:
- the users can not the config of frontend by the joystick or buttons. For example, in others frontends a naughty boys (or adult person) can delete games of the list or change something.
- you can manage the frontend (and other things of GNU/Linux) by webpanel. For example, there is a bad boy (or adult person) greedy playing and he does not let another person play to the arcade. You can force exit the game and return to frontend or restart all cabinet.
- it has as screensaver mode when nobody plays it.
- Tajnymag 3y agoFirstly, kudos for the project. If I may ask, as python3 came out in 2008, why did you choose python2 for the frontend in 2011?
- EDevil 3y agoIt took a long time for projects to begin using Python 3 due to it being backwards incompatible. Django 1.5 for example, the first version that had Python 3 support, came out in 2013.
- ynik 3y agopython3 in 2008 was practically unusable. It was incompatible, none of the libraries on pypi supported it; and it was extremely hard to write a code base that was compatible with both python2.6 and python3.0 at the same time, so almost none of the library authors bothered to add python3 support. In 2010, python2.7 was released, backporting a bunch of python3 features. In 2012, python3.3 was released, fixing a bunch of needless incompatibilities. This finally made it viable to support both 2.7 and 3.3 in the same code base. For the most part, the migration of the Python library ecosystem only started in/after 2012. python3 wasn't really a viable choice for application development until most libraries were ported (2014? 2015?).
- jehb 3y agoI think a lot of people forget this long, slow rollout. Even after most major libraries were ported, it took even longer to be able to count on every dependency having a Python 3 version available. RHEL didn't default to Python 3 until RHEL8 was released in 2019, for example.
- busterarm 3y agoIt's hard for me to forget just from how much bullying and grief people were given for why they hadn't switched to Python 3 yet. Some of the steps that people took were wildly uncharitable and behavior that turned me off to the Python community entirely. So much so that I had a visceral reaction to reading the GP's question about why this hadn't been done. My default reaction was to read it as accusatory rather than a genuine question. Still running some containerized 2.6 and 2.7 workloads and there are no engineering dollars to justify doing anything about it. Dead code can still be running code and can hang around for _decades_.
- at_a_remove 3y agoDue to Reasons, I am still stuck on Python 2.7. Should be an interesting jump.
- js2 3y agoI didn't start using Python 3 till 3.6 was released, so not until 2017. I've been writing Python since 1.5.2. I just didn't find Python 3 compelling/usable till 3.6. I recall f-strings being a really nice ergonomic improvement.
- phone8675309 3y agoI always appreciated them for calling it Python 3000[1] at its inception to signal to users that it was going to be very different and take a long time to fully land. It is a great example of how to do it, and I say that as somebody who used to write a lot of Perl 5 and kept wondering when Perl 6 was going to be available. [1]: https://peps.python.org/pep-3000/ https://peps.python.org/pep-3000/