Mailman 3 May 2000 - Python-Dev

Patch: AttributeError and NameError: second attempt.
by Martin v. Loewis 28 May '00

28 May '00

[thread moved, since I can't put in proper References headers, anyway, just by looking at the archive] > 1) I rewrite the stuff that went into exceptions.py in C, and stick it > in the _exceptions module. I don't much like this idea, since it > kills the advantage noted above. >2) I leave the stuff that's in C already in C. I add C __str__ methods > to AttributeError and NameError, which dispatch to helper functions > in the python 'exceptions' module, if that module is available. >Which is better, or is there a third choice available? There is a third choice: Patch AttributeError afterwards. I.e. in site.py, say _AttributeError_str(self): code AttributeError.__str__ = _AttributeError_str Guido said > This kind of user-friendliness should really be in the tools, not in > the core language implementation! And I think Nick's patch exactly follows this guideline. Currently, the C code raising AttributeError tries to be friendly, formatting a string, and passing it to the AttributeError.__init__. With his patch, the AttributeError just gets enough information so that tools later can be friendly - actually printing anything is done in Python code. Fred said > I see no problem with the functionality from Nick's patch; this is > exactly te sort of thing what's needed, including at the basic > interactive prompt. I agree. Much of the strength of this approach is lost if it only works inside tools. When I get an AttributeError, I'd like to see right away what the problem is. If I had to fire up IDLE and re-run it first, I'd rather stare at my code long enough to see the problem. Regards, Martin

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib exceptions.py,1.18,1.19
by M.-A. Lemburg 27 May '00

27 May '00

> Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25262 > > Modified Files: > exceptions.py > Log Message: > For backwards compatibility, simply import everything from the > _exceptions module, including __doc__. Hmm, wasn't _exceptions supposed to be a *fall back* solution for the case where the exceptions.py module is not found ? It now looks like _exceptions replaces exceptions.py... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 2

Win32 build (was: RE: [Patches] From comp.lang.python: A compromise on case-sensitivity)
by Greg Stein 27 May '00

27 May '00

On Fri, 26 May 2000, Tim Peters wrote: >... > PS: Barry's exception patch appears to have broken the CVS Windows build > (nothing links anymore; all the PyExc_xxx symbols aren't found; no time to > dig more now). The .dsp file(s) need to be updated to include the new _exceptions.c file in their build and link step. (the symbols moved there) IMO, it seems it would be Better(tm) to put _exceptions.c into the Python/ directory. Dependencies from the core out to Modules/ seems a bit weird. Cheers, -g -- Greg Stein, http://www.lyra.org/

4 5

py_compile and CR in source files
by Greg Ward 27 May '00

27 May '00

Just made an unpleasant discovery: if a Python source file has CR-LF line-endings, you can import it just fine under Unix. But attempting to 'py_compile.compile()' it fails with a SyntaxError at the first line-ending. Arrghh! This means that Distutils will either have to check/convert line-endings at build-time (hey, finally, a good excuse for the "build_py" command), or implicitly compile modules by importing them (instead of using 'py_compile.compile()'). Perhaps I should "build" modules by line-at-a-time copying -- currently it copies them in 16k chunks, which would make it hard to fix line endings. Hmmm. Greg

5 6

C implementation of exceptions module
by bwarsaw＠python.org 27 May '00

27 May '00

Hi all, I've taken /F's C implementation of the standard class-based exceptions, implemented the stuff he left out, proofread for reference counting issues, hacked a bit more, and integrated it with the 1.6 interpreter. Everything seems to work well; i.e. the regression test suite passes and I don't get any core dumps ;). I don't have the ability right now to Purify things[1], but I've tried to be very careful in handling reference counting. Since I've been hacking on this all day, it could definitely use another set of eyes. I think rather than email a huge patch kit, I'll just go ahead and check the changes in. Please take a look and give it a hard twist. Thanks to /F for the excellent head start! -Barry [1] Purify was one of the coolest products on Solaris, but alas it doesn't seem like they'll ever support Linux. What do you all use to do similar memory verification tests on Linux? Or do you just not?

3 5

Memory woes under Windows
by Tim Peters 26 May '00

26 May '00

