[gentoo-python] [RFC] Including (some) support for Tauthon

[Michał Górny]

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