Antoine Pitrou wrote:
Le mardi 15 septembre 2009 à 11:57 +0300, Orestis Markou a écrit :
When a new version of Python comes out, people *do* have to
spend some time testing their apps, so if something has moved from
stdlib to stdlib-legacy, they can just install that in their site
packages and go on pretending nothing happened.
Who is "people" in that sentence?
It can be developers. But some applications or scripts have been
developed years ago, by someone who isn't there to maintain them
anymore.
It can be users. But it is unreasonable (and quite rude) to expect users
to fix compatibility problems by themselves.
(do you think the average user knows what a "site packages" is?)
To be fair, anyone relying on legacy Python scripts / applications that
they have no desire or ability to maintain themselves will *soon* have
to stick to the last version of Python 2.X anyway.
Within the foreseeable future vendors will have switched to Python 3 by
default and Python 2 will finally be genuinely stable.
There is the ideal world where every Python program (script,
application, library, etc.) has a dedicated and active maintainer and
regular releases to keep up-to-date with the state of the Python
ecosystem. It is also the visible part of the iceberg (PyPI, Linux
distros etc.), which is why some people assume it accurately describes
reality.
There is the real world where many programs are one-off solutions to
specific problems, coded years ago, not maintained anymore because the
coder has left for another place, and the users don't know Python.
And eventually those programs stop working with the latest and greatest
version of Python. That's the reality of bit-rot.
I read an article (on Planet Python I think) about code-examples from a
C/C++ book that no longer compile with modern compilers (neither VS nor
gcc). Languages change and Python has been better than others in this
regard. The 2 to 3 transition will be very harsh from this point of view
however.
Up until now we have been reluctant to remove modules, although several
deprecated ones were removed in Python 3. My homebrew blogging system,
which I haven't touched the code of in several years, now has several
deprecation warnings from the standard library when I run it - because
it uses the md5 and mimewriter modules that are now deprecated.
The question of removal is an interesting one. Dragging around legacy
code that still needs to be maintained is a burden. We'll see what
smattering of consensus we can reach when there is a PEP.
Michael
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
--
http://www.ironpythoninaction.com/
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
