Re: [Python-Dev] PEP 3149 thoughts
On Sep 12, 2010, at 04:10 PM, Martin v. Löwis wrote: >> Does PEP 3149 have any advantage for Windows installations? > >I don't see any immediate advantage. The problem that the PEP addresses >typically doesn't exist on Windows. Cool. >>> 2. Why does the PEP recommend installing stuff >>> into /usr/share/pyshared? >> >> It's just a suggestion, but as it turns out, probably an incorrect >> one. I'll rephrase this to make it clear that it's up to the >> distribution as to where exactly these files get installed. Nothing >> about this PEP changes the default from-source installation >> directory. > >Is the rephrasing done already? Yes, but I forgot to commit the change. Done now. >I still wonder why you suggest /usr/share should be used, when the FHS >says it should be /usr/lib. This keeps confusing me, despite not being >part of the specification. I don't, as you should now see. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
On Mon, 13 Sep 2010 16:18:44 +0200 (CEST) barry.warsaw wrote: > > -For an arbitrary package `foo`, you would see these files when the > +For an arbitrary package `foo`, you might see these files when the > distribution package was installed:: > > -/usr/share/pyshared/foo.cpython-32m.so > -/usr/share/pyshared/foo.cpython-33m.so > +/usr/lib/python/foo.cpython-32m.so > +/usr/lib/python/foo.cpython-33m.so Are these the default paths? The PEP doesn't say how a distribution is supposed to choose its PEP 3149 filesystem layout (instead of /usr/lib/python3.2/site-packages). Thanks Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python needs a standard asynchronous return object
James Yonan openvpn.net> writes: > I'd like to propose that the Python community standardize on a > "deferred" object for asynchronous return values Have a look at PEP 3148: http://www.python.org/dev/peps/pep-3148/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python needs a standard asynchronous return object
James Yonan openvpn.net> writes: > > I'd like to propose that the Python community standardize on a > "deferred" object for asynchronous return values, modeled after the > well-thought-out Twisted Deferred class. Ummm, sorry, I seem to need new glasses :-( ignore my last post. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
On Sep 13, 2010, at 04:36 PM, Antoine Pitrou wrote: >On Mon, 13 Sep 2010 16:18:44 +0200 (CEST) >barry.warsaw wrote: >> >> -For an arbitrary package `foo`, you would see these files when the >> +For an arbitrary package `foo`, you might see these files when the >> distribution package was installed:: >> >> -/usr/share/pyshared/foo.cpython-32m.so >> -/usr/share/pyshared/foo.cpython-33m.so >> +/usr/lib/python/foo.cpython-32m.so >> +/usr/lib/python/foo.cpython-33m.so > >Are these the default paths? The PEP doesn't say how a distribution >is supposed to choose its PEP 3149 filesystem layout (instead of >/usr/lib/python3.2/site-packages). Why should it? Distributions are going to make their own decisions independent of the PEP. That's why s/would/might/ in the above change. I'm open to suggestions for better ways to explain it. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
On Mon, 13 Sep 2010 10:55:16 -0400 Barry Warsaw wrote: > On Sep 13, 2010, at 04:36 PM, Antoine Pitrou wrote: > > >On Mon, 13 Sep 2010 16:18:44 +0200 (CEST) > >barry.warsaw wrote: > >> > >> -For an arbitrary package `foo`, you would see these files when the > >> +For an arbitrary package `foo`, you might see these files when the > >> distribution package was installed:: > >> > >> -/usr/share/pyshared/foo.cpython-32m.so > >> -/usr/share/pyshared/foo.cpython-33m.so > >> +/usr/lib/python/foo.cpython-32m.so > >> +/usr/lib/python/foo.cpython-33m.so > > > >Are these the default paths? The PEP doesn't say how a distribution > >is supposed to choose its PEP 3149 filesystem layout (instead of > >/usr/lib/python3.2/site-packages). > > Why should it? Distributions are going to make their own decisions > independent of the PEP. That's why s/would/might/ in the above change. I'm > open to suggestions for better ways to explain it. I meant how these decisions are implemented. Is there a configure switch (there doesn't seem to be)? Does it require patching Python? Thanks Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
On Sep 13, 2010, at 05:04 PM, Antoine Pitrou wrote: >On Mon, 13 Sep 2010 10:55:16 -0400 >Barry Warsaw wrote: >> On Sep 13, 2010, at 04:36 PM, Antoine Pitrou wrote: >> >> -/usr/share/pyshared/foo.cpython-32m.so >> >> -/usr/share/pyshared/foo.cpython-33m.so >> >> +/usr/lib/python/foo.cpython-32m.so >> >> +/usr/lib/python/foo.cpython-33m.so >> > >> >Are these the default paths? The PEP doesn't say how a distribution >> >is supposed to choose its PEP 3149 filesystem layout (instead of >> >/usr/lib/python3.2/site-packages). >> >> Why should it? Distributions are going to make their own decisions >> independent of the PEP. That's why s/would/might/ in the above >> change. I'm open to suggestions for better ways to explain it. > >I meant how these decisions are implemented. Is there a configure >switch (there doesn't seem to be)? Does it require patching Python? Ah, no. Standard configure switches are used. Debian (inherited by Ubuntu) has a post-installation script for Python packages which create the .py symlinks and do the byte-compilation. The big win here is that much of this can go away now (and in fact there are modifications to this post-installation script already). -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
> >I meant how these decisions are implemented. Is there a configure > >switch (there doesn't seem to be)? Does it require patching Python? > > Ah, no. Standard configure switches are used. Debian (inherited by Ubuntu) > has a post-installation script for Python packages which create the .py > symlinks and do the byte-compilation. The big win here is that much of this > can go away now (and in fact there are modifications to this post-installation > script already). Ok, so can you explain how the new thing will work (on Debian)? :) Does it mean that e.g. /usr/lib/python3.2/site-packages will get symlinked to /usr/lib/python? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84775 - peps/trunk/pep-3149.txt
Am 13.09.2010 17:36, schrieb Antoine Pitrou: > >>> I meant how these decisions are implemented. Is there a configure >>> switch (there doesn't seem to be)? Does it require patching Python? >> >> Ah, no. Standard configure switches are used. Debian (inherited by Ubuntu) >> has a post-installation script for Python packages which create the .py >> symlinks and do the byte-compilation. The big win here is that much of this >> can go away now (and in fact there are modifications to this >> post-installation >> script already). > > Ok, so can you explain how the new thing will work (on Debian)? :) > Does it mean that e.g. /usr/lib/python3.2/site-packages will get > symlinked to /usr/lib/python? They currently get /usr/lib/pyshared/ onto sys.path, by providing a .pth file (python-support.pth). There are many other ways: you can edit site.py, provide a sitecustomize.py, or edit Modules/Setup (providing a Modules/Setup.local may also work). If I was them, I wouldn't relocate the standard extension modules, but keep them in lib-dynload; /usr/lib/pyshared would only be there for additional packages (which then don't need to bring /usr/lib/python3.3 into existance even though python 3.3 isn't installed). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84792 - in python/branches/py3k: Doc/library/reprlib.rst Lib/collections.py Lib/reprlib.py Lib/test/test_reprlib.py Misc/NEWS
On Tue, Sep 14, 2010 at 7:36 AM, raymond.hettinger wrote: > + # Can't use functools.wraps() here because of bootstrap issues > + wrapper.__module__ = getattr(user_function, '__module__') > + wrapper.__doc__ = getattr(user_function, '__doc__') > + wrapper.__name__ = getattr(user_function, '__name__') > + return wrapper Perhaps add __wrapped__ as well? (I assume that, similar to _collections before it was made a builtin, the bootstrap issue is that _functools is an extension module rather than builtin, but reprlib is needed when building the extension modules?) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
