[IPython-dev] [sympy] Treating Python 3 as a first-class citizen

Aaron Meurer asmeurer at gmail.com
Fri Aug 9 17:35:11 EDT 2013

On Fri, Aug 9, 2013 at 2:25 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi Ondrej,
> On Mon, Aug 5, 2013 at 9:05 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
>> Fernando, I would be very much interested what you think of this
>> issue, as you have more touch with the Python core devs.
> I don't really have any particular insights on this one.  But I am
> concerned about the fact that, even with a unified 2/3 codebase (which
> I agree is the right approach and which we'll move towards in
> IPython), we're going to be living in this funky 2+3 (5 ?) ghetto for
> a long time to come. It's true that we can now write single-codebase
> codes, esp. cleanly if we're willing to drop both 2.6 and 3.2.   But
> that means not using any of the new and sometimes appealing features
> of the language, like 'yield from', function type annotations, or new
> features in the library like concurrent.futures.

That's nothing new, though. You couldn't use with statements or
ternary statements if you wanted to support 2.4, you couldn't use
new-style string formatting if you wanted to support 2.5, and you
can't use set literals or dictionary comprehensions if you want to
support 2.6.

> This means that 2.x support is going to be a drag into people really
> embracing python 3 for a long time to come, since I'm sure that many
> projects will be reluctant to completely drop 2.x support altogether.
> If you ask me, the strategy to encourage py3 adoption should have been:
> 1. Provide the 2to3 tool meant mostly as a one-time use tool to help
> projects make the initial transition, assuming that it would require
> manual cleanup afterwards.
> 2. Provide a 3to2 tool meant to run at installation time automatically
> when setup.py detects it's getting run via python2.  This could do
> whatever ugliness is necessary to emit python2-compatible code,
> possibly along shimming in a backports module along the lines of six.
> If this had been done, we'd all move happily along to python3, knowing
> that (perhaps with a bit of care to ensure we don't fall outside the
> scope of what 3to2 could do) we could support our 2.x user base
> without trouble.
> I know that such a hypothetical 3to2 isn't an easy job, but honestly
> given the years of slowing down of Python development the 3 transition
> has costed everyone, and the amount of grief and pleading for projects
> to move forward, I think it would have been a very worthwhile
> investment.  I'm willing to bet it would massively speed up 3
> adoption, and re-invigorate Python development.

I think 2to3 was a mistake. It gave credence to the idea that Python 3
is a different language from Python 2. What they should have done was
just included something like six with the standard library (or at
least had official documentation on all the ways to get around things,
especially the tricky ones like unicode and metaclasses). That would
have made it clear that supporting 2.x-3.y is no different from
supporting 2.x-2.y, which is what writers of big Python libraries had
already been doing for ages.

That, and I think the print function was a mistake, because it has
(and still is) scared everyone away from Python 3.

Aaron Meurer

> But hey, that's just my opinion.  I'm not in the core team and I'm not
> the one who is going to do the work, so I have little right to
> complain.  They have their priorities and I'm very grateful for the
> fact that on many fronts they do a spectacular job, so unless I'm
> going to roll up my sleeves and do something about this, I should
> probably shut up :)
> Cheers,
> f
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

More information about the IPython-dev mailing list