[Python-ideas] Moving development out of the standard library

Ian Bicking ianb at colorstudy.com
Tue Jun 8 23:01:34 CEST 2010


On Tue, Jun 8, 2010 at 3:56 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 09/06/10 05:33, Terry Reedy wrote:
>
>> On 6/7/2010 5:20 PM, Eric Smith wrote:
>>
>>  pip could use the new features in 3.4, and it could get the new features
>>> in 2.x if the users were willing to install the updated library, since
>>> it's not in the stdlib. But for 3.3 you'd be stuck.
>>>
>>
>> I see no reason why 3.3 users could not also download the 3.4 version of
>> something just as well as user of earlier versions (who well might
>> already have the 3.3 version).
>>
>
> I believe Eric was pointing out the fact that, by default, there is no
> directory on sys.path that will override the standard library versions of a
> module or package for all applications using that interpreter installation.
>
> So you're forced to either resort to destructive replacement (actually
> overwriting the standard library module on disk) or else tinkering with
> sys.path in each app or a library to insert an "override" directory before
> the normal standard library paths.
>
> It sometimes seems to me that, for the advocates of a more granular
> standard library, proposing standardisation of such an override directory
> would be an interesting way to test the waters (since it would make it much
> easier to drop in backported updates to standard library modules).
>

Setuptools uses .pth file hackery to handle this case (not to intentionally
override the stdlib, but it would also do that), and I think it could apply
here as well.  Also the way Setuptools installs eggs might be useful in this
case, as it makes it very obvious in tracebacks what version of a module is
being used (and if it is from the standard library).  Even if the particular
mechanics were revisited, I think these basic ideas would be helpful.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100608/932a96d9/attachment.html>


More information about the Python-ideas mailing list