[stdlib-sig] Breaking out the stdlib

[Orestis Markou]

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 at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig