Mailman 3 November 2001 - Python-Dev

PyObject_GenericGetAttr vs cygwin
by Michael Hudson Nov. 8, 2001

Nov. 8, 2001

CVS doesn't build cleanly on cygwin at the moment. The problem is that the address of a DL_IMPORT()ed function is not a compile time constant when building shared libraries, so when a type wants to use PyObject_GenericGetAttr as it's tp_getattro it shouldn't include it in the PyTypeObject definition (similar to why we now always write PyObject_HEAD_INIT(NULL) ). This means that (currently) cPickle and socket don't build as shared libraries. Two solutions: (1) build them statically. … [View More]

2 1

Re: [Python-Dev] Proposal - KeyboardInterrupt should inherit directly from Exception
by Anthony Baxter Nov. 8, 2001

Nov. 8, 2001

>>> Michael Hudson wrote > Parenthetically, could someone explain why this doesn't work[1]: > [keyboard interrupt vs sigint] > I think I hate readline. readline messes up the signals & bitsnpieces far, far too much. In the unified messaging server at work, we reimplemented our own history &c thing in the console, because that way we knew what it was doing. Anthony. (look for another large mass of checkins in the next day on the branch) -- Anthony Baxter <… [View More]

1 0

Re: [Python-Dev] Re: complex() bug or feature? (fwd)
by Michael Hudson Nov. 8, 2001

Nov. 8, 2001

Skip Montanaro <skip(a)pobox.com> writes: > The topic of the behavior and documentation of complex() in the face of > string args came up in c.l.py. I believe the current behavior and > documentation are both in error. I have a patch, test case and doc fixes > that I still need to run. Looks like a probably bug fix for 2.2b2 to me. > I'll submit a bug report and patch and assign to Tim. Unlike the one I just submitted and assigned to Fred? http://sourceforge.net/… [View More]

1 0

Proposal - KeyboardInterrupt should inherit directly from Exception
by Skip Montanaro Nov. 8, 2001

Nov. 8, 2001

Consider this code posted to c.l.py in the past day or two: try: x = float(s) result = 1 except: result = 0 to which Andrew Kuchling replied: It's better to catch ValueError and not all exceptions. Else what would happen if you get a MemoryError or a KeyboardInterrupt? All well and good. There are situations other than in throwaway code where you do want a more-or-less catchall except clause (any time you are executing arbitrary code for which you don'… [View More]

8 10

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.287,2.288
by barry＠zope.com Nov. 8, 2001

Nov. 8, 2001

[Followups redirected to python-dev... -BAW] >>>>> "MAL" == M <lemburg(a)users.sourceforge.net> writes: | Modified Files: | ceval.c | Log Message: | Add fast-path for comparing interned (true) string objects. MAL> This patch boosts performance for comparing identical string MAL> object by some 20% on my machine while not causing any MAL> noticable slow-down for other operations (according to tests MAL> done with pybench). … [View More]

2 2

Re: complex() bug or feature? (fwd)
by Skip Montanaro Nov. 8, 2001

Nov. 8, 2001

The topic of the behavior and documentation of complex() in the face of string args came up in c.l.py. I believe the current behavior and documentation are both in error. I have a patch, test case and doc fixes that I still need to run. Looks like a probably bug fix for 2.2b2 to me. I'll submit a bug report and patch and assign to Tim. Skip ------- start of forwarded message (RFC 934 encapsulation) ------- From: Skip Montanaro <montanaro(a)tttech.com> Sender: python-list-admin(a)… [View More]

1 0

Re: [Python-Dev] Proposal - KeyboardInterrupt should inherit directly from Exception
by Michael Hudson Nov. 8, 2001

Nov. 8, 2001

Thomas Wouters <thomas(a)xs4all.net> writes: > On Thu, Nov 08, 2001 at 05:24:53AM -0500, Michael Hudson wrote: > > [1] Actually I know, on thinking about it, but it still sucks. > > Is this worth working around? > > I don't think so, but it's worth keeping in mind when writing your > readline replacement, or your REPL/interactive-interpreter > replacement. Well, it works in pyrepl but that's mainly because it's implemented in a sensible language with a … [View More]

