Mailman 3 August 2007 - Python-Dev

Pleaswe help with the countdown to zero failing tests in the struni branch!
by Guido van Rossum 08 Aug '07

08 Aug '07

We're down to 11 failing test in the struni branch. I'd like to get this down to zero ASAP so that we can retire the old p3yk (yes, with typo!) branch and rename py3k-struni to py3k. Please help! Here's the list of failing tests: test_ctypes Recently one test started failing again, after Martin changed PyUnicode_FromStringAndSize() to use UTF8 instead of Latin1. test_email test_email_codecs test_email_renamed Can someone contact the email-sig and ask for help with these? test_minidom Recently started failing again; probably shallow. test_sqlite Virgin territory, probably best done by whoever wrote the code or at least someone with time to spare. test_tarfile Virgin territory again (but different owner :-). test_urllib2_localnet test_urllib2net I think Jeremy Hylton may be close to fixing these, he's done a lot of work on urllib and httplib. test_xml_etree_c Virgin territory again. There are also a few tests that only fail on CYGWIN or OSX; I won't bother listing these. If you want to help, please refer to this wiki page: http://wiki.python.org/moin/Py3kStrUniTests There are also other tasks; see http://wiki.python.org/moin/Py3kToDo -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 1

os.tmpfile() problem
by Maciej Fijalkowski 08 Aug '07

08 Aug '07

I've got slight problem with os.tmpfile(). What I would like to do is to get the filedesc of tmpfile. First approach: os.tmpfile().fileno() of course does not work out, because fileno() does not keep object alive. The solution is to keep os.tmpfile() result somewhere for an arbitrary amount of time, which is quite obscure. This is problem with all file operations, but fortunately if I want a filedesc, I can do just os.open() which will not close the file for me. I've got several obscure solutions, noone satisfies me really: * If I use .fileno() than I'm on my own and I need to close file myself * .fileno() returns a int-like object which keeps alive file (well, this will explode when keeping this as an index in a list, which does not keep the object alive and so on) * have os._tmpfile() or whatever which returns filedesc What do you think? Cheers, fijal

2 1

cStringIO.StringIO() buffer behavior
by Georg Brandl 07 Aug '07

07 Aug '07

See bugs #1548891 and #1730114. In the former, it was reported that cStringIO works differently from StringIO when handling unicode strings; it used GetReadBuffer which returned the raw internal UCS-2 or UCS-4 encoded string. I changed it to use GetCharBuffer, which converts to a string using the default encoding first. This fix was also in 2.5.1. The latter bug now complains that this excludes things like array.array()s from being used as an argument to cStringIO.StringIO(), which worked before with GetReadBuffer. What's the preferred solution here? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

4 7

Re: [Python-Dev] x86_64 Interix - Advise needed on size of long
by Jerker Bäck 05 Aug '07

05 Aug '07

