Mailman 3 March 2009 - Python-Dev

Re: [Python-Dev] BZR mirror and pushing to Launchpad
by Ross Light 09 Mar '09

09 Mar '09

On Sun, Mar 8, 2009 at 7:40 PM, Andrew Bennetts <andrew-pythondev(a)puzzling.org> wrote: > Actually, the Launchpad code server is configured to make bzr automatically > stack on the appropriate branch. The docs you point to there are about manually > specifying the branch to stack on. > > -Andrew. However, my understanding is that Launchpad will not automatically stack if you are using the Python.org branch; you must use the Launchpad mirror. If you want to stack off the Python.org branch, then I think you need to manually stack. Cheers, Ross Light (sorry for possible dupe posting, I thought my mail client was sending to python-dev, but it didn't seem to)

4 4

RELEASED Python 3.1 alpha 1
by Benjamin Peterson 09 Mar '09

09 Mar '09

On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Python 3.1 focuses on the stabilization and optimization of features and changes Python 3.0 introduced. The new I/O system has been rewritten in C for speed. Other features include a ordered dictionary implementation and support for ttk Tile in Tkinter. Please note that these are alpha releases, and as such are not suitable for production environments. We continue to strive for a high degree of quality, but there are still some known problems and the feature sets have not been finalized. These alphas are being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 3.1 might impact you. If you find things broken or incorrect, please submit a bug report at http://bugs.python.org For more information and downloads, see the Python 3.1 website: http://www.python.org/download/releases/3.1/ See PEP 375 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, -- Benjamin Benjamin Peterson benjamin at python.org Release Manager (on behalf of the entire python-dev team)

9 10

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
by Larry Bugbee 09 Mar '09

09 Mar '09

>>> In light of this, what I'd love to see (but sadly can't really help >>> with, and am not optimistic about happening) is for: >>> >>> - python to grow a decent, cross platform, package management system >>> >>> - the standard library to actually shrink to a point where only >>> libraries that are not released elsewhere are included >>> >>> I'd be interested to know how many users of python also felt this >>> way ;-) >>> >> >> I don't like the standard library to shrink. It's good that batteries >> are included. >> > I have mixed feelings. It is great that the batteries are included, > but > some batteries are showing their age or not maintained (who maintains > IDLE? - does the calendar module really warrant being in the standard > library? - imaplib is really not useful and IMAPClient which isn't in > the standard library is much better [1]). > > If a library is well maintained then there seems to be little point in > moving it into the standard library as it may actually be harder to > maintain, and if a library has no active developers then do we really > want it in the standard library... > > On the other hand there are some standard tools that a significant > portion of the community use (Python Imaging Library and the PyWin32 > extensions for example) that aren't in the standard library. > > I think other developers have similar mixed feelings, or at least > there > are enough people on both sides of the fence that it is very hard to > make changes. Perhaps this is the way it should be. Batteries Included should not be interpreted as Soup and Nuts or the Kitchen Sink. There are a lot of good, no, outstanding libraries out there that are excellent candidates for the standard library. IMO, the standard library should include those things that would be truly helpful getting small projects started. Beyond that the needs of the project will likely be specialized to the point that one should be using libraries beyond the standard libraries. Heck, there are things I use frequently that I'd like to be "standard", but could be an imposition on the rest of the Python community. The last thing I want to see is a library so large that we spend time figuring out how to cull unwanted items. Beautiful Soup and html5lib are good, but specialized libraries, and not, IMO, of *general* interest. The same goes for lxml, which by the way, I like and have used. ...but it doesn't have to be in the standard library to be useful. I'd like to suggest that any new candidate for the standard library be discussed and then set aside for a cooling off period of ONE YEAR. If then folks can all agree the library is not only Goodness, but of general interest, especially for bootstrapping small projects, then take a vote, or the BDFL can decide. A key criteria should be, "Will the new library help small projects get started by providing basic capabilities without introducing a steep learning curve?" Larry

2 1

IDLE maintenance
by Mitchell L Model 09 Mar '09

09 Mar '09

I've been trying to decipher the various mentions of IDLE maintenance on this list to determine the likely future (not necessarily feature addition, just keeping it working with each new version of Python and, I suppose, Tk) , who is currently responsible for it, and who will be responsible for it. Presumably these questions have official answers somewhere, but I wouldn't know where to find them. I have several strong reasons to want IDLE to survive, including using it in teaching and writing, where it becomes absurd to provide instructions full of variations based on different IDE's. IDLE is sufficient for introductory courses and books, and useful for many purposes even beyond that. The community should want to minimize the entry friction new users experience, and new users in these times will not necessarily have any experience with command-line shells or editors like vi and emacs. IDLE is at just the right level for someone new to Python to just jump in and start exploring or even for someone with reasonable Python experience investigating a new area of the library. As I said, I don't know the plans or people surrounding IDLE are. If it needs a new maintainer I hereby volunteer. Discussions about my qualifications should probably be conducted through email to me personally, rather than through this mailing list, using the address I use when submitting issues to the tracker: mlm(a)acm.org. -- Mitchell L Model, Ph.D. mlm(a)acm.org MLM Consulting (508) 358-8055 (v) 42 Oxbow Road (508) 641-7772 (m) Wayland, MA 01778