1 0

Change in evaluation order in new object model
by Michael McLay Nov. 8, 2001

Nov. 8, 2001

I was suprised by a change to the order of evaluation of members in the new object type. I haven't found an explanation for why the change was made. I was comfortable with the way it worked. Is there an advantage to the change?. In the classic python model the interpreter looked in the instance dictionary and if the name wasn't there it looked in the class dictionary. The following illustrates this evaluation order. >>> class C: def __init__(self): self.a = 4 >>&… [View More]

5 10

Future division detection
by com-nospam＠ccraig.org Nov. 7, 2001

Nov. 7, 2001

I am in the process of porting my cRat module to take advantage of some of the new features in Python 2.2 (and possibly making a patch out of it to address PEP239 (though not for Python 2.2 obviously)). While doing this I was thinking that I would change true_division on ints and floats to return a rational and change the rational code to return a long if the denominator is 1. This works great, except that if future division is off then rationals can suddenly become longs and do not … [View More]

4 4

RE: Program very slow to finish
by Tim Peters Nov. 7, 2001

Nov. 7, 2001

Speed freaks should look up this thread on c.l.py; also a related SF bug report I recently closed as "Won't Fix". Roeland Rengelink set up a simple test that builds increasingly large dicts, timing the per-item creation and destruction times. This was in response to another poster who bumped into the "geez, my program seems to take *forever* to exit" annoyance, where final decref'ing of many objects *can* take hours to complete (normally people only notice this at program exit, but it can … [View More]happen whenever a large number of objects get freed). Roeland found the creation time per dict element on his Linux system was pretty steady, but destruction time per element grew disturbingly with dict size. I found the same on Win98SE, but the degeneration in destruction time per element was milder than on his Linux test. I fiddled dict deallocation on my box to do everything *except* call free() when a refcount hit zero (the dict contained only string objects, so free() was the only thing left out -- strings have a trivial destructor). So the memory leaked, but per-element destruction time no longer increased with dict size, i.e. "the problem" on my box was entirely due to MS free() behavior. I suggested to Roeland that he try rebuilding his Python with PyMalloc enabled, just to see what would happen. This is what happened (time is average microseconds per dict entry, as computed from time.time() deltas captured across whole-dict operations): > Well, aint that nice > > 2.2b1 --with-pymaloc > > size: 10000, creation: 29.94, destruction: 0.61 > size: 20000, creation: 30.10, destruction: 0.64 > size: 50000, creation: 30.73, destruction: 0.71 > size: 100000, creation: 30.72, destruction: 0.68 > size: 200000, creation: 30.95, destruction: 0.69 > size: 500000, creation: 30.62, destruction: 0.67 > size: 1000000, creation: 30.71, destruction: 0.68 > > malloc is faster too ;) This is what he saw earlier, using his platform malloc/free: > All times in micro-seconds per item. For the code see end of this post. > (Linux 2.2.14, 128M RAM, Cel 333 MHz) > > size: 10000, creation: 31.00, destruction: 1.49 > size: 20000, creation: 31.10, destruction: 1.57 > size: 50000, creation: 32.77, destruction: 1.76 > size: 100000, creation: 32.00, destruction: 1.92 > size: 200000, creation: 32.59, destruction: 2.38 > size: 500000, creation: 32.12, destruction: 4.35 > size: 1000000, creation: 32.25, destruction: 10.47 Can any Python-Dev'er make time to dig into the advisability of making PyMalloc the default? I only took time for this because I'm out sick today, and was looking for something mindless to occupy my fevered thoughts; alas, it paid off <wink>. I recall there are still thread issues wrt PyMalloc, and there *were* some reports that PyMalloc was slower on some platforms. Against that, I'm the guy who usually gets stuck trying to explain the inexplicable, and malloc/free performance are so critical to Python performance that it's always been "a problem" that we have no idea how system malloc/free behave across platforms (although I suppose it's "a feature" that I know how to crash Win9X by provoking problems with its malloc <wink>). I can't make time for it in the 2.2 timeframe, though. factors-of-2-to-15-are-worth-a-little-effort-if-they're-real-ly y'rs - tim [View Less]

6 12