Re: Python Packaging Guide
On Fri, Apr 16, 2010 at 06:15:20PM +0530, Umang Varma wrote [edited]: > A few weeks back there was a small discussion I initiated on > #debian-python about a guide for new-comers to learn about packaging > Python applications and modules. I decided to update, restructure A big bravo for the effort, keep it up! -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419175036.ga3...@mobee
Is it worth back porting PEP 3147 to Python < 3.2?
Apologies for the cross-post, but I want to make sure that everyone who cares about Python on both Debian and Ubuntu gets a chance to weigh in. On Friday, Guido approved and I landed the implementation of PEP 3147 on the py3k trunk (what will be Python 3.2). This allows multiple versions of Python to coexist on the same system without the need for symlinks to handle pyc file incompatibility. http://www.python.org/dev/peps/pep-3147/ This will be officially supported in Python starting with 3.2. It will not however be available in upstream Python 2.7. The PEP does recognize however that distros may want to back port the feature to get its advantages now. Although I have not yet tried to do so, I think the essential elements of the PEP should be fairly easy to back port to Python 2.6, 2.7 and 3.1. The question is, should we do this? As the PEP outlines, my preference would be to back port it but *not* enable this by default in any Python < 3.2. Instead, the back port would add a -Xenablecachedir switch, and an associated $PYTHONENABLECACHEDIR environment variable that would have to be used to enable PEP 3147 pyc paths. Of course, this would have to be supported in python-support and python-central too, but I believe Piotr has started working on this. With the back port it means that any Python modules installed by apt will not need symlinks in order to share both the source and pyc locations. Normal Python developers working on their own code however would still get traditional pyc file locations by default (but of course, there would be nothing stopping them from setting the above switch/envar). It's possible that Debian and Ubuntu will come to different decisions about what to do, but it would be nice if we could reach consensus. I would be willing to do the work to back port the essential bits to earlier Pythons, or at least spend some time to see whether it is feasible. I know that given the release schedule of Python 2.7, it's possible that Ubuntu 10.10 could include 2.6, 2.7, and 3.1, though I don't think that's been decided yet. I'm not sure how Python 2.7's scheduled release date of 2010-06-26 matches Debian's release schedule. (Given that lenny was released on 2010-01-30 I'm guessing it will be a while.) Before I start working on this though, I'd like to get your opinion as to whether it is worth it. Thanks, -Barry signature.asc Description: PGP signature
Skip Python 2.6 and use 2.7 as default in Squeeze?
Given how much work is required to change the default Python, does it make sense to just skip Python 2.6 and use 2.7 as the default Python version in Squeeze? The glaring downside of this is that 2.7 hasn't yet been released, but a feature-complete beta is available and, given how big the test suite is nowadays, it's pretty stable. The final 2.7 should be released in June (see PEP 373 for the full schedule) which is, I guess, before the release of Squeeze. Python 2.7 is faster than 2.6 (in my limited tests from a few percents to more than 7 times faster, the latter with a small CPU-intensive math program), it has a few cool new toys, for many years in the future it will be THE Python 2 version (it's the last one) and, most importantly it has several new features to make the transition to Python 3 easier. Including it in Debian now should make many Python programmers happier in the next few years. Moreover AFAICT 2.7 is the most compatible-with-the-previous-version Python release in the last 16 years, so switching to it from 2.6 should be much less painful than the switch from 2.5 to 2.6 (again in my limited tests 2.7b1 can run without changes anything that ran on 2.6). And, of course, all the work done so far would not be wasted since the changes required are largely the same. TIA for any feedback to this crazy idea. -- Lino Mastrodomenico -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/z2icc93256f1004191719vd8d48523za77c14f3284e8...@mail.gmail.com
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
Hi Lino, Lino Mastrodomenico (20/04/2010): > Given how much work is required to change the default Python, does > it make sense to just skip Python 2.6 and use 2.7 as the default > Python version in Squeeze? Python 2.6 transition is already going on. > The glaring downside of this is that 2.7 hasn't yet been released, > but a feature-complete beta is available and, given how big the test > suite is nowadays, it's pretty stable. The final 2.7 should be > released in June (see PEP 373 for the full schedule) which is, I > guess, before the release of Squeeze. Heard of what's called “freeze” in the release process? Hopefully, it will start before Python 2.7 is released. And the testsuite ensures basically nothing WRT Python Modules from other source packages. > Python 2.7 is faster than 2.6 (in my limited tests from a few > percents to more than 7 times faster, the latter with a small > CPU-intensive math program), it has a few cool new toys, for many > years in the future it will be THE Python 2 version (it's the last > one) and, most importantly it has several new features to make the > transition to Python 3 easier. For any software, new versions always have new shiny features and of course no regressions. > Including it in Debian now should make many Python programmers > happier in the next few years. Including it and making it the default are two different topics. > TIA for any feedback to this crazy idea. You named it. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
On Tue, Apr 20, 2010 at 02:42:37AM +0200, Cyril Brulebois wrote: > > Python 2.7 is faster than 2.6 (in my limited tests from a few > > percents to more than 7 times faster, the latter with a small > > CPU-intensive math program), it has a few cool new toys, for many > > years in the future it will be THE Python 2 version (it's the last > > one) and, most importantly it has several new features to make the > > transition to Python 3 easier. > > For any software, new versions always have new shiny features and of > course no regressions. Of course, Cyril meant "new" regressions, I guess. ;-) > > Including it in Debian now should make many Python programmers > > happier in the next few years. > > Including it and making it the default are two different topics. > > > TIA for any feedback to this crazy idea. > > You named it. :) And, JFTR, I'd go with Cyril's one-step-at-a-time approach, as would most other in the list, I'd guess. But it would be nice to see Python 2.7 in Debian soon. :-) Kumar -- Actually, typing random strings in the Finder does the equivalent of filename completion. -- Discussion on file completion vs. the Mac Finder signature.asc Description: Digital signature
Re: Is it worth back porting PEP 3147 to Python < 3.2?
My take of the situation: Yes, please backport PEP 3147 to at least Python 2.7. The rationale: we'll need to support both Python 2.x and Python 3.x for several years, and it will be nice if the same library package can be made to support both 2.x and 3.x. It would also be nice to define a way to specify that a tree of Python 2.7 scripts are to be compiled into Python 3.x bytecode, by specifying that the compilation process has first to run 2to3 (http://docs.python.org/py3k/library/2to3.html#to3-reference) on the Python scripts and actually compile the 2to3's output. --- Omer On Mon, 2010-04-19 at 17:53 -0400, Barry Warsaw wrote: > On Friday, Guido approved and I landed the implementation of PEP 3147 on the > py3k trunk (what will be Python 3.2). This allows multiple versions of Python > to coexist on the same system without the need for symlinks to handle pyc file > incompatibility. > > http://www.python.org/dev/peps/pep-3147/ > > This will be officially supported in Python starting with 3.2. It will not > however be available in upstream Python 2.7. The PEP does recognize however > that distros may want to back port the feature to get its advantages now. > Although I have not yet tried to do so, I think the essential elements of the > PEP should be fairly easy to back port to Python 2.6, 2.7 and 3.1. The > question is, should we do this? -- $ python >>> type(type(type)) My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1271735426.4405.10.ca...@c2.home.zak.co.il
Re: Is it worth back porting PEP 3147 to Python < 3.2?
On Tue, Apr 20, 2010 at 06:50:26AM +0300, Omer Zak wrote: > My take of the situation: > Yes, please backport PEP 3147 to at least Python 2.7. > The rationale: we'll need to support both Python 2.x and Python 3.x for > several years, and it will be nice if the same library package can be > made to support both 2.x and 3.x. > > It would also be nice to define a way to specify that a tree of Python > 2.7 scripts are to be compiled into Python 3.x bytecode, by specifying > that the compilation process has first to run 2to3 > (http://docs.python.org/py3k/library/2to3.html#to3-reference) on the > Python scripts and actually compile the 2to3's output. Use build_py_2to3 from distutils.command.build_py, for example: if sys.version_info[0] == 3: from distutils.command.build_py import build_py_2to3 cmdclass['build_py'] = build_py_2to3 -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpgxhKLpgyHw.pgp Description: PGP signature
