Python 2 to 3 conversion - embrace the pain

[Steven D'Aprano]

On Mon, 16 Mar 2015 07:31 pm, Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> The std lib is *batteries* included. If you need a nuclear reactor, you
>> turn to third-party frameworks and libraries like Twisted, Zope, numpy,
>> PLY, etc.
> 
> I always thought twisted and zope were monstrosities.  I've used threads
> instead of twisted and various other possibilities instead of zope.  Not
> sure why numpy couldn't go in the stdlib: does it change all that fast?
> PLY is an application not a library.

I don't know whether numpy changes *fast* or not, but its release cycle is
nothing like CPython's release cycle and it would be impractical to
syncronise the two. numpy is also awfully specialised, with a bunch of
dependencies like Fortran compilers and BLAS.

As for PLY, I'm sorry that was a typo I actually was thinking of PIL.


>> It's precisely because the stdlib has much stronger backward
>> compatibility requirements and a higher reluctance to break things that
>> fast-changing projects (including just bug fixes, not just new features)
>> cannot go into the stdlib.
> 
> Has that been a problem for PHP?

You surely aren't looking at PHP for best practices are you? PHP doesn't
just break backwards compatibility on major updates like 4 to 5, but on
minor updates like 5.2 to 5.3:

http://php.net/manual/en/migration53.incompatible.php

Of course, "problem" seems to be relative. PHP culture seems to accept that
code will break when you do a minor upgrade, and it's no big deal to do a
search-and-replace and rename your functions. The same thing would be
considered unacceptable in Python and unthinkable in C.

http://stackoverflow.com/questions/4693575/is-php-5-3-backwards-compatible-with-php-5-2



-- 
Steven