Mailman 3 December 2007 - Python-Dev

Re: [Python-Dev] patching asyncore and asynchat
by Daniel Arbuckle 11 Dec '07

11 Dec '07

> From: "Giampaolo Rodola'" <gnewsg(a)gmail.com> > I remembered right now that there's a patch pending which should be > included in the trunk before solving issues related to py3k and/or > applying other changes: > http://bugs.python.org/issue1736190 > Since it solves a lot of older and newer asyncore/chat issues I guess > you should work on that one instead of using the current asyncore/chat > versions available in the trunk. Those patches can't be applied directly to the py3k branch, where Guido asked me to work, so instead I've ported them and merged them with my patch where appropriate. This merged patch should address both py3k porting and the issues in raised in 1736190 http://bugs.python.org/issue1563

1 0

patching asyncore and asynchat
by Daniel Arbuckle 11 Dec '07

11 Dec '07

I've posted a new patch with the documentation for handle_expt and handle_error adjusted, thanks to the feedback from Giampaolo Rodola and James Y Knight. http://bugs.python.org/issue1563

3 3

Non-portable address length calculation for AF_UNIX sockets in socketmodule.c
by Vlado Handziski 10 Dec '07

10 Dec '07

Hi all. I recently stumbled upon an address length calculation problem in socketmodule.c, for UNIX sockets and anonymous "linux" sockets, that is triggered on some embedded platforms due to padding issues. I have submitted a patch dealing with the issue about 4 months ago, but it is still unassigned, and the bug remains even in 3.0: http://bugs.python.org/issue1754489 I would be very grateful if some of the core developers can take a look at the issue so this can be fixed in time for 2.6. Vlado

1 0

Missing _sqlite checkin on trunk?
by skip＠pobox.com 10 Dec '07

10 Dec '07

On Nov 25 Gerhard Haering checked in a change to the release25-maint branch: Author: gerhard.haering Date: Sun Nov 25 18:40:35 2007 New Revision: 59184 Modified: python/branches/release25-maint/Modules/_sqlite/statement.c python/branches/release25-maint/Modules/_sqlite/util.c Log: - Backported a workaround for a bug in SQLite 3.2.x/3.3.x versions where a statement recompilation with no bound parameters lead to a segfault - Backported a fix necessary because of an SQLite API change in version 3.5. This prevents segfaults when executing empty queries, like our test suite does. This bug is also present on the trunk, yet I saw no indication that he checked in such a fix there. Gerhard's patch applies cleanly. I sent him an email after I saw the checkin and verified that the patch worked on the trunk, but have yet to hear back from him. Is there some different method for getting sqlite changes into the trunk? Thx, Skip

2 1

Re: [Python-Dev] Python-Dev Digest, Vol 53, Issue 23
by Daniel Arbuckle 09 Dec '07

09 Dec '07

> "Josiah Carlson" <josiah.carlson(a)gmail.com> wrote: > On Dec 5, 2007 9:19 AM, Guido van Rossum <guido(a)python.org> wrote: > > The asyncore and asynchat modules are in a difficult position when it > > comes to Python 3000. None of the core developers use it or > > particularly care about it (AFAIK), and the API has problems because > > it wasn't written to deal with bytes vs. unicode. E.g. in > > http://bugs.python.org/issue1067, Thomas suggests that these modules > > need to be rewritten to use bytes internally and have separate APIs to > > handle (unicode) text as desired, similar to the way file I/O was > > redesigned. Another alternative would be to make these modules deal > > strictly in bytes, but that would probably vastly reduce their > > usefulness (though I don't know -- as I said, I don't use them). > I can look into it later this month, but for the short term, I'm a > little squeezed for time (work, finishing school, etc.). I am a bit > curious, however, I could have sworn that bytes were to become, > essentially, the 2.x str type (without some methods). If that is the > case, no changes should really be necessary, except for a few small > changes to asynchat with regards to line terminators. > Then again, I haven't really been keeping up in the p3k/pydev lists > for the last 6-8 months, and only the subject line of this posting > caught my eye (because I use asyncore/asynchat, and support users of > asyncore/asynchat that contact me directly). You're exactly right about the (lack of) problems and the correct way to fix them. I've placed a patch in the bug tracker that takes that very approach. http://bugs.python.org/issue1563

