Mailman 3 December 2001 - Python-Dev

Release criteria
by Martin von Loewis Dec. 2, 2001

Dec. 2, 2001

Now that there are only ten days left for the release candidate, I wonder whether there are any release criteria beyond "builds on Windows". In particular, I think that the release candidate should not be produced until "critical" SF bugs have been resolved. In #420851, Barry indicates that bugs with a priority higher than six will block a release. This sounds reasonable. Looking at the remaining bugs, we see Priority 8: two reports (assigned to loewis and nobody) Priority 7: 11 reports (6x … [View More]

6 6

test_builtin failing? or just 64-bit platforms
by Mark Favas Dec. 2, 2001

Dec. 2, 2001

Anyone else getting test_builtin failures with current CVS, or does it only show on 64-bit platforms? Changes in the past week seem to have caused the failure. Isolated to following (will post bug on SF): ***** older CVS works ***** 201 mark(a)gonzo.per.dem.csiro.au python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-… [View More]

7 16

Differentiating $(EXT) between build and install
by Jack Jansen Dec. 2, 2001

Dec. 2, 2001

Folks, there's so many bug reports and questions about needing the --with-suffix on Mac OS X when you're building on an HFS+ filesystem that I'd like to fix this. The warning in configure doesn't cut it because it gets lost in all the other messages. What I'd like to do is have a separate Makefile variable, BUILDEXT, that gives the extension to use for python while it lives in the build directory. It would default to EXT, except if on HFS+ when EXT is empty. But this might change a couple of … [View More]

2 1

REMOVE !!
by adam Dec. 2, 2001

Dec. 2, 2001

