Mailman 3 June 2000 - Python-Dev

build problems under MSVC 5.0
by Fredrik Lundh July 28, 2000

July 28, 2000

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

2 3

Sourceforge Interface Concerns
by Andy Robinson July 10, 2000

July 10, 2000

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

10 18

Patch management (was: Warnings in pythonrun.c)
by Andrew M. Kuchling July 9, 2000

July 9, 2000

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

13 31

Comparison inconsistency with ExtensionClass
by Greg Ward July 6, 2000

July 6, 2000

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

4 3

Just spotted on SourceForge main page
by Greg Ward July 3, 2000

July 3, 2000

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

3 2

Re: [Python-Dev] Test results of linuxaudiodev.c
by Michael Hudson July 3, 2000

July 3, 2000

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

4 3

RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6
by Mark Hammond July 1, 2000

July 1, 2000

> 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 July 1, 2000

July 1, 2000

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

6 15

Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32
by Sjoerd Mullender July 1, 2000

July 1, 2000

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

3 3

New PythonLabs site revealed!
by Guido van Rossum June 30, 2000

June 30, 2000

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

11 14