Hi, everyone. I've noticed yesterday that one of our users is forking python-utils-r1 [1] to include support for Tauthon. I kinda feel bad about our users having to fork the eclass, so I started wondering about adding the support officially. However, since it's a relatively controversial topic, I'd like to gather the opinion of the community at large.
What Tauthon is? ================ Tauthon [2] (formerly called 'Python 2.8') is a 'fork of Python 2.7 with new syntax, builtins, and libraries backported from Python 3'. I haven't taken it seriously as long as it was pretending to be a continuation of CPython but since upstream grew up to use its own name and the project didn't seem to die, it might be worth thinking of for a few minutes. Technically, it's simply a fork of CPython with modifications. I haven't tested it myself but I've heard opinions that some stuff written for 2.7 works. I haven't verified that either but FWICS its sys.version states 2.8.0a0 or sth like that. I am not aware if it's possible to clearly distinguish it using some other characteristics. The project seems to be maintained by a single person, Naftali Harris, who seems to have a clear goal. It seems to have gathered a small community around it. What implementations we support currently? ========================================== Right now, we support three families of Python interpreters: CPython, PyPy and Jython. CPython is the reference C implementation of Python. We slot it per minor version which matches the way it is installed, its ABI stability and feature changes. This is the default interpreter, and the only implementation available for stable. PyPy is the fancy implementation which is written in Python. That Python is magically converted into C, and compiled. PyPy has been steadily gaining popularity due to its supposed performance benefits and extraordinary features. We support PyPy on ~arch. Historically, we have been slotting PyPy per version. However, the 'original' PyPy has been based on Python 2.7 for as long as I can remember, so I eventually dropped the slotting and just combined it into 'pypy'. Afterwards, upstream has released PyPy 3* variants that I've also combined into 'pypy3'. Jython is the half-dead implementation in Java. We have been historically somewhat supporting Jython 2.5 (versions matching CPython) but we removed it after Python 2.5 was removed. Then Jython 2.7 was in a very long, half-dead alpha stage and we never actually went beyond having a Jython package and 'experimental' support in eclass that is not really used by any packages. What levels of support can we provide? ====================================== For Tauthon, I would consider one of the following levels of support: A. provide low-level eclass support only, without USE flags or even a Tauthon package -- i.e. make it easier for others to play with it but not support it in any degree, B. eclass support + package -- make it experimental like jython2.7; let people play with it but do not add its support to packages; C. full ~arch -- let people actually use it on ~arch, and add it to PYTHON_COMPAT. As for PYTHON_COMPAT values, we could either use a versioned form, i.e. 'tauthon2_8' or just 'tauthon'. I would lean towards the latter since I don't expect us to put much effort into that project. Subjective view on Tauthon ========================== Now that all technicalities have been covered, few words of my opinion. As I said, I find the topic controversial. I wouldn't mind that much providing people ability to play with Tauthon but I wouldn't put any real effort on supporting it beyond the absolute minimum. In my opinion, this project has a number of issues and no future. 1. Python version mayhem. The idea of 'old Python with new features' has already been tested and proven wrong a lot. dev-python/future is one example where it failed -- it installs some stuff that makes Python 2 look more like Python 3 which simply breaks random assumptions in packages. Tauthon just seems like a reiteration of that, with some extra syntax and a version that pretends to be neither 2.7 nor 3.x. I can imagine this is going to cause a lot of fun results for people playing with versions, or modules, or anything in particular Plus, it's not Python 3. Even if it would be able to run some pure Python 3 code (which I don't think it can), random Python 3-only packages will still refuse to run because the version says 2. 2. No real innovation. Think of PyPy. It had to introduce a lot of fancy to actually get noticed. Tauthon just doesn't have it. Some people will use it as an excuse not to use Python 3 but that's all. If someone was to consider adding Python 3 features to a semi-serious project that needs Python 2, it is far more likely that he will use one of the backport modules -- that work with pure CPython which he has already installed, and which are easy to install e.g. in virtualenv. It is highly unlikely that someone will consider building a custom Python interpreter just to have a few syntax extras. 3. Bus factor. As I said, the project is developed by a single person. While it has a community, the problem is that it runs on quite a fragile equilibrium. If the community takes over, it is quite likely that the project will trip over with additional features that make it a moving target that breaks more stuff than it fixes. Your thoughts? [1]:https://github.com/stefantalpalaru/gentoo-overlay/blob/master/eclass/python-utils-r1.eclass [2]:https://github.com/naftaliharris/tauthon -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
