Mailman 3 June 2001 - Python-Dev

Help: Python 2.1: "Corrupt Installation Detected"
by Greg Ewing June 27, 2001

June 27, 2001

I'm trying to install Python-2.1 on Windows, and I keep getting "Corrupt Installation Detected" when I run the installer.

2 1

Unicode fallout: Windows _winreg project broken
by Tim Peters June 27, 2001

June 27, 2001

The _winreg project no longer links: Creating library ./_winreg_d.lib and object ./_winreg_d.exp _winreg.obj : error LNK2001: unresolved external symbol __imp__PyUnicode_DecodeMBCS The compilation of PyUnicode_DecodeMBCS in unicodeobject.c is in a #if defined(MS_WIN32) && defined(HAVE_USABLE_WCHAR_T) block. But the top of unicodeobject.h now wraps the enabling # if defined(MS_WIN32) && !defined(USE_UCS4_STORAGE) # define HAVE_USABLE_WCHAR_T # define PY_UNICODE_TYPE wchar_t # endif block inside a #ifndef PY_UNICODE_TYPE block, and a change to PC/config.h: #define PY_UNICODE_TYPE unsigned short stops all that. IOW, HAVE_USABLE_WCHAR_T no longer gets #define'd on Windows, and that prevents unicodeobject.c from supplying routines _winreg.c calls. leaving-it-to-an-expert-who-thinks-they-know-what-all-these-symbols- are-supposed-to-really-mean-ly y'rs - tim

1 0

Re: PEP 260: simplify xrange()
by James Logajan June 27, 2001

June 27, 2001

