Mailman 3 March 2006 - Python-Dev

pysqlite for 2.5?
by Anthony Baxter 31 Mar '06

31 Mar '06

This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. What's people's thoughts? Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

27 87

2.5 trunk built for Windows available?
by Georg Brandl 31 Mar '06

31 Mar '06

Hi, for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? Georg

4 4

alpha problems -- need input
by Neal Norwitz 31 Mar '06

31 Mar '06

These issues are on HEAD. There might be some others I missed. With cc there are at least 2 issues: * test_file causes interpreter exit due to sys.stdin.seek(-1) * test_pty fails apparently due to whitespace differences http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/1… Should we skip the test for an invalid seek on stdin on osf1? I haven't investigated the test_pty failure further. With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails * test_ctypes The question is how to fix these. test_float and test_struct fail due to a Floating Point Exception signal (SIGFPE). test_long fails due to float(shuge) raising a ValueError. There is a comment: # XXX Perhaps float(shuge) can raise OverflowError on some box? # The comparison should not. Note: it raises value error, not OverflowError. Should I just wrap the float(shuge) in a try/except and skip the test if an exception is raised? The patches below fix the float and struct problems. I'm not sure if we should ignore SIGFPE in test_float. I'm also not sure if the change to floatobject.c should be made. It's possible there is a compiler flag that would help. I tried -mieee and a few others, but none seemed to make a difference for gcc. test_ctypes fails because _findLib() doesn't seem to work properly on OSF1. Note: libc.so => /usr/shlib/libc.so ERROR: test_find (ctypes.test.test_loading.LoaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py", line 40, in test_find cdll.find(name) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 205, in find raise OSError("Library %r not found" % name) OSError: Library 'c' not found ====================================================================== ERROR: test_load (ctypes.test.test_loading.LoaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py", line 25, in test_load cdll.load(name) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/__init__.py", line 292, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlopen: Cannot map library libc.so.6 ====================================================================== Below are the patches. Index: Objects/floatobject.c =================================================================== --- Objects/floatobject.c (revision 43416) +++ Objects/floatobject.c (working copy) @@ -1430,10 +1430,19 @@ return -1; } else { - float y = (float)x; + float y; const char *s = (char*)&y; int i, incr = 1; + /* The conversion of x to a float causes a floating exception + on some platforms (at least OSF1 v5.1 gcc-4.0.1) + */ +#ifndef MAXFLOAT +#define MAXFLOAT ((float)3.40282346638528860e+38) +#endif + if (x > MAXFLOAT || x < -MAXFLOAT) + goto Overflow; + y = (float)x; if ((float_format == ieee_little_endian_format && !le) || (float_format == ieee_big_endian_format && le)) { p += 3; Index: Lib/test/test_float.py =================================================================== --- Lib/test/test_float.py (revision 43416) +++ Lib/test/test_float.py (working copy) @@ -1,4 +1,5 @@ +import signal import unittest, struct from test import test_support @@ -83,6 +84,12 @@ # is accident (today). class IEEEFormatTestCase(unittest.TestCase): + def setUp(self): + signal.signal(signal.SIGFPE, signal.SIG_IGN) + + def tearDown(self): + signal.signal(signal.SIGFPE, signal.SIG_DFL) + if float.__getformat__("double").startswith("IEEE"): def test_double_specials_do_unpack(self): for fmt, data in [('>d', BE_DOUBLE_INF), Index: Lib/test/test_file.py =================================================================== --- Lib/test/test_file.py (revision 43416) +++ Lib/test/test_file.py (working copy) @@ -100,12 +100,14 @@ print "writelines accepted sequence of non-string objects" f.close() -try: - sys.stdin.seek(-1) -except IOError: - pass -else: - print "should not be able to seek on sys.stdin" +# This causes the interpreter to exit on OSF1 v5.1. +if sys.platform != 'osf1V5': + try: + sys.stdin.seek(-1) + except IOError: + pass + else: + print "should not be able to seek on sys.stdin" try: sys.stdin.truncate() Index: Lib/test/test_long.py =================================================================== --- Lib/test/test_long.py (revision 43416) +++ Lib/test/test_long.py (working copy) @@ -372,10 +372,15 @@ self.assertRaises(OverflowError, eval, test, namespace) - # XXX Perhaps float(shuge) can raise OverflowError on some box? - # The comparison should not. - self.assertNotEqual(float(shuge), int(shuge), - "float(shuge) should not equal int(shuge)") + # float(shuge) can raise OverflowError on an Alpha built with gcc. + try: + fshuge = float(shuge) + except ValueError: + pass + else: + # The comparison should not. + self.assertNotEqual(fshuge, int(shuge), + "float(shuge) should not equal int(shuge)") def test_logs(self): import math Index: Lib/test/test_struct.py =================================================================== --- Lib/test/test_struct.py (revision 43416) +++ Lib/test/test_struct.py (working copy) @@ -429,11 +429,12 @@ # The same, but tack on a 1 bit so it rounds up to infinity. big = (1 << 25) - 1 big = math.ldexp(big, 127 - 24) - try: - packed = struct.pack(">f", big) - except OverflowError: - pass - else: - TestFailed("expected OverflowError") + for value in (big, -big): + try: + packed = struct.pack(">f", value) + except OverflowError: + pass + else: + TestFailed("expected OverflowError") test_705836()