Hello Martin, > > You mean I should list all of these in "Modules/Setup"? > Exactly so. They are already listed - just uncomment them all > (with proper command line flags and libraries where necessary). OK, I will try to get it compiled and tested. Meanwhile, you asked so: > I still don't understand. Are you *certain* that these are LP64 > libraries? Can you kindly refer to some official document that says > Interix uses LP64 on AMD64? MS is surprisingly very quiet of the POSIX subsystem and the Interix BSD implementation, so it's hard to find any official info on the net. But here is one the developers: <http://blogs.msdn.com/shan/archive/2006/12/12/hi-there.aspx> In Interix SDK releasenotes.htm (SDK download): "64-bit compilation supports the LP64 data model." Interix general: <http://www4.osnews.com/story/5751/Review_of_Windows_Services_for_UNIX_3.5> <http://www.interopcommunity.com> To find details on how it all really works, one will have to look in the headers and try different features oneself. (Which actually is pretty fun because it's really fast and usually works well). The SDK comes with support for x86, x86_64 (EM64T or AMD64) and IA64. > And if so, how did Microsoft manage to build them, if their compiler > does not support LP64? (I see you kind of answer that below - although > I'm unsure what "translate all longs to long long means - you mean > literal text replacement?) Sure, cc precompiles the source file to a temporary file, flip it, runs a conversion tool - "l2ll" => all <long> are converted to <long long> and finally compiles the converted file. The compile is done via a call from POSIX to the Windows subsystem and the compiler found in the POSIX path environment. To understand the details one has to know that the POSIX environment runs directly on top of the NT kernel and know nothing of Windows, Windows paths etc. This is kind of a compile on the fly. The libraries are also of two kinds: 1 The core POSIX libraries - part of the OS, uses DDK tools 2 Interix SDK - BSD libc and utils, uses cc and Interix gcc (x86 only) The DDK tools is turned to LP64 support via special defines in the headers. But here is some unclear issues with functions directly exported from the OS native LLP64 libraries (ntdll.dll) - don't know how this is solved. Somewhere here lies the reason why cc is hard to use with Visual Studio and why the long type is such a nuisance. I also tried the Intel x64 PE compiler (for better C99 support), but it produces applications which relies on Windows API functions (e.g. VirtualAlloc, LoadLibrary) and thus cannot be used in POSIX. Cheers, Erik

1 0

Re: [Python-Dev] [Python-3000] test_asyncore fails intermittently on Darwin
by Alan McIntyre 05 Aug '07

05 Aug '07

On 8/4/07, Jeffrey Yasskin <jyasskin(a)gmail.com> wrote: > Well, regardless of the brokenness of the patch, I do get two > different failures from this test on OSX. The first is caused by > trying to socket.bind() a port that's already been bound recently: <snip> > That looks pretty easy to fix. It was fixed in the trunk on July 28 as part of rev 56604, by letting the OS assign the port (binding to port 0). I apologize if everybody was expecting me to fix this in Python 3000; I thought the initial complaint was in reference to 2.6. I'm working on test improvements for 2.6, so I'm sort of fixated on the trunk at the moment. :) I wouldn't mind trying to roll my changes forward into Py3k after GSoC is done if I have the time, though. Alan

1 0

x86_64 Interix - Advise needed on size of long
by Jerker Bäck 05 Aug '07

05 Aug '07

Hello all, I'm in need of an advise how to handle sizeof long in python. I wanted a x86_64 compile of python for Interix (that is NT POSIX subsystem with x86_64 Interix 6 SDK). My first attempt to build failed due to the makefile insisted on linking as shared libraries (works only in x86 with GNU ld). Tried autoreconf to get rid of libtool - no luck. Q1: Is the static build broken? Q2: Anyone have a useable Makefile.am? My second attempt was based on the VS2005 project and the previous Makefile. Not to tire you with details, but for this to work I need to explicit assign the sizeof long (replace all long types with explicit sized ones, int32_t, ssize_t etc). There are 2 choices: All longs to 64bit (LP64 model) or all to 32bit (LLP64 model). Since Interix use LP64 the first alternative would be logic, but considering compatibility with the Windows DLL, performance(?) and whatever, I choosed the latter. A choice which later would turn me into trouble. Here's how I am reasoning: x64 Windows DLL = LLP64 model => sizeof(long) = 4 x86_64 Interix = LP64 model => sizeof(long) = 8 So, since the Windows build works, basically all long types in the code are 32bit (or at least works if they are 32bit). 64bit dependent variables like pointers have already been taken care of. Right? While it sounds reasonable as long as one are consistent, it's actually quite difficult to get it right (and a lot of work). To be precise, would this be OK? long PyInt_AsLong(PyObject *); change to: int32_t PyInt_AsLong(PyObject *); or unsigned long PyOS_strtoul(char*, char**, int); to: uint32_t PyOS_strtoul(char*, char**, int); Thanks, Erik

2 3

Summary of Tracker Issues
by Tracker 05 Aug '07

05 Aug '07

