Mailman 3 September 2000 - Python-Dev

stupid floating point question...
by Martin von Loewis 29 Sep '00

29 Sep '00

> A *good* compiler won't collapse *any* fp expressions at > compile-time, because doing so can change the 754 semantics at > runtime (for example, the evaluation of 1./6 triggers the 754 > "inexact" signal, and the compiler has no way to know whether the > user is expecting that to happen at runtime, so a good compiler will > leave it alone Of course, that doesn't say anything about what *most* compilers do. For example, gcc, on i586-pc-linux-gnu, compiles double foo(){ return (double)1/6; } into .LC0: .long 0x55555555,0x3fc55555 .text .align 4 .globl foo .type foo,@function foo: fldl .LC0 ret when compiling with -fomit-frame-pointer -O2. That still doesn't say anything about what most compilers do - if there is interest, we could perform a comparative study on the subject :-) The "would break 754" argument is pretty weak, IMO - gcc, for example, doesn't claim to comply to that standard. Regards, Martin

7 18

.pyc broken on Windows -- anywhere else?
by Tim Peters 29 Sep '00

29 Sep '00

This is from 2.0b2 Windows, and typical: C:\Python20>python -v # C:\PYTHON20\lib\site.pyc has bad magic import site # from C:\PYTHON20\lib\site.py # wrote C:\PYTHON20\lib\site.pyc # C:\PYTHON20\lib\os.pyc has bad magic import os # from C:\PYTHON20\lib\os.py # wrote C:\PYTHON20\lib\os.pyc import nt # builtin # C:\PYTHON20\lib\ntpath.pyc has bad magic import ntpath # from C:\PYTHON20\lib\ntpath.py # wrote C:\PYTHON20\lib\ntpath.pyc # C:\PYTHON20\lib\stat.pyc has bad magic import stat # from C:\PYTHON20\lib\stat.py # wrote C:\PYTHON20\lib\stat.pyc # C:\PYTHON20\lib\string.pyc has bad magic import string # from C:\PYTHON20\lib\string.py # wrote C:\PYTHON20\lib\string.pyc import strop # builtin # C:\PYTHON20\lib\UserDict.pyc has bad magic import UserDict # from C:\PYTHON20\lib\UserDict.py # wrote C:\PYTHON20\lib\UserDict.pyc Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> That is, .pyc's don't work at all anymore on Windows: Python *always* thinks they have a bad magic number. Elsewhere? Also noticed that test_popen2 got broken on Windows after 2.0b2, for a very weird reason: C:\Code\python\dist\src\PCbuild>python ../lib/test/test_popen2.py Test popen2 module: testing popen2... testing popen3... Traceback (most recent call last): File "../lib/test/test_popen2.py", line 64, in ? main() File "../lib/test/test_popen2.py", line 23, in main popen2._test() File "c:\code\python\dist\src\lib\popen2.py", line 188, in _test for inst in _active[:]: NameError: There is no variable named '_active' C:\Code\python\dist\src\PCbuild> C:\Code\python\dist\src\PCbuild>python ../lib/popen2.py testing popen2... testing popen3... Traceback (most recent call last): File "../lib/popen2.py", line 195, in ? _test() File "../lib/popen2.py", line 188, in _test for inst in _active[:]: NameError: There is no variable named '_active' C:\Code\python\dist\src\PCbuild> Ah! That's probably because of this clever new code: if sys.platform[:3] == "win": # Some things don't make sense on non-Unix platforms. del Popen3, Popen4, _active, _cleanup If I weren't on vacation, I'd check in a fix <wink>.

2 1

Python-Dev] Patch to avoid conflict with older versions of Python.
by Martin v. Loewis 29 Sep '00

29 Sep '00

