Python-Dev December 2007

python-dev@python.org

74 participants
86 discussions

Re: [Python-Dev] patching asyncore and asynchat

by Daniel Arbuckle

> 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

13 years, 9 months

patching asyncore and asynchat

by Daniel Arbuckle

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

13 years, 9 months

Non-portable address length calculation for AF_UNIX sockets in socketmodule.c

by Vlado Handziski

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

13 years, 9 months

Missing _sqlite checkin on trunk?

by skip＠pobox.com

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

13 years, 9 months

Re: [Python-Dev] Python-Dev Digest, Vol 53, Issue 23

by Daniel Arbuckle

> "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

13 years, 9 months

Re: [Python-Dev] PEP Idea: Syntactic sugar for StopIteration.

by Phillip J. Eby

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. :)

13 years, 9 months

python25 on "Windows 2003 Enterprise Server OS"

by Meerovich, Demitry

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.

13 years, 9 months

bsddb185 v1.0 for Python 2.6 and 3.0

by skip＠pobox.com

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/

13 years, 9 months

PEP Idea: Syntactic sugar for StopIteration.

by Manuel Alejandro Cerón Estrada

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.

13 years, 9 months

Slow tests involving bsddb - timeout

by skip＠pobox.com

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

13 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2007