[Noah, I'm wondering whether this is related to our W98 NatSpeak woes -- Python grows its lists much like a certain product we both work on <ahem> grows its arrays ...] Here's a simple test case: from time import clock def run(): n = 1 while n < 4000000: a = [] push = a.append start = clock() for i in xrange(n): push(1) finish = clock() print "%10d push %10.3f" % (n, round(finish - start, 3)) n = n + n for i in (1, 2, 3): try: run() except MemoryError: print "Got a memory error" So run() builds a number of power-of-2 sized lists, each by appending one element at a time. It prints the list length and elapsed time to build each one (on Windows, this is basically wall-clock time, and is derived from the Pentium's high-resolution cycle timer). The driver simply runs this 3 times, reporting any MemoryError that pops up. The largest array constructed has 2M elements, so consumes about 8Mb -- no big deal on most machines these days. Here's what happens on my new laptop (damn, this thing is fast! -- usually): Win98 (Second Edition) 600MHz Pentium III 160Mb RAM Python 1.6a2 from python.org, via the Windows installer 1 push 0.000 2 push 0.000 4 push 0.000 8 push 0.000 16 push 0.000 32 push 0.000 64 push 0.000 128 push 0.000 256 push 0.001 512 push 0.001 1024 push 0.003 2048 push 0.011 4096 push 0.020 8192 push 0.053 16384 push 0.074 32768 push 0.163 65536 push 0.262 131072 push 0.514 262144 push 0.713 524288 push 1.440 1048576 push 2.961 Got a memory error 1 push 0.000 2 push 0.000 4 push 0.000 8 push 0.000 16 push 0.000 32 push 0.000 64 push 0.000 128 push 0.000 256 push 0.001 512 push 0.001 1024 push 0.003 2048 push 0.007 4096 push 0.014 8192 push 0.029 16384 push 0.057 32768 push 0.116 65536 push 0.231 131072 push 0.474 262144 push 2.361 524288 push 24.059 1048576 push 67.492 Got a memory error 1 push 0.000 2 push 0.000 4 push 0.000 8 push 0.000 16 push 0.000 32 push 0.000 64 push 0.000 128 push 0.000 256 push 0.001 512 push 0.001 1024 push 0.003 2048 push 0.007 4096 push 0.014 8192 push 0.028 16384 push 0.057 32768 push 0.115 65536 push 0.232 131072 push 0.462 262144 push 2.349 524288 push 23.982 1048576 push 67.257 Got a memory error Commentary: The first time it runs, the timing behavior is indistinguishable from O(N). But realloc returns NULL at some point when growing the 2M array! There "should be" huge gobs of memory available. The 2nd and 3rd runs are very similar to each other, both blow up at about the same time, but both run *very* much slower than the 1st run before that point as the list size gets non-trivial -- and, while the output doesn't show this, the disk starts thrashing too. It's *not* the case that Win98 won't give Python more than 8Mb of memory. For example, >>> a = [1]*30000000 # that's 30M >>> works fine and fast on this machine, with no visible disk traffic [Noah, that line sucks up about 120Mb from malloc in one shot]. So, somehow or other, masses of allocations are confusing the system memory manager nearly to death (implying we should use Vladimir's PyMalloc under Windows after grabbing every byte the machine has <0.6 wink>). My belief is that the Windows 1.6a2 from python.org was compiled with VC6, yes? Scream if that's wrong. This particular test case doesn't run any better under my Win95 (original) P5-166 with 32Mb RAM using Python 1.5.2. But at work, we've got a (unfortunately huge, and C++) program that runs much slower on a large-memory W98 machine than a small-memory W95 one, due to disk thrashing. It's a mystery! If anyone has a clue about any of this, spit it out <wink>. [Noah, I watched the disk cache size while running the above, and it's not the problem -- while W98 had allocated about 100Mb for disk cache at the start, it gracefully gave that up as the program's memory demands increased] just-another-day-with-windows-ly y'rs - tim

2 4

Extension on Solaris: ld -G or gcc -G?
by Greg Ward 26 May '00

26 May '00

My post on this from last week was met with a deafening silence, so I will try to be short and to-the-point this time: Why are shared extensions on Solaris linked with "ld -G" instead of "gcc -G" when gcc is the compiler used to compile Python and extensions? Is it historical? Ie. did some versions of Solaris and/or gcc not do the right thing here? Could we detect that bogosity in "configure", and only use "ld -G" if it's necessary, and use "gcc -G" by default? The reason that using "ld -G" is the wrong thing is that libgcc.a is not referenced when creating the .so file. If the object code happens to reference functions in libgcc.a that are not referenced anywhere in the Python core, then importing the .so fails. This happens if there is a 64-bit divide in the object code. See my post of May 19 for details. Greg -- Greg Ward - software developer gward(a)mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

2 3

Terminology question
by Greg Ward 26 May '00

26 May '00

A question of terminology: frequently in the Distutils docs I need to refer to the package-that-is-not-a-package, ie. the "root" or "empty" package. I can't decide if I prefer "root package", "empty package" or what. ("Empty" just means the *name* is empty, so it's probably not a very good thing to say "empty package" -- but "package with no name" or "unnamed package" aren't much better.) Is there some accepted convention that I have missed? Here's the definition I've just written for the "Distribution Python Modules" manual: \item[root package] the ``package'' that modules not in a package live in. The vast majority of the standard library is in the root package, as are many small, standalone third-party modules that don't belong to a larger module collection. (The root package isn't really a package, since it doesn't have an \file{\_\_init\_\_.py} file. But we have to call it something.) Confusing enough? I thought so... Greg -- Greg Ward - Unix nerd gward(a)python.net http://starship.python.net/~gward/ Beware of altruism. It is based on self-deception, the root of all evil.

4 3

ActiveState news
by David Ascher 26 May '00

26 May '00

While not a technical point, I thought I'd mention to this group that ActiveState just announced several things, including some Python-related projects. See www.ActiveState.com for details. --david PS: In case anyone's still under the delusion that cool Python jobs are hard to find, let me know. =)

2 1

Re: [Python-checkins] CVS: python/dist/src/Modules _exceptions.c,NONE,1.1
by Greg Stein 26 May '00

26 May '00

On Thu, 25 May 2000, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25441 > > Added Files: > _exceptions.c > Log Message: > Built-in class-based standard exceptions. Written by Fredrik Lundh. > Modified, proofread, and integrated for Python 1.6 by Barry Warsaw. Since the added files are not emailed, you can easily see this file at: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/dist/src/Modules/_exce… Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0