----- Original Message ----- From: <python-dev-request(a)python.org> To: <python-dev(a)python.org> Sent: Saturday, December 01, 2001 6:33 AM Subject: Python-Dev digest, Vol 1 #1748 - 15 msgs > Send Python-Dev mailing list submissions to > python-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-dev > or, via email, send a message with subject or body 'help' to > python-dev-request(a)… [View More]python.org > > You can reach the person managing the list at > python-dev-admin(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-Dev digest..." > > > Today's Topics: > > 1. ArtifactFile: I can't change my patch files (James C. Ahlstrom) > 2. Re: problems with DBM nonuniformity (Jason R. Mastaler) > 3. Re: -DINET6 in Makefile (Martin v. Loewis) > 4. Re: -DINET6 in Makefile (M.-A. Lemburg) > 5. RE: gc.garbage (Tim Peters) > 6. RE: gc.garbage (Tim Peters) > 7. RE: Subclassing varying length types (What's a PyStructSequence ?) (Tim Peters) > 8. Re: -DINET6 in Makefile (Martin v. Loewis) > 9. Re: gc.garbage (Martin v. Loewis) > 10. test_builtin failing? or just 64-bit platforms (Mark Favas) > 11. RE: test_builtin failing? or just 64-bit platforms (Tim Peters) > 12. Re: test_builtin failing? or just 64-bit platforms (Guido van Rossum) > 13. RE: test_builtin failing? or just 64-bit platforms (Tim Peters) > 14. RE: test_builtin failing? or just 64-bit platforms (Barry A. Warsaw) > 15. RE: test_builtin failing? or just 64-bit platforms (Tim Peters) > > --__--__-- > > Message: 1 > Date: Fri, 30 Nov 2001 12:07:03 -0500 > From: "James C. Ahlstrom" <jim(a)interet.com> > To: python-dev(a)python.org > Subject: [Python-Dev] ArtifactFile: I can't change my patch files > > I am trying to replace files in my patch #483466, but > I am getting > > File delete: ArtifactFile: Permission Denied > > on SourceForge. If I need to be a member of the Python > project to do this, could someone please add me? Or > tell me what's wrong? > > The new files implement the changes to sys.path[0] > that we have been discussing. I still need to make > further changes to import.c so that "" and relative > paths are handled. So don't install this patch yet, > but look it over for problems if you want. > > Jim > > > --__--__-- > > Message: 2 > To: python-list(a)python.org, python-dev(a)python.org, > Date: Fri, 30 Nov 2001 10:17:24 -0700 > From: "Jason R. Mastaler" <jason-dated-1007831845.6c6a51(a)mastaler.com> > Subject: [Python-Dev] Re: problems with DBM nonuniformity > > Skip Montanaro <skip(a)pobox.com> writes: > > > Seems to me the natural thing to do would be to add > > "get_data_filename" and "get_index_filename" methods (or something > > similar) to the underlying modules (dbhash, bsddb, dbm, etc) and > > expose them through anydbm. > > I see. So you agree that with the current implementation, there isn't > a reliable way to do what I'm trying to do with DBM? > > > It's too late for 2.2, but I suspect if you implemented something > > and method name(s) could be settled on it would make it into CVS > > early in the 2.3 cycle. This seems like a small enough change that > > you just file a bug report on SourceForge with the proposal and add > > an implementation when you have something workable. > > I'm not sure when I'll be able to get to this, but I'll put it on my > TODO list. In the meantime, I think I'll just support the auto > regeneration feature I mentioned with CDB[1] instead of DBM since its > file interface is consistent across platforms. > > Footnotes: > 1. python-cdb extension module (http://pilcrow.madison.wi.us/) > > -- > (TMDA - http://tmda.sourceforge.net) > (Python-based SPAM reduction system) > > > --__--__-- > > Message: 3 > Date: Fri, 30 Nov 2001 21:22:24 +0100 > From: "Martin v. Loewis" <martin(a)v.loewis.de> > To: mal(a)lemburg.com > CC: python-dev(a)python.org > Subject: Re: [Python-Dev] -DINET6 in Makefile > > > What's the reasoning behind putting -DINET6 into the default > > compiler options of the generic Makefile ? > > I believe the sole reason is that the author of the patch didn't know > how to get it into pyconfig.h. itojun recently confirmed that all uses > of the INET6 can be replaced with ENABLE_IPV6, and that the define may > go away. > > I hesitate to change that, though, since some of the IPv6 > implementations *may* require that INET6 is defined when processing > the "system" headers (not all IPv6 implementations we support actually > come with the operating system). > > > I'm just asking because such a define will be inherited by > > all extensions being compiled with distutils and the Makefile.pre.in > > setup process... sounds like trouble if you ask me. > > What kind of trouble? > > > Shouldn't the define be placed into the pyconfig.h file or > > only in those extensions which need it ? > > Wouldn't it cause the same trouble there? > > Regards, > Martin > > > --__--__-- > > Message: 4 > Date: Fri, 30 Nov 2001 21:46:14 +0100 > From: "M.-A. Lemburg" <mal(a)lemburg.com> > Organization: eGenix.com Software GmbH > To: "Martin v. Loewis" <martin(a)v.loewis.de> > CC: python-dev(a)python.org > Subject: Re: [Python-Dev] -DINET6 in Makefile > > "Martin v. Loewis" wrote: > > > > > What's the reasoning behind putting -DINET6 into the default > > > compiler options of the generic Makefile ? > > > > I believe the sole reason is that the author of the patch didn't know > > how to get it into pyconfig.h. itojun recently confirmed that all uses > > of the INET6 can be replaced with ENABLE_IPV6, and that the define may > > go away. > > > > I hesitate to change that, though, since some of the IPv6 > > implementations *may* require that INET6 is defined when processing > > the "system" headers (not all IPv6 implementations we support actually > > come with the operating system). > > For Python's own use, it should suffice defining the symbol in > pyconfig.h. > > > > I'm just asking because such a define will be inherited by > > > all extensions being compiled with distutils and the Makefile.pre.in > > > setup process... sounds like trouble if you ask me. > > > > What kind of trouble? > > The symbol could enable some logic which may not be desired > by the application, e.g. cause system includes to change, > socket semantics of wrapped libs could also be affected etc. > > > > Shouldn't the define be placed into the pyconfig.h file or > > > only in those extensions which need it ? > > > > Wouldn't it cause the same trouble there? > > No, because the pyconfig.h import is under extension control > (e.g. you can first include the system or lib header files > and only then import pyconfig.h). > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Consulting & Company: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > > --__--__-- > > Message: 5 > From: "Tim Peters" <tim.one(a)home.com> > To: "Neil Schemenauer" <nas(a)python.ca>, > "PythonDev" <python-dev(a)python.org> > Subject: RE: [Python-Dev] gc.garbage > Date: Fri, 30 Nov 2001 18:30:43 -0500 > > [Neil Schemenauer] > > Is there some way to prevent people from assigning to certain module > > variables? > > [Tim] > >> Not that I know of. If you're terribly concerned, gc could look up > >> "garbage" in its dict on each access. That's what, e.g., > >> PRINT_ITEM does with sys.stdout. ... > > [Neil] > > What would happen if it's not a list? PRINT_ITEM raises RuntimeError. > > I suppose the collector could do the same. > > Sure, that would be fine. > > >> But I'd be keener to see new words spelling out which parts of the gc > >> interface are and aren't intended "to work" across releases ... > > > All of them? :-) Seriously, there could come a time when GC can no > > longer be disabled. The debugging and threshold stuff is fairly > > implementation dependent. get_referrers() and get_objects() are highly > > implementation dependent. I suppose gc.collect() should always be > > available. Anything else is fair game, IMHO. > > I meant "new words" in the docs, not on Python-Dev <wink>. > > > Incidentally, I can't say I'm happy with GC as it stands. > > Well, you're young and hopeful -- you'll get over both. I have, and am > indeed happy with GC as it stands. > > > It uses too much memory now that so many objects are tracked. > > There I disagree, but subtly: it always used "too much" memory. The > marginal memory cost in adding a gazillion new tracked types was minor, as > very few programs have a gazillion frame objects or traceback objects or > generator-iterator objects (etc) sitting around. The vast bulk of the > damage was done the instant lists, tuples, dicts and instances got tracked. > So it goes. > > > I had worked on the idea of a separate heap for GC objects for a while > > but couldn't figure out how to make generational collection to work. > > Generational gimmicks are rare in non-copying collectors for this very > reason, right? > > > As Don Beaudry's sig says: "so much code, so little time". :-) > > Time for Don to change his sig -- his young and hopeful days should be long > gone by now too <wink>. > > > > --__--__-- > > Message: 6 > From: "Tim Peters" <tim.one(a)home.com> > To: <python-dev(a)python.org> > Subject: RE: [Python-Dev] gc.garbage > Date: Fri, 30 Nov 2001 18:30:44 -0500 > > [Martin v. Loewis] > > I wish the C API hadn't been changed for 2.2, rendering useless all > > code that had been created to support GC in 2.0 and 2.1. > > Would we really need more than one hand to count all that code <0.9 wink>? > > not-aware-of-any-myself-ly y'rs - tim > > > --__--__-- > > Message: 7 > From: "Tim Peters" <tim.one(a)home.com> > To: <python-dev(a)python.org> > Subject: RE: [Python-Dev] Subclassing varying length types (What's a PyStructSequence ?) > Date: Fri, 30 Nov 2001 18:35:23 -0500 > > [M.-A. Lemburg] > > ... > > Hmm, this makes me wonder: perhaps we should start thinking > > about phasing out varying length PyObjects in the interpreter... > > No chance, IMO: the memory savings is too great. > > > esp. the inability to subclass strings looks like a bummer for > > future extensions of this particular type. Unicode doesn't have > > this problem, BTW. > > OTOH, I know someone at Zope Corp who could testify with force about the > memory burden of switching to Unicode strings -- if you've got gobs of 'em, > it's much worse than a factor of 2 blowup. Moving to obmalloc.c should help > that a lot (two malloc overheads per Unicode string, and obmalloc overheads > are much lower). > > > Or we need to come up with a fairly nice way of making > > subclassing varying length types a lot easier, e.g. by > > adding a special pointer ob_ext to PyObject_VAR_HEAD > > which then allows declaring type extensions in an malloced > > buffer. > > > > Thoughts ? > > Not a one <wink>. > > > > --__--__-- > > Message: 8 > Date: Sat, 1 Dec 2001 02:07:19 +0100 > From: "Martin v. Loewis" <martin(a)v.loewis.de> > To: mal(a)lemburg.com > CC: python-dev(a)python.org > Subject: Re: [Python-Dev] -DINET6 in Makefile > > > > > Shouldn't the define be placed into the pyconfig.h file or > > > > only in those extensions which need it ? > > > > > > Wouldn't it cause the same trouble there? > > > > No, because the pyconfig.h import is under extension control > > (e.g. you can first include the system or lib header files > > and only then import pyconfig.h). > > Of course, doing so would be really stupid. Python.h *must* be the > first include, or things may break. > > Regards, > Martin > > > > --__--__-- > > Message: 9 > Date: Sat, 1 Dec 2001 02:11:34 +0100 > From: "Martin v. Loewis" <martin(a)v.loewis.de> > To: tim.one(a)home.com > CC: python-dev(a)python.org > Subject: Re: [Python-Dev] gc.garbage > > > [Martin v. Loewis] > > > I wish the C API hadn't been changed for 2.2, rendering useless all > > > code that had been created to support GC in 2.0 and 2.1. > > > > Would we really need more than one hand to count all that code <0.9 wink>? > > Mine was among it (in pyexpat), and I really hate looking at the code > now. Not only need I support two versions of Unicode (i.e. having or > not having it), but also three versions of GC, all in a single file. > > Regards, > Martin > > > --__--__-- > > Message: 10 > Date: Sat, 01 Dec 2001 09:55:49 +0800 > From: Mark Favas <mark.favas(a)csiro.au> > Organization: CSIRO > To: python-dev(a)python.org > Subject: [Python-Dev] test_builtin failing? or just 64-bit platforms > > Anyone else getting test_builtin failures with current CVS, or does it > only show on 64-bit platforms? Changes in the past week seem to have > caused the failure. Isolated to following (will post bug on SF): > > ***** older CVS works ***** > 201 mark(a)gonzo.per.dem.csiro.au python > Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> s=-1-sys.maxint > >>> d=`s` > >>> d > '-9223372036854775808' > >>> s > -9223372036854775808 > >>> ^D > > ***** current CVS fails ***** > 202 mark(a)gonzo.per.dem.csiro.au cd dist/src > 203 mark(a)gonzo.per.dem.csiro.au ./python > Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> s=-1-sys.maxint > >>> d=`s` > >>> d > '8t\x10@\x01' > >>> s > -9223372036854775808 > >>> ^D > > > -- > Mark Favas - m.favas(a)per.dem.csiro.au > CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA > > > --__--__-- > > Message: 11 > From: "Tim Peters" <tim.one(a)home.com> > To: "Mark Favas" <mark.favas(a)csiro.au>, > <python-dev(a)python.org> > Subject: RE: [Python-Dev] test_builtin failing? or just 64-bit platforms > Date: Fri, 30 Nov 2001 21:41:56 -0500 > > [Mark Favas] > > Anyone else getting test_builtin failures with current CVS, > > No. > > > or does it only show on 64-bit platforms? Changes in the past week > > seem to have caused the failure. Isolated to following (will post bug > > on SF): > > Thanks! > > > ***** older CVS works ***** > > 201 mark(a)gonzo.per.dem.csiro.au python > > Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import sys > > >>> s=-1-sys.maxint > > >>> d=`s` > > >>> d > > '-9223372036854775808' > > >>> s > > -9223372036854775808 > > >>> ^D > > > > ***** current CVS fails ***** > > 202 mark(a)gonzo.per.dem.csiro.au cd dist/src > > 203 mark(a)gonzo.per.dem.csiro.au ./python > > Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import sys > > >>> s=-1-sys.maxint > > >>> d=`s` > > >>> d > > '8t\x10@\x01' > > >>> s > > -9223372036854775808 > > >>> ^D > > It doesn't make sense, but it *smells* like a sprintf -> PyOS_snprintf > screwup ... OK, our int repr code has always been wrong(!): > > static PyObject * > int_repr(PyIntObject *v) > { > char buf[20]; > PyOS_snprintf(buf, sizeof(buf), "%ld", v->ob_ival); > return PyString_FromString(buf); > } > > 20 bytes isn't enough to hold the result on a 64-bit box (insert rant about > the idiot practice of trying to make stack buffers as small as possible). > You have 20 characters in your result, but need 21 to hold the trailing 0 > byte too. I don't know what snprintf does when there's not enough room, but > I think you just showed us what it does on Tru64 <wink>. > > Doing repr impllicitly instead works because that goes thru int_print > instead of int_repr. Doing repr explicitly "worked" before by accident (the > trailing null overwrite some random byte on the stack). Please change 20 to > 200(*) (or 64 -- your choice) and see whether that fixes it? > > > > --__--__-- > > Message: 12 > To: "Tim Peters" <tim.one(a)home.com> > cc: "Mark Favas" <mark.favas(a)csiro.au>, python-dev(a)python.org > Subject: Re: [Python-Dev] test_builtin failing? or just 64-bit platforms > From: Guido van Rossum <guido(a)python.org> > Date: Fri, 30 Nov 2001 22:01:24 -0500 > > > I don't know what snprintf does when there's not enough room, but > > I think you just showed us what it does on Tru64 <wink>. > > Hm, snprintf is *supposed* to truncate the result, but it seems that > here it refused to do anything. Maybe PyOS_snprintf should be a > wrapper that checks the return value of snprintf? I noticed that > *none* of the recently checked-in PyOS_snprintf calls have their > return value checked, and I think it's better to leave it that way > (since in many cases we really don't know what to do instead) -- maybe > PyOS_snprintf should even return void (or does it already?). > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > --__--__-- > > Message: 13 > From: "Tim Peters" <tim.one(a)home.com> > To: "Guido van Rossum" <guido(a)python.org> > Cc: "Mark Favas" <mark.favas(a)csiro.au>, > <python-dev(a)python.org> > Subject: RE: [Python-Dev] test_builtin failing? or just 64-bit platforms > Date: Fri, 30 Nov 2001 22:42:58 -0500 > > > Hm, snprintf is *supposed* to truncate the result, > > According to C99, yes, but MS has its own pre-C99 snprintf semantics, and > glibc has had at least two different versions. > > > but it seems that here it refused to do anything. Maybe PyOS_snprintf > > should be a wrapper that checks the return value of snprintf? > > Check it for what? We can't (at least not yet) count on uniform behavior > across platform snprintf implementations. > > > I noticed that *none* of the recently checked-in PyOS_snprintf calls > > have their return value checked, > > They were all derived (and most mindlessly) from existing sprintf calls that > didn't check either. A goal of this transformation was to change as little > as possible. > > > and I think it's better to leave it that way (since in many cases we > > really don't know what to do instead) -- maybe PyOS_snprintf should > > even return void (or does it already?). > > The comments suggest it wants to return the C99-defined value (an int, < 0 > for an encoding error, else the number of characters (excluding \0) written > if the size is big enough, else the number of characters that would have > been written (excluding \0) had size been big enough. So the output was > converted in full iff the return value is non-negative and strictly less > than the size passed in. That's fine by me, and I'll note that MS snprintf > meets that much too (if size isn't big enough, it returns a negative > result). So perhaps in a debug build PyOS_snprintf could assert that the > returned value is non-negative and less than the passed-in size ... > > > > --__--__-- > > Message: 14 > Date: Fri, 30 Nov 2001 23:17:31 -0500 > To: "Tim Peters" <tim.one(a)home.com> > Cc: "Mark Favas" <mark.favas(a)csiro.au>, <python-dev(a)python.org> > Subject: RE: [Python-Dev] test_builtin failing? or just 64-bit platforms > From: barry(a)zope.com (Barry A. Warsaw) > > > >>>>> "TP" == Tim Peters <tim.one(a)home.com> writes: > > TP> It doesn't make sense, but it *smells* like a sprintf -> > TP> PyOS_snprintf screwup ... OK, our int repr code has always > TP> been wrong(!): > > | static PyObject * > | int_repr(PyIntObject *v) > | { > | char buf[20]; > | PyOS_snprintf(buf, sizeof(buf), "%ld", v->ob_ival); > | return PyString_FromString(buf); > | } > > TP> 20 bytes isn't enough to hold the result on a 64-bit box > TP> (insert rant about the idiot practice of trying to make stack > TP> buffers as small as possible). You have 20 characters in your > TP> result, but need 21 to hold the trailing 0 byte too. I don't > TP> know what snprintf does when there's not enough room, but I > TP> think you just showed us what it does on Tru64 <wink>. > > Heh, I was going to suggest that this might be a good place to > substitute a call to PyString_FromFormat*() but then I read this > little nugget: > > case 'd': case 'i': case 'x': > (void) va_arg(count, int); > /* 20 bytes should be enough to hold a 64-bit > integer */ > n += 20; > break; > > love-ly y'rs, > -Barry > > > --__--__-- > > Message: 15 > From: "Tim Peters" <tim.one(a)home.com> > To: "Barry A. Warsaw" <barry(a)zope.com> > Cc: "Mark Favas" <mark.favas(a)csiro.au>, > <python-dev(a)python.org> > Subject: RE: [Python-Dev] test_builtin failing? or just 64-bit platforms > Date: Fri, 30 Nov 2001 23:31:51 -0500 > > [Barry] > > ... > > Heh, I was going to suggest that this might be a good place to > > substitute a call to PyString_FromFormat*() but then I read this > > little nugget: > > > > case 'd': case 'i': case 'x': > > (void) va_arg(count, int); > > /* 20 bytes should be enough to > > hold a 64-bit > > integer */ > > n += 20; > > break; > > This use of 20 is fine (I checked all occurrences of "20" in the codebase, > BTW); int_repr's use of 20 was wrong because it failed to allow for the > trailing \0 byte too; the loop in PyString_FromFormatV doesn't have to worry > about that (PyString_FromStringAndSize() later adds 1 of its own for the > trailing \0 -- of course it doesn't actually add anything, but it adds 1 "in > effect" <wink -- jeez, C string handling is obscure!>). > > > > > --__--__-- > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > > > End of Python-Dev Digest [View Less]

1 0

ExtensionClass plans (was Re: [ZODB-Dev] Another ExtensionClass incompatibility: __pow__())
by Jim Fulton Dec. 1, 2001

Dec. 1, 2001

Greg Ward wrote: > > Sigh. In addition to ignoring __r{add,sub,mul,div}__() methods, > ExtensionClass also calls __pow__() differently. (snip) > So what is the future of ExtensionClass, anyways? I intend that Python 2.2 (or maybe 2.3) will make it irrelevent. > Are the little > incompatibility bugs between classic Python classes and ExtensionClass > ever going to be fixed? Probably not by us. Patches are gratefully accepted. We are going to keep supporting it for … [View More]

1 0

gc.garbage
by Tim Peters Nov. 30, 2001

Nov. 30, 2001

I notice the gc docs say: The following variable is provided for read-only access: ^^^^^^^^^^^^^^^^ garbage A list of objects which the collector found to be unreachable ... This isn't clear to me. When I find finalizer cycles in gc.trash, I want to clean them up by breaking the cycles. Unless I remove the instances from gc.trash too, their appearance in that list keeps them alive despite that the cycles are broken. But "read-only … [View More]

5 8