On Sep 15, 2009, at 2:07 PM, 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?)
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.
People who don't know what Python or site-packages is, should not
receive Python updates anyway (save security updates). The same
argument can be made against Python 3 (and it probably has been). Of
course, I'm not saying that there won't be a lot of cases where
breakage will happen. This can be mitigated by better packaging (ie,
making standalone packages). And I'm not focusing on getopt/optparser
here - there are loads of other modules in stdlib that are dinosaurs
(mostly platform dependent ones) that could be hidden away neatly.
<tagging proposal>
So what do you think of this proposal?
Laura
Seeing that this is an expansion of the stdlib-legacy idea, +1. I
think this is information that's excellent to have, and should be
extended to PyPI as well.
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
