> 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:
> 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
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:
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.
On Nov 25 Gerhard Haering checked in a change to the release25-maint branch:
Date: Sun Nov 25 18:40:35 2007
New Revision: 59184
- 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
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?
> "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
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.
Is a valid empty generator. :)
Does python25 supports on the "Windows 2003 Enterprise Server OS" ?
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.
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:
Skip Montanaro - skip(a)pobox.com - http://www.webfast.com/~skip/
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:
Or something like:
There is an old thread discussing the diferent alternatives:
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
Second problem: Explicit raise without explicit try-except.
Take a look at this example:
for line in my_file:
for line in lines():
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:
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:
for line in my_file:
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.
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.