ACTIVITY SUMMARY (07/29/07 - 08/05/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1276 open ( +0) / 11101 closed ( +0) / 12377 total ( +0) Average duration of open issues: 695 days. Median duration of open issues: 561 days. Open Issues Breakdown open 1274 ( +0) pending 2 ( +0)

1 0

Pythreads and BSD descendants
by Cameron Laird 04 Aug '07

04 Aug '07

Folklore that I remember so unreliably I avoid trying to repeat it here held that Python threading had problems on BSD and allied Unixes. What's the status of this? I suspect the answer is, "Everything works, and the only real problem ever was that *signals* have different semantics under Linux and *BSD." Anyone who can answer explicitly, though, would repre- sent a help to me.

5 4

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 04 Aug '07

04 Aug '07

Patch / Bug Summary ___________________ Patches : 404 open ( +5) / 3847 closed (+11) / 4251 total (+16) Bugs : 1059 open ( +3) / 6784 closed ( +8) / 7843 total (+11) RFE : 263 open ( +0) / 295 closed ( +1) / 558 total ( +1) New / Reopened Patches ______________________ struni: Fix test_aepack by converting 4cc's to bytes (2007-07-26) CLOSED http://python.org/sf/1761465 reopened by gvanrossum distutils.util.get_platform() return value on 64bit Windows (2007-07-27) http://python.org/sf/1761786 opened by Mark Hammond Some fix abount _WIN32_WINNT (2007-07-27) CLOSED http://python.org/sf/1761803 opened by Hirokazu Yamamoto struni: test_xml_etree.py (2007-07-27) CLOSED http://python.org/sf/1762412 opened by Joe Gregorio unable to serialize Infinity or NaN on ARM using marshal (2007-07-28) http://python.org/sf/1762561 opened by Matthias Klose struni: test_urllib2, test_cookielib (2007-07-29) CLOSED http://python.org/sf/1762940 opened by Joe Gregorio socket close fixed (2007-07-29) CLOSED http://python.org/sf/1763387 opened by Hasan Diwan tiny addition to peephole optimizer (2007-07-31) http://python.org/sf/1764087 opened by Paul Pogonyshev Fix for test_socketserver for Py3k (2007-07-31) CLOSED http://python.org/sf/1764815 opened by ??PC?? generic and more efficient removal of unreachable code (2007-08-01) http://python.org/sf/1764986 opened by Paul Pogonyshev logging: delay_fh option and configuration kwargs (2007-08-01) http://python.org/sf/1765140 opened by Chris Leary small improvement for peephole conditional jump optimizer (2007-08-01) http://python.org/sf/1765558 opened by Paul Pogonyshev urllib2-howto - correction (2007-08-02) http://python.org/sf/1765839 opened by O.R.Senthil Kumaran improve xrange.__contains__ (2007-08-02) http://python.org/sf/1766304 opened by Stargaming Fix for test_zipimport (2007-08-03) CLOSED http://python.org/sf/1766592 opened by ??PC?? Make xmlrpc use HTTP/1.1 and keepalive (2007-08-04) http://python.org/sf/1767370 opened by Donovan Baarda test_csv struni fixes + unicode support in _csv (2007-08-03) http://python.org/sf/1767398 opened by Adam Hupp Patches Closed ______________ struni: Fix test_aepack by converting 4cc's to bytes (2007-07-26) http://python.org/sf/1761465 closed by gvanrossum struni: Fix test_aepack by converting 4cc's to bytes (2007-07-26) http://python.org/sf/1761465 closed by gvanrossum Some fix abount _WIN32_WINNT (2007-07-27) http://python.org/sf/1761803 closed by mhammond struni pulldom: Don't use 'types' to check strings (2007-07-24) http://python.org/sf/1759922 closed by gvanrossum struni: test_xml_etree.py (2007-07-27) http://python.org/sf/1762412 closed by loewis struni: test_urllib2, test_cookielib (2007-07-28) http://python.org/sf/1762940 closed by gvanrossum socket close fixed (2007-07-30) http://python.org/sf/1763387 closed by facundobatista itertools.getitem() (2007-07-08) http://python.org/sf/1749857 closed by rhettinger Fix for test_socketserver for Py3k (2007-07-31) http://python.org/sf/1764815 closed by gvanrossum Fix Decimal.sqrt bugs described in #1725899 (2007-06-22) http://python.org/sf/1741308 closed by facundobatista Fix for test_zipimport (2007-08-03) http://python.org/sf/1766592 closed by gvanrossum urllib2 tests pass (2007-07-16) http://python.org/sf/1755133 closed by gvanrossum New / Reopened Bugs ___________________ 'exec' does not accept what 'open' returns (2007-07-28) http://python.org/sf/1762972 opened by Brett Cannon S.find documentation uses s[start, end] vs. s[start:end] (2007-07-29) CLOSED http://python.org/sf/1763149 opened by Rob copy 2 (2007-07-30) http://python.org/sf/1764044 opened by robs pythonid _RLock.__repr__ throws exception (2007-07-30) CLOSED http://python.org/sf/1764059 opened by Greg Kochanski The -m switch does not use the builtin __main__ module (2007-07-31) http://python.org/sf/1764407 opened by Nick Coghlan Decimal comparison with None fails in Windows (2007-07-31) CLOSED http://python.org/sf/1764761 opened by pablohoffman.com setup.py trashes LDFLAGS (2007-08-01) http://python.org/sf/1765375 opened by Harald Koenig poll() returns "status code", not "return code" (2007-08-02) http://python.org/sf/1766421 opened by sjbrown os.chmod failure (2007-08-03) http://python.org/sf/1767242 reopened by rgheck os.chmod failure (2007-08-03) http://python.org/sf/1767242 opened by Richard Heck String.capwords() does not capitalize first word (2007-08-03) http://python.org/sf/1767363 opened by Saatvik Agarwal Bugs Closed ___________ No docs for list comparison (2007-07-25) http://python.org/sf/1760423 closed by gbrandl SSL-ed sockets don't close correct? (2004-06-24) http://python.org/sf/978833 closed by loewis incorrect return value of unicodedata.lookup() - beoynd BMP (2007-04-21) http://python.org/sf/1704793 closed by loewis Thread.join() fails to release Lock on KeyboardInterrupt (2005-03-26) http://python.org/sf/1171023 closed by phansen S.find documentation uses s[start, end] vs. s[start:end] (2007-07-29) http://python.org/sf/1763149 closed by gbrandl _RLock.__repr__ throws exception (2007-07-31) http://python.org/sf/1764059 closed by ncoghlan Decimal comparison with None fails in Windows (2007-07-31) http://python.org/sf/1764761 closed by facundobatista decimal sqrt method doesn't use round-half-even (2007-05-25) http://python.org/sf/1725899 closed by facundobatista New / Reopened RFE __________________ add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP (2007-07-31) http://python.org/sf/1764638 opened by Paul Pogonyshev RFE Closed __________ add operator.fst and snd functions (2007-05-27) http://python.org/sf/1726697 closed by rhettinger

1 0

Re: [Python-Dev] [Python-3000] optimizing [x]range
by Lisandro Dalcin 04 Aug '07

04 Aug '07

On 8/2/07, Stargaming <stargaming(a)gmail.com> wrote: > >> made into an O(1) operation. here's a demo code (it should be trivial > >> to implement this in CPython) > [snipped algorithm] Did you taked into account that your patch is not backward compatible with py2.5?? Just try to do this with your patch, $ python Python 2.5.1 (r251:54863, Jun 1 2007, 12:15:26) >>> class A: ... def __eq__(self, other): ... return other == 3 ... >>> A() in xrange(3) False >>> A() in xrange(4) True >>> I know, my example is biased, but I have to insist. With this patch, 'a in xrange' will in general not be the same as 'a in range(...)'. I am fine with this for py3k, but not sure if all people will agree on this for python 2.6. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0