On 9/11/07, Nick Coghlan <report(a)bugs.python.org> wrote:
> (Is the head still being merged to the py3k branch? Or does this need to
> be forward-ported manually?)
No worries, the trunk is still being merged to py3k. I doubt we'll ever stop
doing that, unless the trunk becomes py3k and 2.x development is done on a
branch (in which case I imagine we'd merge between those two in some way :-)
Thomas Wouters <thomas(a)python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
I've now built a framework in test_ssl to test all client protocols
(SSL2, SSL3, SSL23, TLS1) against all server protocols, and here's
what I've come up with. Servers are along the X axis, and clients are
on the Y axis. "Yes" means that that client protocol can talk to that
SSL2 SSL3 SS23 TLS1
SSL2 yes no no no
SSL3 yes yes yes no
SSL23 no no yes no
TLS1 no no yes yes
I'm a bit surprised by the facts that (1) an SSL2 client can't connect
to an SSL23 server, and (2) an SSL23 client can *only* connect to an
SSL23 server. Can anyone verify that these combos (the results of
testing with the Python framework) are indeed to be expected?
I have an unusual use case in which some software I work on compiles a
version of Python for distribution. I'm not 100% across this as it's not at
all my area of responsibility, but I have been having some issues lately.
My hand-compiled version of Python 2.5 works just fine, and in turn uses a
hand-compiled Tcl/Tk with threading disabled.
The system then re-compiles Python2.5 for its own purposes. At this point,
it appears to ignore some of the options originally set using configure for
I have enough knowledge/control over the system to pass in some additional
compiler flags. I would like to try to force some behaviour normally set as
a flag to the configure script.
Is there a C compiler flag I can use to force the use of UCS2 unicode?
Is there a policy about putting email addresses in PEPs? I have the names
and email addresses of a couple platform maintainers to add to PEP 11.
Having the email addresses there would make it handy to contact said
maintainers, but I realize people don't always appreciate the extra exposure
BerkeleyDB 4.6.19 is a buggy release, the DB_HASH access method databases
can lockup the process. This is why several of the bleeding edge distro
buildbots are timing out while running test_bsddb3. I've created a simple C
test case and made sleepycat^Woracle aware of the problem.
I have a change in my sandbox to explicitly avoid linking with 4.6.19 but it
seems like committing it would just pollute setup.py with vague notions of
what versions of a specific library are bad. I'd prefer to just disallow
use of libdb 4.6 completely in setup.py until oracle fixes this and we're
sure no OS release ships with 4.6.19.
The weekly summaries from the new bug tracker are disappearing somewhere
between the tracker and python-dev. My attempt to post one by hand was
rejected by python-dev-owner (Barry Warsaw?) without explanation. Perhaps he
has bounced the others; emails to python-dev-owner result in an automated
message suggesting that my mail may never be read so I don't know how to ask
As a small boy I once knew wrote, I must not use bad words. (:->
While working on an in-house application that uses the curses
module, we noticed that it didn't work as expected on an AIX system
(powerpc 64-bit big-endian LP64), using python 2.3.5.
On a hunch, I took a look through the _cursesmodule.c code and
noticed the use of PyArg_ParseTuple()'s "l" decoding mode to retrieve
a "long" from python into a C type (attr_t) that on AIX is an int.
On 64-bit LP64 platforms, sizeof(long) > sizeof(int), so this
doesn't quite work, especially on big-endian systems.
Further research into curses shows that different platforms use a
different underlying C type for the attr_t type (int, unsigned int,
long, unsigned long), so changing the PyArg_ParseTuple() to using
the "i" decoding mode probably wasn't portable.
I documented this problem and provided a patch that fixes it against
the head of the svn trunk in http://bugs.python.org/issue1114
(because the problem appears to still exist in the latest code.)
My workaround was to use a separate explicit C "long" to decode
the value from python into, and then just assign that to the
final value and hope that the type promotion does the right thing
on the native platfomr.
My questions are:
(a) What's the "preferred" style in python extension modules
of parsing a number from python into a C type, where the
C type size may change on different platforms?
Is my method of guessing what the largest common size
will be (long, unsigned long, ...), reading into that,
and assigning to the final type, acceptable?
(b) Is there a desire to see the standard python C extension
modules cleaned up to use the answer to (a), especially
where said modules may be susceptable to the word
size problems I mentioned?
(64bit big-endian platforms such as powerpc and sparc64
are good for detecting word-size lossage)