Mailman 3 March 2001 - Python-Dev

test_doctest failing, but perhaps by accident
by Tim Peters March 21, 2001

March 21, 2001

When running the full test suite, test_doctest fails (in current CVS; did not fail yesterday). This was on Windows. Other platforms? Does not fail in isolation. Doesn't matter whether or not .pyc files are deleted first, and doesn't matter whether a regular or debug build of Python is used. In four runs of the full suite with regrtest -r (randomize test order), test_doctest failed twice and passed twice. So it's unlikely this has something specifically to do with doctest. roll-out-the-… [View More]

4 9

PEP 245: Python Interfaces
by Michel Pelletier March 21, 2001

March 21, 2001

Barry has just checked in PEP 245 for me. http://python.sourceforge.net/peps/pep-0245.html I'd like to open up the discussion phase on this PEP to anyone who is interested in commenting on it. I'm not sure of the proper forum, it has been discussed to some degree on the types-sig. Thanks, -Michel

1 0

Re: [Python-Dev] test_coercion failing
by Jack Jansen March 21, 2001

March 21, 2001

It turns out that even simple things like 0j/2 return -0.0. The culprit appears to be the statement r.imag = (a.imag - a.real*ratio) / denom; in c_quot(), line 108. The inner part is translated into a PPC multiply-subtract instruction fnmsub fp0, fp1, fp31, fp0 Or, in other words, this computes "0.0 - (2.0 * 0.0)". The result of this is apparently -0.0. This sounds reasonable to me, or is this against IEEE754 rules (or C99 rules?). If this is all according to 754 rules the one … [View More]

2 1

(no subject)
by reptile research March 21, 2001

March 21, 2001

1 0

test_coercion failing
by Mark Favas March 21, 2001

March 21, 2001

[Tim searches for -0's] On Tru64 Unix (4.0F) with Compaq's C compiler I get: Python 2.1b2 (#344, Mar 22 2001, 03:18:25) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> x = 0.0 >>> print "%.17g" % -x -0 >>> print "%+.17g" % -x -0 and on Solaris 8 (Sparc) with gcc I get: Python 2.1b2 (#23, Mar 22 2001, 03:25:27) [GCC 2.95.2 19991024 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> x = 0.0 … [View More]

1 0

Re: [Python-Dev] Nested scopes core dump
by Michael Hudson March 21, 2001

March 21, 2001

"Tim Peters" <tim.one(a)home.com> writes: > [Michael Hudson] > >>> Maybe you could do the check for resize *after* the call to > >>> insertdict? I think that would work, but I wouldn't like to go > >>> messing with such a performance critical bit of code without some > >>> careful thinking. > > [Guido] > >> No, that could still decide to resize, couldn't it? > > [Michael] > > Yes, but not when you're … [View More]inserting on a key that is already in the > > dictionary - because the resize would have happened when the key was > > inserted into the dictionary, and thus the problem we're seeing here > > wouldn't happen. > > Careful: this comment is only half the truth: > > /* if fill >= 2/3 size, double in size */ Yes, that could be clearer. I was confused by the distinction between ma_used and ma_fill for a bit. > The dictresize following is also how dicts *shrink*. That is, build > up a dict, delete a whole bunch of keys, and nothing at all happens > to the size until you call setitem again (actually, I think you need > to call it more than once -- the behavior is tricky). Well, as I read it, if you delete a bunch of keys and then insert the same keys again (as in pybench's SimpleDictManipulation), no resize will happen because ma_fill will be unaffected. A resize will only happen if you fill up enough slots to get the mp->ma_fill*3 >= mp->ma_size*2 to trigger. > In any case, that a key is already in the dict does not guarantee > that a dict won't resize (via shrinking) when doing a setitem. Yes. But I still think that the patch I posted here (the one that checks for resize after the call to insertdict in PyDict_SetItem) yesterday will suffice; even if you've deleted a bunch of keys, ma_fill will be unaffected by the deletes so the size check before the insertdict won't be triggered (becasue it wasn't by the one after the call to insertdict in the last call to setitem) and neither will the size check after the call to insertdict won't be triggered (because you're inserting on a key already in the dictionary and so ma_fill will be unchagned). But this is mighty fragile; something more explicit is almost certainly a good idea. So someone should either > bite the bullet and add a new PyDict_AdjustSize function, just > duplicating the resize logic. or just put a check in PyDict_Next, or outlaw this practice and fix the places that do it. And then document the conclusion. And do it before 2.1b2 on Friday. I'll submit a patch, unless you're very quick. > Delicate, though. Uhh, I'd say so. Cheers, M. -- Very clever implementation techniques are required to implement this insanity correctly and usefully, not to mention that code written with this feature used and abused east and west is exceptionally exciting to debug. -- Erik Naggum on Algol-style "call-by-name" [View Less]

1 0

Re: FW: FW: [Python-Dev] Simple generator implementation
by Uche Ogbuji March 21, 2001

March 21, 2001

> > At IPC9, Guido put up a poll of likely use of stackless features, and it was a > > pretty clear arithmetic progression from those who wanted to use microthreads, > > to those who wanted co-routines, to those who wanted just generators. The > > generator folks were probably 2/3 of the assembly. Looks as if many have > > decided, and they seem to agree with you. > > Here the exact facts of the poll: > > microthreads: 26 > co-routines: … [View More]

2 1

Editor sought for Quick Python Book 2nd ed.
by Guido van Rossum March 21, 2001

March 21, 2001

The publisher of the Quick Python Book has approached me looking for an editor for the second edition. Anybody interested? --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] test_coercion failing
by Jack Jansen March 21, 2001

March 21, 2001

> Everyone! Run this program under current CVS: > > x = 0.0 > print "%.17g" % -x > print "%+.17g" % -x > > What do you get? WinTel prints "0" for the first and "+0" for the second. Macintosh: -0 for both. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Python-Dev] Unicode and the Windows file system.
by Jack Jansen March 21, 2001

March 21, 2001

> The way I see it, to fix this we have 2 basic choices when a Unicode object > is passed as a filename: > * we call the Unicode versions of the CRTL. > * we auto-encode using the "mbcs" encoding, and still call the non-Unicode > versions of the CRTL. > > The first option has a problem in that determining what Unicode support > Windows 95/98 have may be more trouble than it is worth. Sticking to purely > ascii versions of the functions means that the worst thing … [View More]

1 0