> but do we want this sort of code in Python? Since I proposed a more primitive approach to solve the same problem (which you had postponed), I'm obviously in favour of that patch. > Is this sort of hack, however clever, going to some back and bite us? I can't see why. The code is quite defensive: If the data structures don't look like what it expects, it gives up and claims it can't find the version of the python dll used by this module. So in worst case, we get what we have now. My only concern is that it assumes the HMODULE is an address which can be dereferenced. If there was some MS documentation stating that this is guaranteed in Win32, it'd be fine. If it is merely established fact that all Win32 current implementations implement HMODULE that way, I'd rather see a __try/__except around that - but that would only add to the defensive style of this patch. A hack is required since earlier versions of Python did not consider this problem. I don't know whether python20.dll will behave reasonably when loaded into Python 2.1 next year - was there anything done to address the "uninitialized interpreter" problem? > if people like it, is this feature something we can squeeze in for > 2.0? I think this patch will have most value if applied to 2.0. When 2.1 comes along, many people will have been bitten by this bug, and will know to avoid it - so it won't do that much good in 2.1. I'm not looking forward to answering all the help(a)python.org messages to explain why Python can't deal with versions properly, so I'd rather see these people get a nice exception instead of IDLE silently closing all windows [including those with two hours of unsaved work]. Regards, Martin P.S db3l is David Bolen, see http://sourceforge.net/users/db3l.

1 0

.pyc broken on Windows -- anywhere else?
by Mark Favas 29 Sep '00

29 Sep '00

Tim writes: That is, .pyc's don't work at all anymore on Windows: Python *always* thinks they have a bad magic number. Elsewhere? Just grabbed the latest from CVS - .pyc is still fine on Tru64 Unix... Mark -- Email - m.favas(a)per.dem.csiro.au Postal - Mark C Favas Phone - +61 8 9333 6268, 041 892 6074 CSIRO Exploration & Mining Fax - +61 8 9387 8642 Private Bag No 5 Wembley, Western Australia 6913

4 6

2.0b2 on Slackware 7.0
by Fred L. Drake, Jr. 28 Sep '00

28 Sep '00

I just built and tested 2.0b2 on Slackware 7.0, and found that threads failed miserably. I got the message: pthread_cond_wait: Interrupted system call over & over (*hundreds* of times before I killed it) during one of the tests (test_fork1.py? it scrolled out of the scollback buffer, 2000 lines). If I configure it --without-threads it works great. Unless you need threads. uname -a says: Linux linux1.compile.sourceforge.net 2.2.14-5.0.14smp #1 SMP Sun Mar 26 13:03:52 PST 2000 i686 unknown ldd ./python says: libdb.so.3 => /lib/libdb.so.3 (0x4001c000) libdl.so.2 => /lib/libdl.so.2 (0x40056000) libutil.so.1 => /lib/libutil.so.1 (0x4005a000) libm.so.6 => /lib/libm.so.6 (0x4005d000) libc.so.6 => /lib/libc.so.6 (0x4007a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) If anyone has any ideas, please send them along! I'll turn this into a real bug report later. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

2 1

Python 2.0 beta 2 pre-release
by Jeremy Hylton 28 Sep '00

28 Sep '00

We have tar balls and RPMs available on our private FTP site, python.beopen.com. If you have a chance to test these on your platform in the next couple of hours, feedback would be appreciated. We've tested on FreeBSD and RH and Mandrake Linux. What we're most interested in hearing about is whether it builds cleanly and runs the regression test. The actual release will occur later today from pythonlabs.com. Jeremy

11 38

Dynamically loaded extension modules on MacOS X
by Martin v. Loewis 28 Sep '00

28 Sep '00

Has anybody succeeded in building extension modules for 2.0b1 on MacOS X? On xml-sig, we had a report that the pyexpat module would not build dynamically when building was initiated by the distutils, see the report in http://sourceforge.net/bugs/?func=detailbug&bug_id=115544&group_id=6473 Essentially, Python was configured with "-with-threads -with-dyld -with-suffix=.exe", which causes extension modules to be linked as cc -bundle -prebind {object files} -o {target}.so With this linker line, the linker reported /usr/bin/ld: warning -prebind has no effect with -bundle and then /usr/bin/ld: Undefined symbols: _PyArg_ParseTuple _PyArg_ParseTupleAndKeywords ...*removed a few dozen more symbols*... So apparently the command line options are bogus for the compiler, which identifies itself as Reading specs from /usr/libexec/ppc/2.95.2/specs Apple Computer, Inc. version cc-796.3, based on gcc driver version 2.7.2.1 executing gcc version 2.95.2 Also, these options apparently won't cause creation of a shared library. I wonder whether a simple "cc -shared" won't do the trick - can a Mac expert enlighten me? Regards, Martin