Tim Peters wrote: > [James Logajan] > > Are there still known bugs that will take some effort to repair? Is > > xrange constantly touched when changes are made elsewhere? If no to > > both, then I suggest don't fix what ain't broken; life is too short. > > (Unless it is annoying you to distraction, then do the deed and get > > it over with.) > > I think it's more the latter. I partly provoked this by bitterly pointing > out that there's more code in the CVS tree devoted to supporting the single > xrange() gimmick than Neil Schemenauer added to support the get-out-of-town > more powerful new generators. Masses of crufty code nobody benefits from > are a burden on the soul. Design mistakes one has made do tend to weigh on one's soul (speaking from more than two decades of programming experience) so I understand the primal urge to correct them when one can, and even when one shouldn't. So although I'm quite annoyed by all these new-fangled gimmicks being added to the language (i.e. Python generators being added to solve California's power problems) I have no problem with xrange being fenced in. (I find the very existence of the PEP process somewhat unsettling; there are now thousands of programmers trying to use the language. Why burden them with insuring their programs remain compatible with yet-another-damn-set-of-proposals every year? Or worse: trying to rewrite their code "more elegantly" using all the latest gimmicks. Why in my day, if you wanted to, say, save execution state, you figured out how to do it and didn't go crying to the language designer. Damn these young lazy programmers. Don't know how good they have it. Wouldn't know how to save their execution state if their lives depended on it. Harumph.) Speaking of "generators", I just want to say that I think that "generator" makes for lousy terminology. If I understand correctly, "generators" are coroutines that have peer-to-peer synchronized messaging (synchronizing and communicating at the "yield" points). To my mind, "generators" does not evoke that image at all. Assuming I understand it in my early senility.... > although-it-would-be-impolite-to-ask-we-why-still-ship-a-directory- > full-of-crufty-old-irix5-demos-in-the-std-library<wink>-ly Perhaps because the Irix community would be quite Irate if they were removed?

2 1

collecting timer resolution information...
by Fred L. Drake, Jr. June 27, 2001

June 27, 2001

I'd like people to run the attached C program and send the output to me. What this does is run the gettimeofday() and getrusage() functions until the time values change. The intent is to determine the quality of the available timing information. For example, on my Linux-Mandrake 7.2 installation with a stock 2.2.17 kernel, I get this: timeofday: 1 (1 calls), rusage: 10000 (2465 calls) Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

3 6

RE: PEP 260: simplify xrange()
by Delaney, Timothy June 27, 2001

June 27, 2001

> Here's another sweet and short PEP. What do folks think? Is > xrange()'s complexity really worth having? > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > PEP: 260 > Title: Simplify xrange() > Version: $Revision: 1.1 $ > Author: guido(a)python.org (Guido van Rossum) > Status: Draft > Type: Standards Track > Python-Version: 2.2 > Created: 26-Jun-2001 > Post-History: 26-Jun-2001 > > Abstract > > This PEP proposes to strip the xrange() object from some rarely > used behavior like x[i:j] and x*n. > > > Problem > > The xrange() function has one idiomatic use: > > for i in xrange(...): ... If this is to be done, I would also propose that xrange() and range() be changed to allow passing in a straight-out sequence such as in the following code in order to get rid of the need for range(len(seq)): import __builtin__ def range (start, stop=None, step=1, range=range): """""" start2 = start stop2 = stop if stop is None: stop2 = start start2 = 0 try: return range(start2, stop2, step) except TypeError: assert stop is None return range(len(start)) def xrange (start, stop=None, step=1, xrange=xrange): """""" start2 = start stop2 = stop if stop is None: stop2 = start start2 = 0 try: return xrange(start2, stop2, step) except TypeError: assert stop is None return xrange(len(start)) a = [5, 'a', 'Hello, world!'] b = range(a) c = xrange(4, 6) d = xrange(b) e = range(c) print a print b print c print d print e print range(d, 2) Tim Delaney

2 1

Re: PEP 260: simplify xrange()
by James Logajan June 27, 2001

June 27, 2001

Guido van Rossum wrote: > Here's another sweet and short PEP. What do folks think? Is > xrange()'s complexity really worth having? Are there still known bugs that will take some effort to repair? Is xrange constantly touched when changes are made elsewhere? If no to both, then I suggest don't fix what ain't broken; life is too short. (Unless it is annoying you to distraction, then do the deed and get it over with.)

2 1

latest unicode-related change causes failure in test_unicode & test_unicodedata
by Mark Favas June 26, 2001

June 26, 2001

CVS of a short while ago, Tru64 Unix: "make test" gives two unicode-related failures: test_unicode test test_unicode crashed -- exceptions.UnicodeError: UTF-8 decoding error: illegal encoding test_unicodedata The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_unicodedata Testing Unicode Database... Methods: ********************************************************************** Then ... We expected (repr): '6c7a7c02657b69d0fdd7a7d174f573194bba2e18' But instead we got: '374108f225e0c1488f8389ce6333902830d299fb' test test_unicodedata failed -- Writing: '374108f225e0c1488f8389ce6333902830d299fb', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18' Running the tests manually, test_unicode fails, test_unicodedata doesn't fail, but doesn't match the expected output for Methods: (test_unicode) <deletia> Testing Unicode contains method... done. Testing Unicode formatting strings... done. Testing builtin codecs... Traceback (most recent call last): File "Lib/test/test_unicode.py", line 383, in ? verify(u'\ud800\udc02'.encode('utf-8') == \ File "./Lib/test/test_support.py", line 95, in verify raise TestFailed(reason) test_support.TestFailed: test failed (test_unicodedata) python Lib/test/test_unicodedata.py Testing Unicode Database... Methods: 374108f225e0c1488f8389ce6333902830d299fb Functions: 41e1d4792185d6474a43c83ce4f593b1bdb01f8a API: ok -- Mark Favas - m.favas(a)per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA

1 0

make static
by Martin von Loewis June 26, 2001

June 26, 2001

There is a bug report on SF that 'make static' fails for a Makefile.pre.in extension, see http://sourceforge.net/tracker/index.php?func=detail&aid=435446&group_id=54… Is that process still supported? Unless I'm mistaken, this is complicated by the fact that Makefile.pre.in packages use the Makefile.pre.in that comes with the package, not the one that comes with the Python installation. Any insights welcome, Martin

3 3

PEP 260: simplify xrange()
by Guido van Rossum June 26, 2001

June 26, 2001

Here's another sweet and short PEP. What do folks think? Is xrange()'s complexity really worth having? --Guido van Rossum (home page: http://www.python.org/~guido/) PEP: 260 Title: Simplify xrange() Version: $Revision: 1.1 $ Author: guido(a)python.org (Guido van Rossum) Status: Draft Type: Standards Track Python-Version: 2.2 Created: 26-Jun-2001 Post-History: 26-Jun-2001 Abstract This PEP proposes to strip the xrange() object from some rarely used behavior like x[i:j] and x*n. Problem The xrange() function has one idiomatic use: for i in xrange(...): ... However, the xrange() object has a bunch of rarely used behaviors that attempt to make it more sequence-like. These are so rarely used that historically they have has serious bugs (e.g. off-by-one errors) that went undetected for several releases. I claim that it's better to drop these unused features. This will simplify the implementation, testing, and documentation, and reduce maintenance and code size. Proposed Solution I propose to strip the xrange() object to the bare minimum. The only retained sequence behaviors are x[i], len(x), and repr(x). In particular, these behaviors will be dropped: x[i:j] (slicing) x*n, n*x (sequence-repeat) cmp(x1, x2) (comparisons) i in x (containment test) x.tolist() method x.start, x.stop, x.step attributes By implementing a custom iterator type, we could speed up the common use, but this is optional (the default sequence iterator does just fine). I expect it will take at most an hour to rip it all out; another hour to reduce the test suite and documentation. Scope This PEP only affects the xrange() built-in function. Risks Somebody's code could be relying on the extended code, and this code would break. However, given that historically bugs in the extended code have gone undetected for so long, it's unlikely that much code is affected. Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End:

1 0

Re: [Python-Dev] Python Specializing Compiler
by Samuele Pedroni June 26, 2001

June 26, 2001

Hi. [Armin Rigo] ... > Why it is related to Psyco: the current treatment of globals/builtins makes > it hard for Psyco to statically tell what function we are calling when it > sees e.g. "len(a)" in the code. We would at least need some help from the > interpreter; at least hooks called when the module's globals() dictionary > change. The above proposal might provide a more uniform solution. > FYI, a different proposal for opt. globals access by Jeremy Hylton. It seems, it would break fewer things ... don't know whether it can be as useful for Psyco: http://mail.python.org/pipermail/python-dev/2001-May/014995.html In any case I think Psyco will need notification support from the interpreter about dynamic changes to things that Psyco honestly assumes to be invariant in order to achieve performance. regards, Samuele Pedroni.

3 2