4 4

Nasty trunk test failures
by Tim Peters 31 Mar '06

31 Mar '06

test_tokenize started failing on all the trunk buildbots immediately after this seemingly unrelated checkin: > Author: armin.rigo > Date: Thu Mar 30 16:04:02 2006 > New Revision: 43458 > > Modified: > python/trunk/Lib/test/test_index.py > python/trunk/Objects/abstract.c > python/trunk/Objects/typeobject.c > Log: > Minor bugs in the __index__ code (PEP 357), with tests. I haven't gotten anywhere with this. test_tokenize doesn't fail in isolation on my box, and at one point didn't even fail after using -f to reproduce all the steps up to and including test_tokenize from a failing -r run. I do have a long sequence of tests now ending with test_tokenize that fails on my box provided I use -uall (and I should note that test_index is not in this sequence). I'm using a debug build here, and don't know about a release build. Alas, it takes a long time to run, so progress this way is slow. Worse, since this is so flaky I doubt it's going to lead to something interesting anyway. More eyeballs? I didn't see anything obviously wrong in Armin's checkin. Maybe someone else would. Or maybe it's just managing to provoke a pre-existing C problem. ... Eww! test_tokenize _does_ fail in isolation here, but only if I use -uall(!): C:\Code\python\PCbuild>python_d ../Lib/test/regrtest.py test_tokenize test_tokenize 1 test OK. [25131 refs] C:\Code\python\PCbuild>python_d ../Lib/test/regrtest.py -uall test_tokenize test_tokenize test test_tokenize crashed -- <class 'exceptions.AssertionError'>: 1 test failed: test_tokenize [15147 refs] OK, test_tokenize does a hell of a lot more work when -uall is specified. After applying this patch, test_tokenize fails very quickly (although you still need -uall): """ Index: test_tokenize.py =================================================================== --- test_tokenize.py (revision 43462) +++ test_tokenize.py (working copy) @@ -34,6 +34,7 @@ testdir = os.path.dirname(f) or os.curdir testfiles = glob.glob(testdir + os.sep + 'test*.py') +testfiles = [testdir + os.sep + 'test_index.py'] if not is_resource_enabled('compiler'): testfiles = random.sample(testfiles, 10) """ IOW, it's specifically the new test_index.py that test_tokenize fails on. I'm not sure what test_tokenize is doing, but if someone else is, that seems like a good hint ;-)

2 2

Class decorators
by Jim Jewett 31 Mar '06

31 Mar '06

Phillip J. Eby wrote: > I don't even recall seeing any examples of class decorators > being used without arguments! I have often started with a function, and ended up replacing it with a callable object so that I could save state without resorting to "defalt args" or worse. I would prefer to decorate these exactly like the functions they replace. -jJ

