On Mon, 16 Mar 2015 07:31 pm, Paul Rubin wrote: > Steven D'Aprano <steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list