Mailman 3 August 2007 - Python-Dev

Pleaswe help with the countdown to zero failing tests in the struni branch!
by Guido van Rossum Aug. 7, 2007

Aug. 7, 2007

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 … [View More]

1 1

os.tmpfile() problem
by Maciej Fijalkowski Aug. 7, 2007

Aug. 7, 2007

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 … [View More]

2 1

cStringIO.StringIO() buffer behavior
by Georg Brandl Aug. 6, 2007

Aug. 6, 2007

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 … [View More]

4 7

Re: [Python-Dev] x86_64 Interix - Advise needed on size of long
by Jerker Bäck Aug. 5, 2007

Aug. 5, 2007

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 … [View More]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 [View Less]

1 0

Re: [Python-Dev] [Python-3000] test_asyncore fails intermittently on Darwin
by Alan McIntyre Aug. 5, 2007

Aug. 5, 2007

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 … [View More]

1 0

x86_64 Interix - Advise needed on size of long
by Jerker Bäck Aug. 5, 2007

Aug. 5, 2007

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 … [View More]

2 3

Summary of Tracker Issues
by Tracker Aug. 5, 2007

Aug. 5, 2007

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 Aug. 4, 2007

Aug. 4, 2007

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 Aug. 4, 2007

Aug. 4, 2007

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) … [View More]

1 0

Re: [Python-Dev] [Python-3000] optimizing [x]range
by Lisandro Dalcin Aug. 3, 2007

Aug. 3, 2007

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 … [View More]

1 0