1 0

Re: [Python-Dev] pysqlite for 2.5?
by Phillip J. Eby 31 Mar '06

31 Mar '06

At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote: >On 3/28/06, Anthony Baxter <anthony(a)interlink.com.au> wrote: > > I'm happy to work with Gerhard to make this happen. Does it need a > > PEP? I'd say "no", but only because things like ElementTree didn't, > > either. Does it need a BDFL pronouncement? I'd say yes. > >Unless you've recanted on that already, let me point out that I've >never seen sqlite, and I've ignored this thread, so I don't know what >the disagreement is all about. Perhaps one person in favor and one >person against could summarize the argument for me? Pro: * SQLite is really nice to have for writing simple applications with small data needs, especially client-side software. It's probably the best-of-breed open source embedded SQL DB right now. * So, having a wrapper would be a big "Batteries included" plus for Python Con: * Competing Python wrappers exist * SQLite itself is updated frequently, let alone the wrappers * Build integration risks unknown, possible delay of 2.5? * Another external library to track and maybe have emergency updates of I personally lean somewhat toward the con side because to me it's just as easy to "easy_install pysqlite" after the fact, or get it from the appropriate packager (RPM, Debian, whatever). However, we can't please everybody. If we go for more "batteries included", one group will complain about how much we have linked in and don't have proper system dependencies. If we go for "easy to install add-ons", the same people will gripe that it's the job of the packaging system to do those add-ons, and another group will chime in that they don't have or don't want the packaging system. So we might as well flip a coin. :)

9 16

Python 2.5 Schedule
by Neal Norwitz 30 Mar '06

30 Mar '06

I posted a message to c.l.p about the upcoming alpha 1. Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up real quick, hopefully within a couple of weeks. If you have any *major* features (particularly implemented in C) that you want to see in 2.5, bring it up now. I want to strive for feature completeness by alpha 1. I know we will have some .py modules that won't make it into alpha 1, but they really should make it in by alpha 2 or be deferred to 2.6. For any important bugs or patches, add comments to them. There's still a bunch that I want to see go in. If all goes well, with alphas 1 & 2, maybe we could even skip an alpha 3? We can make a beta 3 if things don't go as well as I anticipate. I'm hoping the buildbot helped shake out a lot of the bugs we might have seen in the alphas. We'll have to wait and see what makes sense. n

18 67

Fwd: Python 2.5 update
by Martin Blais 30 Mar '06

30 Mar '06

---------- Forwarded message ---------- From: Martin Blais <blais(a)furius.ca> Date: Mar 29, 2006 10:32 PM Subject: Python 2.5 update To: optik-users(a)lists.sourceforge.net Hi I was thinking of a new action "append_const" to optparse, so I googled it to check if anybody else had been thinking about the same idea, and *surprise* -- not really -- I discover that it's already been implemented and included in Optik 1.5. Now, I checked in the upcoming Python 2.5 source code -- the Subversion repository -- and it still is at 1.5a2, which does not contain this code. And the stdlib uses an alpha version? Hmmm. What is the process for upgrading the stdlib version of optparse? Are there any plans to upgrade the stdlib's 1.5a2 to the stable 1.5? It seems like it has been released for a while... If there are no plans to do that, what is the process exactly, and can I nudge it with a little bit of armwork somehow? cheers,

2 1

Re: [Python-Dev] pysqlite for 2.5?
by Guido van Rossum 30 Mar '06

30 Mar '06

So do I. On 3/30/06, Bill Janssen <janssen(a)parc.com> wrote: > > I think sqlite is just fine. > > I do, too. > > Bill -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

xmlrpclib.binary missing?
by Chris AtLee 30 Mar '06

30 Mar '06

The current 2.4 and 2.5 docs mention that the xmlrpclib has a function called binary which converts any python value to a Binary object. However, this function does not exist in either 2.4.3 or 2.5. The Binary constructor accepts a data parameter, so I would say just remove mention of the binary function from the docs and leave the implementation as-is. Cheers, Chris

2 2