Mailman 3 October 2002 - Python-Dev

Python 2.2.2b1 checkin freeze
by Guido van Rossum 08 Oct '02

08 Oct '02

I've committed the last changes for Python 2.2.2b1 -- the Misc/NEWS file. I'm now going to follow the rest of the PEP 102 script until the release is done. In the mean time, please no more checkins to the 2.2 branch! --Guido van Rossum (home page: http://www.python.org/~guido/)

5 6

Re: [Python-Dev] tests failing in 2.2.2
by Tim Peters 08 Oct '02

08 Oct '02

[Tim] >> If we changed the test to use maxint // 2 instead, it would >> (just barely) trigger the >> >> _new_size <= ((~(size_t)0) / sizeof(type)) >> >> test in NRESIZE instead, and keep the platform realloc() out of it. >> >> Good enough? [Guido] > I'd say so, except I fear that it might cause different problems > (not that I know of any). I tried it on Linux and on Win98 > and it works fine. I presume you've tested it on Win2K. Not really, but I watched what it *would* have done <wink> in the debugger. > But wasn't it specifically designed to catch a condition that was > only true when the size was (approximately) maxint/4? If that was the intent, then Martin was right that it's not catching what it intended to catch: as written, it goes to the platform realloc. The only place it *could* get caught before going to the platform realloc is in the snippet of code from NRESIZE I included above. The suggested change would (just barely) trigger that code instead, and we wouldn't invoked the platform realloc() at all then. There are no other interesting conditions I know of, or can find in the code.

1 0

Re: [Python-Dev] Warning about use of long double - what's the correct approach?
by Michael Hudson 08 Oct '02

08 Oct '02

Skip Montanaro <skip(a)pobox.com> writes: > When building from CVS head, I get this warning for each file compiled: On Mac OS X, right? > gcc -c -DNDEBUG -g -I. -I../Include -DPy_BUILD_CORE -o Objects/rangeobject.o ../Objects/rangeobject.c > In file included from ../Include/Python.h:70, > from ../Objects/rangeobject.c:3: > ../Include/objimpl.h:252: warning: use of `long double' type; its size may change in a future release > ../Include/objimpl.h:252: warning: (Long double usage is reported only once for each file. > ../Include/objimpl.h:252: warning: To disable this warning, use -Wno-long-double.) > > The culprit is the long double alignment field in: > > /* GC information is stored BEFORE the object structure. */ > typedef union _gc_head { > struct { > union _gc_head *gc_next; > union _gc_head *gc_prev; > int gc_refs; > } gc; > long double dummy; /* force worst-case alignment */ > } PyGC_Head; > > I don't know what the best way to fix this is. Should I look at making > configure add -Wno-long-double in the proper situations or should that > alignment field be something else in situations where the use of long double > would generate a warning? I thought that's what configure already did: case $ac_sys_system in Darwin*) OPT="$OPT -Wno-long-double -no-cpp-precomp";; esac If I've guessed wrong and you're not on OS X, give us some help :) Cheers, M. -- I'm sorry, was my bias showing again? :-) -- William Tanksley, 13 May 2000

3 4

Re: [Python-Dev] Re: [snake-farm] Autodetect /usr/ccs/bin?
by Michael Hudson 08 Oct '02

08 Oct '02

Skip Montanaro <skip(a)pobox.com> writes: > >> Should the configure script try with /usr/ccs/bin/ar and ld if none > >> is explicitly supplied? > > I think you should add /usr/ccs/{lib,bin,include} and /sw/{lib,bin,include} > to places you automatically search for "useful stuff". As Anders pointed > out, /usr/ccs is something of a standard among the more proprietary of the > Unix platforms. /sw/... is where the fink gang installs all the various GNU > goodies on MacOS X. While you won't need to search /sw/bin for ar and ld, > you might well find useful third-party libraries there which various wrapper > modules can use. When I configured XEmacs without asking it to look in > /sw/... it came up with a fairly feeble configuration (no jpeg or png > support). That said, perhaps the /sw thing will work with a simple change > to setup.py. I'm testing a change right now to see if my build picks up > readline or not. If this is your change: Index: setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.111 diff -c -r1.111 setup.py *** setup.py 25 Sep 2002 14:59:57 -0000 1.111 --- setup.py 8 Oct 2002 10:01:00 -0000 *************** *** 229,234 **** --- 229,236 ---- # Ensure that /usr/local is always used add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') + add_dir_to_list(self.compiler.library_dirs, '/sw/lib') + add_dir_to_list(self.compiler.include_dirs, '/sw/include') if os.path.normpath(sys.prefix) != '/usr': add_dir_to_list(self.compiler.library_dirs, It will. This is so easy, I don't think it's worth bothering with in the core... Cheers, M. -- Considering that this thread is completely on-topic in the way only c.l.py threads can be, I think I can say that you should replace "Oblivion" with "Gravity", and increase your Radiohead quotient. -- Ben Wolfson, comp.lang.python

2 1

Re: [Python-Dev] Set-next-statement in Python debuggers
by Michael Hudson 08 Oct '02

08 Oct '02

richie(a)entrian.com writes: > I was interested to see Armin's patch [617312] to "allow the C > profile and trace functions to alter some fields of the current > PyFrameObject". > > I'm writing a Python debugger, and as Armin says, his patch "could > also be used by advanced debuggers to allow the execution point to > be modified by the user." A "Set-next-statement" feature is on my > list of nice-to-have-but-hard-to-do jobs, and this patch could make > it easy. (I know the blockstack presents a problem, but if it's > insurmountable I'm happy to ignore that and to only allow skipping > to lines in the same block - 90% of my use of the equivalent feature > in MSVC is to skip back one line or forward one line.) > > There's one fly in the ointment - I'm trying to keep my debugger in > pure Python, and Armin's patch only applies to C trace functions. > If frame.f_lasti were writable by Python trace functions, pure > Python debuggers (including pdb) could implement Set-Next-Statement. > > Here's a small script that demonstrates what I mean, and the > one-line patch to frameobject.c that enables it: [...] > For completeness, f_lineno should probably be writable as well, but > I'm keeping the changes minimal for the purposes of discussion. I'd prefer a different approach; make f_lasti a descriptor so you can do some sanity checking on the values (i.e. fits in the f_code.co_code, actually is an opcode boundary and sets f_lineno). > Is this a reasonable suggestion for 2.3, or is it giving people too > much rope? A nasty consequence is that you can write Python code > that causes Python to seg-fault, but you have to be doing some > fairly advanced stuff for that to happen. > > I would say that the power of a Set-next-statement feature in pdb > and other debuggers is worth the price, but others may disagree...? Hmm. Not sure. Given all the ways Armin's just found to make the interpreter crap out, one more doesn't seem that exciting -- but perhaps this is the wrong attitude... Cheers, M. -- I'm not sure that the ability to create routing diagrams similar to pretzels with mad cow disease is actually a marketable skill. -- Steve Levin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

1 0

Bug #537450 Improper object initialization for type.__new__
by Kevin Jacobs 08 Oct '02

08 Oct '02

Hi Guido and python-dev, Python 2.2.2 beta 1 is coming out, and I was hoping to float a final request to have the fix for bug #537450 applied to the 2.2 maint branch (it is a trivial backport, since the 2.3 patch applies just fine). A back-port was originally passed over, because it changes semantics from Python 2.2.1. I argue that the changed semantics are desirable and constitute a clear bug fix, which closes holes that can allow very obscure errors. It would be very surprising to me if this change breaks any extant code, since it is virtually impossible to take meaningful or safe advantage of the original semantics. Here is, in brief, an example of what I am talking about (the bug and python-dev archives have more information on this topic). Let's define a class Foo: class Foo(object): def __new__(cls): return [1,2,3] print Foo() Okay, this _is_ a contrived example, though it does reflects a real use-case that appears in one of my large real-world apps. Here is the output from Python 2.2.1: >>> print Foo() [] # !!! not what we expected! and from Python 2.3 CVS: >>> print Foo() [1, 2, 3] # Just right! This is because any object returned from __new__ has its constructor called, regardless of its type in 2.2.1. The new rule in Python 2.3 CVS is that the constructor is only called when the type returned is an instance of the type being built (including subtype instances). The above example demonstrates the problems with the 2.2.1 behavior on lists, though more problems are exposed when we consider other object types: class Bar(object): def __init__(self, a, b, c): pass class Foo(object): def __new__(cls,a): if a: return Bar(1,2,3) else: return super(Foo, cls).__new__(cls) Here is what happens in Python 2.3 CVS: >>> print Foo(0) <__main__.Foo object at 0x402baf0c> >>> print Foo(1) <__main__.Bar object at 0x402bab6c> All looks as it should, based on the discussions from when bug #537450 was last discussed. Here is what happens in Python 2.2.1 (and the current 2.2.2 CVS): >>> print Foo(0) <__main__.Foo object at 0x8174434> >>> print Foo(1) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __init__() takes exactly 4 arguments (2 given) In the first case where a=0, the super-class new is called, and a Foo instance is returned. All is fine, so far. However, the second case returns an initialized Bar instance, which Foo tries to initialize again by calling Bar.__init__ with the same arguments that were passed into Foo.__new__. An arity error results, which is actually a good thing, since arbitrarily calling another object's constructor with arguments passed in for another object is a decidedly bad thing to do in general. The more severe problem occurs when the arguments do conform, and an instance of an improperly constructed object is returned. Either way, Bar is initialized _twice_, once with the intended arguments, another with arguments that were intended for Foo! I assert that no sensible developer would ever write code that relied on the pre-2.3 CVS semantics. I've done a survey of much of the meta-class code posted to or discussed on Python-dev and comp.lang.python, and none rely on this behavior. Plus, even if they did, we have already decided they will have to change it when 2.3 comes out. If you are not entirely convinced by the above argument, please consider a compromise solution: put the fix in for 2.2.1 Beta 1. If anyone has complaints based on extant code, then we can always back it out for Beta 2, or the final release. Thanks for taking the time... -Kevin Jacobs -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs(a)theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com

5 20

Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.44,1.44.6.1
by Michael Hudson 08 Oct '02

08 Oct '02

mwh(a)users.sourceforge.net writes: > Index: sysconfig.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/distutils/sysconfig.py,v > retrieving revision 1.44 > retrieving revision 1.44.6.1 > diff -C2 -d -r1.44 -r1.44.6.1 > *** sysconfig.py 6 Dec 2001 20:51:35 -0000 1.44 > --- sysconfig.py 7 Oct 2002 10:38:33 -0000 1.44.6.1 > *************** > *** 24,40 **** > EXEC_PREFIX = os.path.normpath(sys.exec_prefix) > > ! # Boolean; if it's true, we're still building Python, so > ! # we use different (hard-wired) directories. > ! > ! python_build = 0 > ! > ! def set_python_build(): > ! """Set the python_build flag to true. > > ! This means that we're building Python itself. Only called from > ! the setup.py script shipped with Python. > ! """ > ! global python_build > python_build = 1 Hmm, I wonder if I should put a do-nothing set_python_build back in for 2.2.2. Does anyone call this from their build scripts? I guess it's possible... Cheers, M. -- GET *BONK* BACK *BONK* IN *BONK* THERE *BONK* -- Naich using the troll hammer in cam.misc

2 1

Warning about use of long double - what's the correct approach?
by Skip Montanaro 08 Oct '02

08 Oct '02

When building from CVS head, I get this warning for each file compiled: gcc -c -DNDEBUG -g -I. -I../Include -DPy_BUILD_CORE -o Objects/rangeobject.o ../Objects/rangeobject.c In file included from ../Include/Python.h:70, from ../Objects/rangeobject.c:3: ../Include/objimpl.h:252: warning: use of `long double' type; its size may change in a future release ../Include/objimpl.h:252: warning: (Long double usage is reported only once for each file. ../Include/objimpl.h:252: warning: To disable this warning, use -Wno-long-double.) The culprit is the long double alignment field in: /* GC information is stored BEFORE the object structure. */ typedef union _gc_head { struct { union _gc_head *gc_next; union _gc_head *gc_prev; int gc_refs; } gc; long double dummy; /* force worst-case alignment */ } PyGC_Head; I don't know what the best way to fix this is. Should I look at making configure add -Wno-long-double in the proper situations or should that alignment field be something else in situations where the use of long double would generate a warning? Skip

2 2

RELEASED: Python 2.2.2b1
by Guido van Rossum 08 Oct '02

08 Oct '02

I'm happy to announce the release of Python 2.2.2 beta 1. Python 2.2.2 will be a fully backwards compatible bugfix release for Python 2.2.1. I'm shooting for a short beta test cycle: hopefully I can make the final 2.2.2 release next week with minimal changes from 2.2.2b1. Python 2.2.2 has a large number of bug fixes in all areas of the interpreter and the library; for a full account see the release notes, available via the link below. The new release is available here: http://www.python.org/2.2.2/ As usual, a Windows installer and a Unix/Linux source tarball are made available, as well as tarballs of the documentation in various forms. At the moment, no Mac version is available, though I expect that Jack Jansen will start working on one soon. Likewise, no Linux RPMs are available; I expect that Sean Reifschneider will prepare Linux RPMs for 2.2.2 final. I'm especially grateful to Michael Hudson, Raymond Hettinger and Neal Norwitz for their hard work on backporting the large volume of patches from Python 2.3. Without them this release would not have been possible. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 3

RE: [Python-Dev] [win32] Killing MSVC's _alloca
by Delaney, Timothy 08 Oct '02

08 Oct '02

> From: Guido van Rossum [mailto:guido@python.org] > > I don't understand. How many Unix emulations on Windows do we need? > We've already absorbed a sheer endless set of patches to make it work > on CYGWIN. How does Mingw differ? None at all. MinGW is not a Unix emulation. There is a minimal shell environment (MSYS) which works with MinGW (allowing use of the autoconf/make toolchain) but the produced binaries have no reliance on anything except the native win32 libraries. I was recently trying to use MinGW to compile Python CVS at home - I don't own, not will I pay for MSVC++. I occasionally have to use it at work, but only from the command line ;) I gave up when it got into posixmodule.c and there was lots of stuff there I didn't know about. I personally am very pleased that Gerhard is working so hard to make this a viable compilation option on Windows. http://www.mingw.org/ http://www.mingw.org/msys.shtml Tim Delaney

3 2