2 1

BZR mirror and pushing to Launchpad
by R. David Murray 09 Mar '09

09 Mar '09

I just posted a (tiny) patch to the tracker, and for the exercise of it I thought I would push the branch out to Launchpad as suggested in the wiki (http://wiki.python.org/moin/Bazaar). It looks like it is uploading every file in the branch instead of the delta from the trunk. Did I do something wrong in my local bzr setup, or is this the expected behavior? -- R. David Murray http://www.bitdance.com

3 3

Re: [Python-Dev] Ruby-style Blocks in Python
by Henning von Bargen 08 Mar '09

08 Mar '09

I totally agree with Matthew. I don't understand the code at first sight. The "with ... do ..." syntax breaks the "Python is executable pseudo-code" pattern. And according the example given at Tav's web site: with employees.select do (emp): if emp.salary > developer.salary: return fireEmployee(emp) else: return extendContract(emp) It is neither shorter nor clearer than the same thing with existing Python syntax: for emp in employees.select: # or should it be "select()"? if emp.salary > developer.salary: fireEmployee(emp) else: extendContract(emp) BTW it seems to me that Python development might go the wrong direction. Using Python for the development of commercial programs for years, I never felt the need to use anything more complicated than generators or decorators. Security, performance, and the "batteries included" are by far more important than esotheric features which Joe Average doesn't understand anyway (and therefore hopefully won't use it). If there's anything where Python should be improved, it's static code analysis (like pylint) in the standard lib and optional type declarations, which could be used to assist pylint and friends as well as JIT compilers, Cython,.... and not even more Meta-thingies. Sorry, I just had to say this once. Henning

1 0

Ruby-style Blocks in Python [Pseudo-PEP]
by tav 08 Mar '09

08 Mar '09

Hey all, Apologies for bringing up an old issue, but I think I've worked out a Pythonic syntax for doing Ruby-style blocks. The short of it is: with employees.select do (emp): if emp.salary > developer.salary: return fireEmployee(emp) else: return extendContract(emp) I explain in detail in this blog article: http://tav.espians.com/ruby-style-blocks-in-python.html It covers everything from why these are useful to a proposal of how the new ``do`` statement and __do__ function could work. Let me know what you think. My apologies if I've missed something obvious. Thanks! -- love, tav plex:espians/tav | tav(a)espians.com | +44 (0) 7809 569 369 http://tav.espians.com | http://twitter.com/tav | skype:tavespian

5 4

3.1 performance
by Antoine Pitrou 08 Mar '09

08 Mar '09

Hello, Out of curiosity, I timed running the test suite ("./python -m test.regrtest") in non-debug mode, in both the release30-maint and py3k branches: * release30-maint got: 302 tests OK. [...] 165.79user 26.03system 5:01.75elapsed 63%CPU * py3k got: 304 tests OK. [...] 113.33user 28.93system 4:06.79elapsed 57%CPU So, 3.1 is 30% faster in user CPU time, even though it probably has more tests (because of io-c, ordereddict and importlib). This is on a 64-bit Linux AMD system, and I got similar results on a 64-bit Linux Core2 system. Regards Antoine.

6 8

asyncore fixes in Python 2.6 broke Zope's version of medusa
by Sidnei da Silva 08 Mar '09

08 Mar '09

I am working on getting Zope to run (or at least, start) with Python 2.6. It actually starts right now after applying some patches, which is amazing on itself, but it dies right away due to changes in asyncore that break Zope's internal version of medusa. I've opened a bug against Zope on Launchpad, but someone suggested that it might actually be a bug in python, in the sense that it changed asyncore in a backwards-incompatible way. I wouldn't go that far, since I think it's more likely that Zope's version of medusa is poking into asyncore internals instead: https://bugs.edge.launchpad.net/zope2/+bug/280020 I suspect a patch similar to this might be needed: http://codereview.appspot.com/744/diff/1/23 Anyone cares to comment? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

17 54

patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)
by Chris Withers 08 Mar '09

08 Mar '09

Martin v. Löwis wrote: > Martin v. Löwis <martin(a)v.loewis.de> added the comment: > >> So all Chris has to do to get this applied to 2.5 is craft an exploit based >> on the current behavior, right? ;-) > > Right :-) Of course, security patches should see a much more careful > review than regular bug fixes. Well, it's funny you say that, since where I bumped into this, the bug was effectively DOS'ing a couple of mailservers as a result of mailinglogger sending out log entries of uncaught exceptions such as this and so emitting 100Mb emails whenever the foreign server chose not to deliver the whole chunk requested... That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related? I can understand the "no more releases unless there are security problems", but what's the harm in applying a patch to an old version branch on the off chance that a security release might be made some time? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

6 8