3 3

Re: [Python-Dev] PEP Idea: Syntactic sugar for StopIteration.
by Phillip J. Eby 09 Dec '07

09 Dec '07

At 07:55 PM 12/8/2007 -0500, Manuel Alejandro Cerón Estrada wrote: >2007/12/8, Greg Ewing <greg.ewing(a)canterbury.ac.nz>: > > I would put it the other way around -- the problem > > that 'yield break' is meant to solve is already solved > > by 'return'. So there's no need for change. > >I have been re-thinking the problem and this is true. The only >exception would be empty generators, but they are rare. Note that: def g(): return yield Is a valid empty generator. :)

2 1

python25 on "Windows 2003 Enterprise Server OS"
by Meerovich, Demitry 09 Dec '07

09 Dec '07

Hello, Does python25 supports on the "Windows 2003 Enterprise Server OS" ? Thanks Meerovich Dima, Software Intel --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

bsddb185 v1.0 for Python 2.6 and 3.0
by skip＠pobox.com 09 Dec '07

09 Dec '07

Python 3.0 will dispense with the rarely used, but occasionally indispensible, bsddb185 module. I extracted the source code and unit tests from the current Python trunk, wrote a setup.py, made a couple slight mods so it would build and pass tests under both Python 2.6 and 3.0. It's available from the Python Package Index: http://pypi.python.org/pypi/bsddb185 Cheers, -- Skip Montanaro - skip(a)pobox.com - http://www.webfast.com/~skip/

1 0

PEP Idea: Syntactic sugar for StopIteration.
by Manuel Alejandro Cerón Estrada 09 Dec '07

09 Dec '07

Hello Python developers. This is my first post on the list. I have been using Python for a while and I have been thinking about one feature I would like to see integrated into the language. I thought it could be a good topic for a PEP, so I decided to join the list and write about it. First problem: empty generators. Suppose you have to write an empty generator. You could do something like: def foo(): return yield 'never' Or something like: def foo(): yield iter([]).next() Or: def foo(): raise StopIteration() yield "never" There is an old thread discussing the diferent alternatives: http://mail.python.org/pipermail/python-list/2002-November/171588.html Of curse this is unpythonic. It violates the principle of: "There should be one-- and preferably only one --obvious way to do it". Instead, we have a bunch of inelegant solutions, and no one is the obvious one. Second problem: Explicit raise without explicit try-except. Take a look at this example: def lines(): for line in my_file: if some_error(): raise StopIteration() yield line yield 'end' for line in lines(): do_something() Even when the lines function contains an explicit raise statement, there is no explicit try-except block. Of curse, the StopIteration exception is implicitly caught when the generator is called, but this looks a bit confusing. In my opinion, every explicitly raised exception should be explicitly caught by a try-except block. The solution: yield break. The solution used in C# for these problems is the 'yield break' statement. In this way, the empty generator would look like: def foo(): yield break This would be the pythonic way of writing an empty generator. In the same way, every time you want to stop the generation you should call 'yield break', for example: def lines(): for line in my_file: if some_error(): yield break yield line yield 'end' Note that 'yield break' resembles the 'break' statement used in loops, while 'StopIteration' doesn't. 'yield break' is more orthogonal to the rest of the language. I am looking forward to seeing your opinions. Manuel Cerón.

6 12

Slow tests involving bsddb - timeout
by skip＠pobox.com 08 Dec '07

08 Dec '07

I noticed that test_anydbm and test_bsddb seemed to hang, so I -x'd them. Later on while test_whichdb was running and I was off doing something else (so didn't notice the delay), it eventually spewed this traceback: Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_whichdb.py", line 49, in test_whichdb_name f = mod.open(_fname, 'c') File "/Users/skip/src/python/trunk/Lib/dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 310, in hashopen d.open(file, db.DB_HASH, flags, mode) DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit (100) exceeded') Looking at _bsddb.so I see it's linked against Berkeley DB 4.5. This is on Mac OSX 10.4.11 using the MacPorts version of Berkeley DB (4.5.20). Have I somehow strayed out of the support cocoon without realizing it? I wouldn't have thought so, since the max version listed in setup.py is 4.6. Thx, Skip

3 4