1 0

Distutils 1.0 code freeze: Oct 1
by Greg Ward 28 Sep '00

28 Sep '00

Considering the following schedule of events: Oct 4: I go out of town (away from email, off the net, etc.) Oct 10: planned release of Python 2.0 Oct 12: I'm back in town, ready to hack! (and wondering why it's so quiet around here...) the Distutils 1.0 release will go out October 1 or 2. I don't need quite as much code freeze time as the full Python release, but let's put it this way: if there are features you want added to the Distutils that I don't already know about, forget about it. Changes currently under consideration: * Rene Liebscher's rearrangement of the CCompiler classes; most of this is just reducing the amount of code, but it does add some minor features, so it's under consideration. * making byte-compilation more flexible: should be able to generate both .pyc and .pyo files, and should be able to do it at build time or install time (developer's and packager's discretion) If you know about any outstanding Distutils bugs, please tell me *now*. Put 'em in the SourceForge bug database if you're wondering why I haven't fixed them yet -- they might have gotten lost, I might not know about 'em, etc. If you're not sure, put it in SourceForge. Stuff that will definitely have to wait until after 1.0: * a "test" command (standard test framework for Python modules) * finishing the "config" command (auto-configuration) * installing package meta-data, to support "what *do* I have installed, anyways?" queries, uninstallation, upgrades, etc. Blue-sky projects: * standard documentation processing * intra-module dependencies Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

2 1

Re: [Python-Dev] FW: regarding the Python Developer posting...
by Dan Wolfe 28 Sep '00

28 Sep '00

>> [Seg faults in test_sre.py while testing limits] >> >you could try adding a Mac OS clause to the recursion limit stuff >in Modules/_sre.c: > >#if !defined(USE_STACKCHECK) >#if defined(...whatever's needed to detect Max OS X...) >#define USE_RECURSION_LIMIT 5000 >#elif defined(MS_WIN64) || defined(__LP64__) || defined(_LP64) >/* require smaller recursion limit for a number of 64-bit platforms: > Win64 (MS_WIN64), Linux64 (__LP64__), Monterey (64-bit AIX) (_LP64) */ >/* FIXME: maybe the limit should be 40000 / sizeof(void*) ? */ >#define USE_RECURSION_LIMIT 7500 >#else >#define USE_RECURSION_LIMIT 10000 >#endif >#endif > >replace "...whatever...", and try larger values than 5000 (or smaller, >if necessary. 10000 is clearly too large for your platform). > >(alternatively, you can increase the stack size. maybe it's very small >by default?) Hi /F, I spotted the USE_STACKCHECK, got curious, and went hunting for it... of course curiousity kills the cat... it's time to got to work now.... meaning that the large number of replies, counter-replies, code and follow up that I'm going to need to wade thru is going to have to wait. Why you ask, well when you strip Mac OS X down to the core... it's unix based and therefore has the getrusage command... which means that I need to take a look at some of the patches - <http://sourceforge.net/patch/download.php?id=101352> In the Public Beta the stack size is currently set to 512K by default... which is usually enough for most processes... but not sre... I-should-have-stayed-up-all-night'ly yours, - Dan

1 0

Python 2.0 beta 2 pre-release
by Mark Favas 28 Sep '00

28 Sep '00

Jeremy writes... We'll have to be a lot more careful about the 2.0 final release. PEP 200 has a tenative ship date of Oct. 10. We should probably have a code freeze on Oct. 6 and leave the weekend and Monday for verifying that there are no build problems on little- and big-endian platforms. ... and 64-bit platforms (or those where sizeof(long) != sizeof(int) != 4) <grin> - a change yesterday to md5.h caused a compilation failure. Logged as http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470 -- Mark Favas - m.favas(a)per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA

2 1