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

Ian Bicking ianb at colorstudy.com
Tue Jun 8 03:49:46 CEST 2010

On Mon, Jun 7, 2010 at 5:45 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> On 7 June 2010 22:20, Eric Smith <eric at trueblade.com> wrote:
>> Tarek Ziadé wrote:
>>> On Mon, Jun 7, 2010 at 10:00 PM, Ian Bicking <ianb at colorstudy.com>
>>> wrote:
>>>> On Mon, Jun 7, 2010 at 2:57 PM, Tarek Ziadé <ziade.tarek at gmail.com>
>>>> wrote:
>>>> If there are important bugs we'll have to work around them.
>>>> If there are added features we'll have to ignore them.
>>> Not for the bug fixes because they will likely to be backported in all
>>> versions. (3.3 and 2.7)
>>> Now for new features, if pip uses the latest 2.x and the latest 3.x
>>> versions, you will get them.
>>> I am not sure why you would have to ignore them.  You would probably want
>>> to
>>> use the new features when they are released, and still make your code
>>> work with older versions.
>> There's no way for the new features to show up in 3.3, is there? You can't
>> add them to a micro release, and you can't replace a module in the standard
>> library. I think that's Ian's point.
> But that's no different to pip using *any* standard library module. If you
> want to support Python 2.4 you can't use os.path.relpath (or you have to
> provide it yourself anyway) for example.

This is part of why I don't care about reforming or modifying what's in the
standard library now -- I know the constraints well, and they can't be
changed.  I'm solely concerned about new functionality which need not repeat
this pattern.

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

More information about the Python-ideas mailing list