Mailman 3 May 2000 - Python-Dev

Patch: AttributeError and NameError: second attempt.
by Martin v. Loewis May 28, 2000

May 28, 2000

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

1 0

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

May 27, 2000

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

3 2

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

May 27, 2000

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

4 5

py_compile and CR in source files
by Greg Ward May 26, 2000

May 26, 2000

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

5 6

C implementation of exceptions module
by bwarsaw＠python.org May 26, 2000

May 26, 2000

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

3 5

Memory woes under Windows
by Tim Peters May 26, 2000

May 26, 2000

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

2 4

Extension on Solaris: ld -G or gcc -G?
by Greg Ward May 26, 2000

May 26, 2000

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

2 3

Terminology question
by Greg Ward May 26, 2000

May 26, 2000

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

4 3

ActiveState news
by David Ascher May 26, 2000

May 26, 2000

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 May 25, 2000

May 25, 2000

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

1 0