We are planning the release of 2.5.2 for next week. Unless there are
serious bugs, please hold off making big changes to the 2.5 branch
until after 2.5.2 final is released. Anthony gets cranky when things
break and he scares me...a lot. :-) Doc/test fixes as always are
The plan is cut the release candidate around Tuesday/Wednesday next
week (Oct 16/17). If all goes well, 2.5.2 final will follow a week
Please test the 2.5 branch now and let us know if there are any
serious problems. If there are serious bugs that you think should be
addressed, let us know. Bugs are here: http://bugs.python.org/
I see the bugs below as possibly needing attention. Any comments on these?
http://bugs.python.org/issue1692335 Fix exception pickling: Move
initial args assignment to BaseException.__new__
http://bugs.python.org/issue815646 thread unsafe file objects cause crash
http://bugs.python.org/issue1179 Integer overflow in imageop module
I think Anthony might have a patch for 1179.
on "Unifying types and classes in Python 2.2",
we have a GHOP task to "fill in" the Additional Topics section of this
document. 'novanasa', the student who took this task, has written up a
nice set of doctest additions in reST:
and has asked for feedback. My feedback at the moment is, "looks good,
and useful!" I thought I'd ask on python-dev to see if anyone has any
additional comments or ways to make this more directly useful to Python.
You can just add comments on to the task directly, if you like, or send
them to me.
One set of possible additions is to go through and make annotations on
stuff that is going to change in Py3K. Anything else?
a bit of grep'ping and personal examination discovered the following
tests in trunk/ that could be converted to unittest or doctests. Any
thoughts, pro or con?
(I understand from Brett that the goal is to eradicate "old-style"
tests, by which I think he means tests that do not use unittest or
doctest. There are some good reasons to switch to using unittests, not
least of which is that you can use a variety of frameworks (nose,
py.test) to do value-added wrapping and management of such tests.)
Suggestions for additional things to test or tests to modify, clean up,
or extend and expand are welcome.
On Fri, Dec 21, 2007 at 11:28:55AM +0100, Christian Heimes wrote:
> Your wrapper is a good implementation. I even found an inconvenience in
> my implementation when I studied your code. My wrapper raised an
> exception when a closed fd was removed with EPOLL_CTL_DEL.
It should be a good reference, it's gotten a lot of testing.
> > I would also claim that adding a new interface to accomplish the same
> > task is not more pythonic. But I did write the python-epoll module in
> > question, so I may be a bit biased.
> I agree with Gregory on that part of your answer.
I think we can both be right. The select.poll() code does not really
map to the low level poll() call. In fact, it maps much better to the
epoll() call. It appears that your new API is really a superset of the
the select.poll() interface. The only thing which keeps a user from
just importing your module and using it with code which uses the
existing interface is that you've changed names. Why not change the
names so that it Just Works?
Also, everything but the edge-triggered functionality could be
incorporated back into the select.poll() interface (where "everything"
means the modify() call.)
I wrote a patch adding TIPC support to the socket module, you can find
it in http://bugs.python.org/issue1646.
TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.
On #python-dev, a very friendly person (whose name/nick I can't recall,
I had a power cut and lost my IRC session) helped me with the submission
explained that the patch will probably get rejected in order to keep the
core slim, and suggested I should send an email to this mailing list so
it can be discussed.
I already wrote an external module to support TIPC
(http://auriga.wearlab.de/~alb/pytipc/), but given that the socket
module already supports Linux-specific protocols (AF_PACKET and
AF_NETLINK), and the code impact was (IMHO) small, I wrote a patch to
add TIPC support.
The patch consists of adding the TIPC constants, and modifying
makesockaddr(), getsockaddrarg() and getsockaddrlen() to handle the
TIPC addresses. No generic code is changed.
Compilation is completely conditional on having the TIPC headers, and
has no runtime dependencies.
The diff adds 156 new lines and changes 2, and on x86 increases code
size by about 2k:
text data bss dec hex filename
37158 11980 20 49158 c006 /tmp/so/wo-tipc.so
39162 11980 20 51162 c7da /tmp/so/w-tipc.so
Thanks a lot,
Linux Kernel 2.6+ and BSD (including Mac OS X) have two I/O event
notification systems similar but superior to select() and poll(). From
kqueue, kevent -- kernel event notification mechanism
The kqueue() system call provides a generic method of notifying the user
when an event happens or a condition holds, based on the results of
small pieces of kernel code termed filters. A kevent is identified by
the (ident, filter) pair; there may only be one unique kevent per kqueue.
epoll - I/O event notification facility
epoll is a variant of poll(2) that can be used either as an
edge-triggered or a level-triggered interface and scales well to large
numbers of watched file descriptors.
I've written wrappers for both mechanisms. Both wrappers are inspired
from Twisted and select.poll()'s API. The interface is more Pythonic
than the available wrappers and it reduced the burden on the user. The
users don't have to deal with low level control file descriptors and the
fd is closed automatically when the object is collected.
>>> ep = select.epoll(1)
>>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)
>>> ep.modify(fd, select.EPOLL_OUT)
>>> events = ep.wait(1, 1000)
The kqueue interface is more low level than the epoll interface. It has
too many options.
>>> kq = select.kqueue()
>>> ev = [select.kevent(fd, select.KQ_FILTER_WRITE,
select.KQ_EV_ONESHOT | select.KQ_EV_ADD)]
>>> kq.control(ev, 0, 0)
>>> events = kq.control(, 1, None)
I already talked to some Twisted guys and they really like it. A patch
is available at http://bugs.python.org/issue1657. The code needs more
unit tests and documentation updates.
While testing the tkFileDialog, I encountered a strange error :
~/dev/trunk$ ./python Lib/lib-tk/tkFileDialog.py
Traceback (most recent call last):
File "Lib/lib-tk/tkFileDialog.py", line 202, in <module>
openfilename=askopenfilename(filetypes=[("all files", "*")])
File "Lib/lib-tk/tkFileDialog.py", line 125, in askopenfilename
File "/home/quentin/dev/trunk/Lib/lib-tk/tkCommonDialog.py", line 48, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: expected floating-point number but got "0.0"
Investigating a little, I discovered this is a known issue for some
applications like Pyraf and that the following workaround is effective
: "env LC_NUMERIC=C ./python Lib/lib-tk/tkFileDialog.py".
Looking further, this seems to resolve an atof issue and the fact that
Python assumes a C locale while my Linux box actually uses
fr_FR.UTF-8, but I have a hard time determining if that a Python
issue, a TCL issue or something else.
Has someone already encountered this ?
I posted this up to comp.lang.python earlier today and asked a few questions
around IRC. The general consensus appeared to be that this was a bug. Before
opening up an issue on it, I wanted to run it by this list first (just in case)
Here is a copy / paste from comp.lang.python:
I was wondering what would happen, so I tried this out for the heck of it with:
Python 3.0a2 (py3k:59572M, Dec 19 2007, 15:54:07) [MSC v.1500 32 bit (Intel)]
for x in range(0,a(5)):
Which resulted in a:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "a.py", line 5, in <module>
for x in range(0,a(5)):
SystemError: ..\Objects\longobject.c:400: bad argument to internal
It looks like the rangeobject performs a FitsInLong test on each of
the parameters to range, which uses the function
_PyLong_FitsInLong(PyObject *vv) within longobject.c. In tern, this
performs a typecheck: #define PyLong_CheckExact(op) (Py_TYPE(op) ==
&PyLong_Type) that fails.