Mailman 3 June 2000 - Python-Dev

build problems under MSVC 5.0
by Fredrik Lundh 28 Jul '00

28 Jul '00

Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier in MSVC 5.0, _beginthread returns an "unsigned long" (this is also how it's documented in MSDN). I suggest changing the declaration in thread_nt.h to: #if _MSC_VER >= 1200 INT_PTR rv; #else unsigned long rv; #endif on the other hand, the same docs claim that it returns -1 on errors. doesn't exactly look like an unsigned long to me, but that's another story... </F>

2 3

Sourceforge Interface Concerns
by Andy Robinson 10 Jul '00

10 Jul '00

I missed all the SourceForge discussions, but ReportLab have been running all our development on SourceForge for five months and I'd like to share some concerns. First, we all use command line CVS, mostly from Windows; I just posted our setup instructions. It works fine but a bit slowly. I find the web interface totally unusable from IE5 and Netscape 4.XX, working over 64k lines or dialup lines. Once one logs in via SSL, only about one click in five ever returns a sensible page, and most just time out and give an error message. Many other people on the reportlab-users list and my team report similar problems. On the other hand, many are incredulous and say they have never had a problem. I found no complaints on the SF discussion groups, but as far as I can tell hardly anyone uses them. It seems to be better over big corporate connections. I don't think it is because I am in Europe; we never have trouble with our US ISPs. As a result of this, we have not used the wonderful looking bug tracking, to-do-list, patch manager etc. How many people here have actually created accounts for themselves on SourceForge and tried to do stuff when logged in - raise bugs and so on? Did it work for you? We ought to get a few data points before making this the way Python is managed. - Andy Robinson

10 18

Patch management (was: Warnings in pythonrun.c)
by Andrew M. Kuchling 09 Jul '00

09 Jul '00

On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters <tim_one(a)email.msn.com> writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? <flame> Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. </flame> -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21

13 31

Comparison inconsistency with ExtensionClass
by Greg Ward 06 Jul '00

06 Jul '00

Hi all -- I seem to have discovered an inconsistency in the semantics of object comparison between plain old Python instances and ExtensionClass instances. (I've cc'd python-dev because it looks as though one *could* blame Python for the inconsistency, but I don't really understand the guts of either Python or ExtensionClass enough to know.) Here's a simple script that shows the difference: class Simple: def __init__ (self, data): self.data = data def __repr__ (self): return "<%s at %x: %s>" % (self.__class__.__name__, id(self), `self.data`) def __cmp__ (self, other): print "Simple.__cmp__: self=%s, other=%s" % (`self`, `other`) return cmp (self.data, other) if __name__ == "__main__": v1 = 36 v2 = Simple (36) print "v1 == v2?", (v1 == v2 and "yes" or "no") print "v2 == v1?", (v2 == v1 and "yes" or "no") print "v1 == v2.data?", (v1 == v2.data and "yes" or "no") print "v2.data == v1?", (v2.data == v1 and "yes" or "no") If I run this under Python 1.5.2, then all the comparisons come out true and my '__cmp__()' method is called twice: v1 == v2? Simple.__cmp__: self=<Simple at 1b5148: 36>, other=36 yes v2 == v1? Simple.__cmp__: self=<Simple at 1b5148: 36>, other=36 yes v1 == v2.data? yes v2.data == v1? yes The first one and the last two are obvious, but the second one only works thanks to a trick in PyObject_Compare(): if (PyInstance_Check(v) || PyInstance_Check(w)) { ... if (!PyInstance_Check(v)) return -PyObject_Compare(w, v); ... } However, if I make Simple an ExtensionClass: from ExtensionClass import Base class Simple (Base): Then the "swap v and w and use w's comparison method" no longer works. Here's the output of the script with Simple as an ExtensionClass: v1 == v2? no v2 == v1? Simple.__cmp__: self=<Simple at 1b51c0: 36>, other=36 yes v1 == v2.data? yes v2.data == v1? yes It looks as though ExtensionClass would have to duplicate the trick in PyObject_Compare() that I quoted, since Python has no idea that ExtensionClass instances really should act like instances. This smells to me like a bug in ExtensionClass. Comments? BTW, I'm using the ExtensionClass provided with Zope 2.1.4. Mostly tested with Python 1.5.2, but also under the latest CVS Python and we observed the same behaviour. Greg

4 3

Just spotted on SourceForge main page
by Greg Ward 03 Jul '00

03 Jul '00

Maybe this is what all you Windows folks are looking for. SFSetup v1 released mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 SFSetup is a program to automatically setup SSH and WinCVS for SourceForge projects under the Windows 32 platform. It's now available for download so if you have not yet set up SSH and WinCVS and want it done for you, you can use this program. Go to sfsetup.sourceforge.net to find out how to use it. It's open source and written in Delphi - the code is in CVS and any improvements are welcome! Thanks -mike -- Greg Ward - Linux nerd gward(a)python.net http://starship.python.net/~gward/ I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!!

3 2

Re: [Python-Dev] Test results of linuxaudiodev.c
by Michael Hudson 03 Jul '00

03 Jul '00

Ka-Ping Yee <pingster(a)ilm.com> writes: > On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > > Try setting the environment variable AUDIODEV to /dev/audio > > before running the test script. Does that work any better? > > Even if that works, i realize that's not the way the interface > was intended to be used. To play an AU file, the routine should > look something like this (not tested, as i don't have a working > Linux box)... [snip] Yup, that works fine. Don't understand the details - and as I have my graduation ceremony tomorrow I'm going to go to bed and leave learning them until some other occasion! Cheers, M. PS: my Lib/test/test_linuxaudiodev.py is now this: from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ... which is an improvement on what's there now.

4 3

RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
by Mark Hammond 01 Jul '00

01 Jul '00

> Making a tiny change to figure out what I'm going to screw up > by trying to use CVS under Windows at all ... Congratulations :-) Mark.

5 6

Hey! who changed sys.platform?!
by Greg Ward 01 Jul '00

01 Jul '00

Curses! I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this decision is made in the configure script. Does anyone know why it changed? This is not the end of the world, but the OS name alone is not really enough on a multi-architecture OS... ...back to calling os.uname() myself, I guess. ;-( Greg -- Greg Ward - programmer-at-big gward(a)python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man.

6 15

Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32
by Sjoerd Mullender 01 Jul '00

01 Jul '00

Why was the change that occurred in revision 2.31 reverted? Accident? The change log said: Jack Jansen: Use include "" instead of <>; and staticforward declarations On Fri, Jun 30 2000 "M.-A. Lemburg" wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg <mal(a)lemburg.com>: > New buffer overflow checks for formatting strings. > > By Trent Mick. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.31 > retrieving revision 2.32 > diff -C2 -r2.31 -r2.32 > *** unicodeobject.c 2000/06/29 00:06:39 2.31 > --- unicodeobject.c 2000/06/30 10:29:57 2.32 > *************** > *** 67,71 **** > #include "mymath.h" > #include "unicodeobject.h" > ! #include "ucnhash.h" > > #if defined(HAVE_LIMITS_H) > --- 67,71 ---- > #include "mymath.h" > #include "unicodeobject.h" > ! #include <ucnhash.h> > > #if defined(HAVE_LIMITS_H) > *************** > *** 1245,1249 **** > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > --- 1245,1249 ---- > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > *************** > *** 1252,1256 **** > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > --- 1252,1256 ---- > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > *************** > *** 4374,4377 **** > --- 4374,4378 ---- > static int > formatfloat(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4379,4382 **** > --- 4380,4385 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/ > char fmt[20]; > double x; > *************** > *** 4387,4395 **** > if (prec < 0) > prec = 6; > - if (prec > 50) > - prec = 50; /* Arbitrary limitation */ > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > } > --- 4390,4408 ---- > if (prec < 0) > prec = 6; > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > + /* worst case length calc to ensure no buffer overrun: > + fmt = %#.<prec>g > + buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp > + for any double rep.) > + len = 1 + prec + 1 + 2 + 5 = 9 + prec > + If prec=0 the effective precision is 1 (the leading digit is > + always given), therefore increase by one to 10+prec. */ > + if (buflen <= (size_t)10 + (size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted float is too long (precision too long?)"); > + return -1; > + } > return usprintf(buf, fmt, x); > } > *************** > *** 4397,4400 **** > --- 4410,4414 ---- > static int > formatint(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4402,4405 **** > --- 4416,4421 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + 'l' + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/ > char fmt[20]; > long x; > *************** > *** 4410,4413 **** > --- 4426,4436 ---- > if (prec < 0) > prec = 1; > + /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal)) > + worst case buf = '0x' + [0-9]*prec, where prec >= 11 */ > + if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted integer is too long (precision too long?)"); > + return -1; > + } > sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > *************** > *** 4416,4421 **** > static int > formatchar(Py_UNICODE *buf, > ! PyObject *v) > { > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > --- 4439,4446 ---- > static int > formatchar(Py_UNICODE *buf, > ! size_t buflen, > ! PyObject *v) > { > + /* presume that the buffer is at least 2 characters long */ > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > *************** > *** 4447,4450 **** > --- 4472,4485 ---- > } > > + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...) > + > + FORMATBUFLEN is the length of the buffer in which the floats, ints, & > + chars are formatted. XXX This is a magic number. Each formatting > + routine does bounds checking to ensure no overflow, but a better > + solution may be to malloc a buffer of appropriate size for each > + format. For now, the current solution is sufficient. > + */ > + #define FORMATBUFLEN (size_t)120 > + > PyObject *PyUnicode_Format(PyObject *format, > PyObject *args) > *************** > *** 4506,4513 **** > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *buf; > Py_UNICODE sign; > int len; > ! Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */ > > fmt++; > --- 4541,4548 ---- > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *pbuf; > Py_UNICODE sign; > int len; > ! Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */ > > fmt++; > *************** > *** 4659,4664 **** > > case '%': > ! buf = tmpbuf; > ! buf[0] = '%'; > len = 1; > break; > --- 4694,4700 ---- > > case '%': > ! pbuf = formatbuf; > ! /* presume that buffer length is at least 1 */ > ! pbuf[0] = '%'; > len = 1; > break; > *************** > *** 4696,4700 **** > goto onError; > } > ! buf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > --- 4732,4736 ---- > goto onError; > } > ! pbuf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > *************** > *** 4710,4715 **** > if (c == 'i') > c = 'd'; > ! buf = tmpbuf; > ! len = formatint(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4746,4752 ---- > if (c == 'i') > c = 'd'; > ! pbuf = formatbuf; > ! len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4719,4725 **** > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! buf[0] == '0' && buf[1] == c) { > ! *res++ = *buf++; > ! *res++ = *buf++; > rescnt -= 2; > len -= 2; > --- 4756,4762 ---- > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! pbuf[0] == '0' && pbuf[1] == c) { > ! *res++ = *pbuf++; > ! *res++ = *pbuf++; > rescnt -= 2; > len -= 2; > *************** > *** 4736,4741 **** > case 'g': > case 'G': > ! buf = tmpbuf; > ! len = formatfloat(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4773,4779 ---- > case 'g': > case 'G': > ! pbuf = formatbuf; > ! len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4746,4751 **** > > case 'c': > ! buf = tmpbuf; > ! len = formatchar(buf, v); > if (len < 0) > goto onError; > --- 4784,4789 ---- > > case 'c': > ! pbuf = formatbuf; > ! len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v); > if (len < 0) > goto onError; > *************** > *** 4759,4764 **** > } > if (sign) { > ! if (*buf == '-' || *buf == '+') { > ! sign = *buf++; > len--; > } > --- 4797,4802 ---- > } > if (sign) { > ! if (*pbuf == '-' || *pbuf == '+') { > ! sign = *pbuf++; len--; > } > *************** > *** 4796,4800 **** > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, buf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > --- 4834,4838 ---- > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, pbuf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > > -- Sjoerd Mullender <sjoerd.mullender(a)oratrix.com>

3 3

New PythonLabs site revealed!
by Guido van Rossum 30 Jun '00

30 Jun '00

Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place. The new beta will be released via this site. And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README): """ While Pythoneers have grown fond of Python's exceedingly slow version incrementing, that same quality makes parts of the rest of the world think Python is barely out of its first alpha test. Especially enterprise customers are often fearful of anything that's version 1.x! The new version number also clearly marks Python's departure from CNRI. Previously, the version number 2.0 was associated with a mythical and elusive incompatible future release. That release (still ways off, and not as incompatible as people fear!) is now referred to as Python 3000. """ --Guido van Rossum (home page: http://www.python.org/~guido/)

11 14

Python-Dev June 2000