Patch #849407 proposes to change the meaning of the
urllib reporthook so that it takes the amount of the
data read instead of the block size as its second
While this is a behavior change (and even for
explicitly-documented behavior), I still propose
to apply the change:
- in many cases, the number of bytes read will
equal to the block size, so no change should
- the signature (number of parameters) does not
change, so applications shouldn't crash because
of that change
- applications that do use the parameter to
estimate total download time now get a better
chance to estimate since they learn about
What do you think?
this might seem a bit late, and perhaps I was just blind,
but I miss something like a summary how the Python
summer of code projects went, and what the status of the ones
that were meant to improve the standard library, e.g. the
C decimal implementation, is.
I was looking around for an interface to POSIX capabilities from Python
under Linux. I couldn't find anything that did the job, so I wrote the
attached PosixCapabilities module. It has a number of shortcomings:
* it is written using ctypes to interface directly to libcap;
* it assumes the sizes/types of various POSIX defined types;
* it only gets/sets process capabilities;
* it can test/set/clear capability flags.
Despite the downsides, I think it would be good to get the package out
there. If anyone wishes to adopt it, update it, rewrite it and/or put
it into the distribution, then feel free.
> As for the adding of logging to the stdlib modules ... we need the mentors
> to step forward and say something about that.
The logging additions are not ready for stdlib inclusion at this time.
Some modules are closer than others, but whether it makes sense to add
them piecemeal is a different question.
Discussion of what we want in terms of the schema for the new issue tracker
has begun. If you wish to give feedback on what you would like each issue
to have in terms of data then please file an issue in the meta tracker at
http://psf.upfronthosting.co.za/roundup/meta/ . You can see the current
test tracker at http://psf.upfronthosting.co.za/roundup/tracker/ . And the
tracker-discuss mailing list is at
http://mail.python.org/mailman/listinfo/tracker-discuss (although you can
bypass the list and use the meta tracker to your ideas relating to the
If you do participate through the meta tracker please sign up for an account
so that it is not anonymous. I really hope that Anthony and Neal can
participate so that we can make sure the tracker does what they need to make
their lives easier during a release. And obviously everyone who still works
with bugs and patches should participate as well. We can change the schema
even after we launch to the new tracker, but it would be nice to minimize
the amount of feature churn once the tracker is up and going.
I have a fix to my bug report 1593035 regarding
python-2.5 not working with readline on ia64-Linux.
This bug was found while trying to port SAGE
(http://modular.math.washington.edu/sage/) to ia64-Linux.
The problem is caused by the line of Modules/readline.c
return completion_matches(text, *on_completion);
In readline-5.2, completion_matches() is defined in
char ** completion_matches(const char *,rl_compentry_func_t *);
But in Modules/readline.c completion_matches() by default is
assumed to return an int, and on_completion() is defined as
To fix the problem, both the function itself and the
second argument need to be cast to the correct types
return (char **) completion_matches(text, (rl_compentry_func_t *)*on_completio
and completion_matches needs to be defined as an external
function. I added the following else clause to the ifdef
at the top of Modules/readline.c/flex_complete()
#define completion_matches(x, y) \
rl_completion_matches((x), ((rl_compentry_func_t *)(y)))
extern char ** completion_matches(const char *,rl_compentry_func_t *);
University of Maryland, College Park
Wow. Did you catch this news?
The first four weeks of C1 will be a lot like the first
four weeks of 6.001, Abelson said. The difference is
that programming will be done in Python and not Scheme.
I'd like to share an observation on portability of extension
modules to Python 2.5: python-ldap would crash on Solaris, see
It turns out that this was caused by a mismatch in malloc
"families" (PyMem_Del vs. PyObject_Del):
So if Python 2.5 crashes in malloc/free, it's probably a good
guess that some extension module failed use correct APIs.
There is probably not much we can do about this: it's already
mentioned in "Porting to 2.5" of whatsnew25. It would be good
if people were aware of this issue (and the other changes to
the C API); thus I hope that this message/thread makes it to
the python-dev summary :-)