Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
On Mon, 19 Apr 2010 19:46:48 -0500 Kumar Appaiah wrote: But it would be nice to see Python 2.7 in Debian soon. :-) It's available in experimental (not the latest beta, though). But indeed it would be great to have the 2.6-2.7 transition started a little earlier than the 2.5-2.6 one :-) pgpFtHfNGFfti.pgp Description: PGP signature
Re: Is it worth back porting PEP 3147 to Python 3.2?
[Omer Zak, 2010-04-20] 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. you cannot (in most cases) share 2.X and 3.X Python code, so adding it to 2.7 and not to 2.6 doesn't make sense 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. that has to be done at build time On Mon, 2010-04-19 at 17:53 -0400, Barry Warsaw wrote: 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? I doubt we'll touch 2.X packages in Debian Squeeze and in Squeeze+1 we'll most probably have only 1 Python 2.X version (if any) so I don't see a point in backporting it in Debian. If you want to ship two 2.X Python versions in Ubuntu, you could use my new dh_python for that (I hope to finish it soon), but you'd have to convert *all* packages to it and lets face it, python2.5 and python2.6 transitions in Ubuntu (at least in universe) were... well not even close to Debian's quality and these transitions didn't require that much work... (IMHO, /me waits for other opinions) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100420081453.gn6...@piotro.eu
Re: ITP: nltk -- A suite of Python libraries for natural language processing
On Tue, 2010-04-20 at 10:48 -0300, Luciano Bello wrote: El Jue 08 Abr 2010, Luciano Bello escribió: El Mié 07 Abr 2010, C.J. Adams-Collier escribió: It is already being worked on. The package is being hosted on alioth and seems to build for me. I don't know what is keeping it from being rfs'd. Maybe robin knows? are you talking about Robin Munn? I'm not sure if he can sponsor (is he DD?). I can sponsor the package too, but I quite busy these days. You may ping robin first. Did you get any progress? Do you still need sponsor? l. I'm able to build from svn with svn-buildpackage: svn://svn.debian.org/svn/python-modules/packages/nltk/trunk Could someone do a quick policy audit and point me toward the policy docs so I can address any issues that exist? Cheers, C.J. signature.asc Description: This is a digitally signed message part
Re: ITP: nltk -- A suite of Python libraries for natural language processing
* C.J. Adams-Collier c...@colliertech.org, 2010-04-20, 09:02: It is already being worked on. The package is being hosted on alioth and seems to build for me. I don't know what is keeping it from being rfs'd. Maybe robin knows? are you talking about Robin Munn? I'm not sure if he can sponsor (is he DD?). I can sponsor the package too, but I quite busy these days. You may ping robin first. Did you get any progress? Do you still need sponsor? l. I'm able to build from svn with svn-buildpackage: svn://svn.debian.org/svn/python-modules/packages/nltk/trunk Just for the record, the ITP bug is owned by Robin Munn (CCed), and the package hasn't been sponsored so far, because he didn't reply to my review mail (sent ca 2 month ago), in which I pointed out some serious issues with the package. -- Jakub Wilk signature.asc Description: Digital signature
Re: Is it worth back porting PEP 3147 to Python 3.2?
On Apr 20, 2010, at 10:14 AM, Piotr Ożarowski wrote: [Omer Zak, 2010-04-20] 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. you cannot (in most cases) share 2.X and 3.X Python code, so adding it to 2.7 and not to 2.6 doesn't make sense Just thinking out loud: How insane would it be to think of an import hook that could do it at run time? Or, a compilall switch that would do it when the pyc file was generated? You'd need some way to specify that a particular module could/should not be auto-converted, or conversely if automatic support were more the exception, some way to say it can be done. I wonder if something in the debian/[control|rules] file could trigger that. I doubt we'll touch 2.X packages in Debian Squeeze and in Squeeze+1 we'll most probably have only 1 Python 2.X version (if any) so I don't see a point in backporting it in Debian. Good to know, thanks. If you want to ship two 2.X Python versions in Ubuntu, you could use my new dh_python for that (I hope to finish it soon), but you'd have to convert *all* packages to it and lets face it, python2.5 and python2.6 transitions in Ubuntu (at least in universe) were... well not even close to Debian's quality and these transitions didn't require that much work... Sorry, I don't really know the history of any of that so I can't comment. But I would like to know more about your new dh_python, what changes it would require, etc. Where can I find it, or information about it? -Barry signature.asc Description: PGP signature
Re: Is it worth back porting PEP 3147 to Python 3.2?
On Tue, 2010-04-20 at 15:39 -0400, Barry Warsaw wrote: On Apr 20, 2010, at 06:50 AM, 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. If we can come up with a reasonable way to make that work, then I'd be in favor of back porting the PEP to Python 2.x. Julian Andres Klode suggested a way to do so. DISCLAIMER: I didn't verify that it actually works. On Tue, 2010-04-20 at 07:47 +0200, Julian Andres Klode wrote: 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 -- $ python type(type(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/1271796600.5062.24.ca...@c2.home.zak.co.il
Re: Is it worth back porting PEP 3147 to Python 3.2?
On Monday, April 19, 2010 05:53:05 pm Barry Warsaw wrote: 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). I think it is difficult to know for sure what the future will hold. If the backport is not technically complex, I think a backport with the default to off would be a nice tool in the box is things go differently than we plan. Other than the effort involved, I don't see a downside, but I have no idea how hard this would be to do. Scott K -- 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/201004201657.56871.sc...@kitterman.com
Re: Is it worth back porting PEP 3147 to Python 3.2?
[Barry Warsaw, 2010-04-20] On Apr 20, 2010, at 10:14 AM, Piotr Ożarowski wrote: [Omer Zak, 2010-04-20] 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. you cannot (in most cases) share 2.X and 3.X Python code, so adding it to 2.7 and not to 2.6 doesn't make sense Just thinking out loud: How insane would it be to think of an import hook that could do it at run time? 2to3 is not reliable, at least not for now. Example: even today I backported Python 3 related patch from tip and upstream *did* test it with 2to3 and python3.X before releasing Python 3.X compatible version. The second python3-* package I maintain doesn't provide Python extension for now, as it didn't even build for 3.X version; module (that had to use custom 2to3 rules, BTW) uses it optionally, though. If it doesn't always work with modules tested with python3, I'm pretty sure it will not always work with modules written when python3.X wasn't even released upstream so runtime conversion is not acceptable, IMHO. Every maintainer has to check the module before providing python3-foo package and that requires manpower Ubuntu doesn't have. That's why Python transitions in Ubuntu didn't work that well in the past (I don't recall a single one completed before Debian, and Ubuntu started with 2.6 few years before us...) But I would like to know more about your new dh_python, what changes it would require, etc. Where can I find it, or information about it? it will ship symlinks instead of creating them at runtime (and use list of exceptions instead of shipping a list of files to compile) in old mode and in PEP3147 mode, paths like: /usr/share/python3/foo/__init__.py /usr/share/python3/foo/bar.py /usr/share/python3/foo/3.2-/bar.py /usr/share/python3/3.1-3.5/baz.py using __path__ to choose the right source file (like in the example[1] I gave you the other day). Note that right now it requires changing __init__.py file and that's where namespace PEP comes in (and new .pth files). See threads on debian-python mailing list with dh_python in Subject for more info, some things changed since then (and I'm too sleepy right now to list them :-P), though What changes it will require? Well, I plan to provide wrappers that will emulate dh_pycentral/dh_pysupport's API, but as recent site-packages - dist-packages transition showed - every package has to be checked by its maintainer (there are lots of corner cases not easy to predict like depending on helper tool's internal paths) Right now only pycompile[2] and pyclean[3] are available in public. [1] http://people.debian.org/~piotr/__path__.tar.gz [2] http://people.debian.org/~piotr/pycompile [3] http://people.debian.org/~piotr/pyclean -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100420220108.go6...@piotro.eu
Re: Is it worth back porting PEP 3147 to Python 3.2?
[Barry Warsaw, 2010-04-20] If 10.10 includes only Python 2.7, then sure, we'll only back port to that version. why do you want to backport it to 2.X for a single python2.x package? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100420220337.gp6...@piotro.eu
Re: python 2.6 deb for lenny ?
On 04/01/2010 10:27 AM, Toni Mueller wrote: I'm sorry to say that I forgot to upload my semi-broken attempts - just fixed it - maybe they still provide a useful starting point: http://people.debian.org/~toni/python2.6/ Please send feedback my way! I think Fabio (kob...@d.o) also wanted to / is working on a backport, might make sense to co-maintain that with him. CCed him :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4bce35ea.6070...@bzed.de
Re: Python Packaging Guide
* Umang Varma umang...@gmail.com, 2010-04-18, 08:30: My general impression is that it's yet another (very) bad piece of documentation. Feel free to ignore my opinion however, as I'm already prejudiced. :P It's hard to ignore your opinion (or for that matter, that of any DD here). When you say very bad, it is clearly more than just the factual errors you've listed bellow. Could you explain what you said in more detail? Who is your target audience? If you want this document to be read by packaging newbies, then this document is terribly incomplete. On the other hand, anyone who is acquainted with packaging basics will find your text unnecessarily long, full of uninteresting trivia, yet still non-comprehensive. Moreover, doubling the text length for the sake of being neutral is a bad decision. cdbs does not deserve to advertised in any way. Some people will keep using it, let them do it, but that should be their conscious decision. (As a matter of fact, dh7 is neither a good tool to show how things work.) -- Jakub Wilk signature.asc Description: Digital signature
Re: Python Packaging Guide
On 21/04/10 05:01, Jakub Wilk wrote: Who is your target audience? If you want this document to be read by packaging newbies, then this document is terribly incomplete. That, I believe, would be because of my very limited knowledge in the field. Although I may not have explicitly said this initially, I don't know a world more than what I've written. Therefore, if someone is interested in maintaining a guide for newbies, then they'd have to contribute themselves. (That's why I don't want to credit myself, because if it is to be a complete piece of documentation, my contributions aren't sufficient). On the other hand, anyone who is acquainted with packaging basics will find your text unnecessarily long, full of uninteresting trivia, yet still non-comprehensive. Unfortunately, I cannot see it from that perspective. Basically, I wrote this because I struggled to get my first (and currently only) package built properly because the only piece of documentation available used the cdbs approach and was a little outdated. When you reviewed the package, your comments didn't immediately make sense to me because all I had done was blindly follow a guide. The only thing I wanted to do with this guide was to provide a little more explanation of what you are actually doing when you follow the guide (I don't claim to have been very successful at this though). This so that a newbie, like myself, wouldn't have to spend a great deal of time just to understand a DD's review. Clearly, had I known a little more then, the number of emails we would have exchanged would have been far fewer. Moreover, doubling the text length for the sake of being neutral is a bad decision. cdbs does not deserve to advertised in any way. Some people will keep using it, let them do it, but that should be their conscious decision. (As a matter of fact, dh7 is neither a good tool to show how things work.) You and Luca (Falavigna) have confused me here. You even more ;) because I don't understand what you said about dh7. What you are saying is that the cdbs part should be deleted and what with dh7? Thanks, Umang PS: Jakub, I'm really sorry about the previous email. I completely forgot to click Reply list. Apologies. -- 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/4bce7973.7080...@gmail.com
Re: python 2.6 deb for lenny ?
* 2010-04-21 01:17, Bernd Zeimetz wrote: I think Fabio (kob...@d.o) also wanted to / is working on a backport, might make sense to co-maintain that with him. CCed him :) I'm definitely interested in co-maintaining the backport (and using my own backport in production already). I'll have a look at the packages from Toni, and see the difference with my own backport. Best regards. Fabio -- 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/20100421044627.gf2...@mail.tranchitella.eu
