Mailman 3 February 2005 - Python-Dev

Negative indices in UserString.MutableString
by Walter Dörwald 18 Feb '05

18 Feb '05

Currently UserString.MutableString does not support negative indices: >>> import UserString >>> UserString.MutableString("foo")[-1] = "bar" Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/Python-test/dist/src/Lib/UserString.py", line 149, in __setitem__ if index < 0 or index >= len(self.data): raise IndexError IndexError Should this be fixed so that negative value are treated as being relative to the end? Bye, Walter Dörwald

2 1

Re: [Python-checkins] python/dist/src/Doc/lib libimp.tex, 1.36, 1.36.2.1 libsite.tex, 1.26, 1.26.4.1 libtempfile.tex, 1.22, 1.22.4.1 libos.tex, 1.146.2.1, 1.146.2.2
by Just van Rossum 18 Feb '05

18 Feb '05

bcannon(a)users.sourceforge.net wrote: > \begin{datadesc}{PY_RESOURCE} > -The module was found as a Macintosh resource. This value can only be > -returned on a Macintosh. > +The module was found as a Mac OS 9 resource. This value can only be > +returned on a Mac OS 9 or earlier Macintosh. > \end{datadesc} not entirely true: it's limited to the sa called "OS9" version of MacPython, which happily runs natively on OSX as a Carbon app... Just

2 1

Re: [Python-Dev] Re: string find(substring) vs. substring in string
by Raymond Hettinger 18 Feb '05

18 Feb '05

> but refactoring the contains code to use find_internal sounds like a good > first step. any takers? > > </F> I'm up for it. Raymond Hettinger

2 1

[ python-Bugs-1124637 ] test_subprocess is far too slow (fwd)
by Peter Astrand 17 Feb '05

17 Feb '05

I'd like to have your opinion on this bug. Personally, I'd prefer to keep test_no_leaking as it is, but if you think otherwise... One thing that actually can motivate that test_subprocess takes 20% of the overall time is that this test is a good generic Python stress test - this test might catch some other startup race condition, for example. Regards, Åstrand ---------- Forwarded message ---------- Date: Thu, 17 Feb 2005 04:09:33 -0800 From: SourceForge.net <noreply(a)sourceforge.net> To: noreply(a)sourceforge.net Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Bugs item #1124637, was opened at 2005-02-17 11:10 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_… Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-17 12:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 11:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_…

10 12

2.4 func.__name__ breakage
by Tim Peters 17 Feb '05

17 Feb '05

Rev 2.66 of funcobject.c made func.__name__ writable for the first time. That's great, but the patch also introduced what I'm pretty sure was an unintended incompatibility: after 2.66, func.__name__ was no longer *readable* in restricted execution mode. I can't think of a good reason to restrict reading func.__name__, and it looks like this part of the change was an accident. So, unless someone objects soon, I intend to restore that func.__name__ is readable regardless of execution mode (but will continue to be unwritable in restricted execution mode). Objections? Tres Seaver filed a bug report (some Zope tests fail under 2.4 because of this): http://www.python.org/sf/1124295

2 6

builtin_id() returns negative numbers
by Richard Brodie 17 Feb '05

17 Feb '05

> Maybe it's just a wart we have to live with now; OTOH, > the docs explicitly warn that id() may return a long, so any code > relying on "short int"-ness has always been relying on an > implementation quirk. Well, the docs say that %x does unsigned conversion, so they've been relying on an implementation quirk as well ;) Would it be practical to add new conversion syntax to string interpolation? Like, for example, %p as an unsigned hex number the same size as (void *). Otherwise, unless I misunderstand integer unification, one would just have to strike the distinction between, say, %d and %u.

3 2

Windows Low Fragementation Heap yields speedup of ~15%
by Gfeller Martin 17 Feb '05

17 Feb '05

Dear all, I'm running a large Zope application on a 1x1GHz CPU 1GB mem Window XP Prof machine using Zope 2.7.3 and Py 2.3.4 The application typically builds large lists by appending and extending them. We regularly observed that using a given functionality a second time using the same process was much slower (50%) than when it ran the first time after startup. This behavior greatly improved with Python 2.3 (thanks to the improved Python object allocator, I presume). Nevertheless, I tried to convert the heap used by Python to a Windows Low Fragmentation Heap (available on XP and 2003 Server). This improved the overall run time of a typical CPU-intensive report by about 15% (overall run time is in the 5 minutes range), with the same memory consumption. I consider 15% significant enough to let you know about it. For information about the Low Fragmentation Heap, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/bas… Best regards, Martin PS: Since I don't speak C, I used ctypes to convert all heaps in the process to LFH (I don't know how to determine which one is the C heap). ________________________ COMIT AG Risk Management Systems Pflanzschulstrasse 7 CH-8004 Zürich Telefon +41 (44) 1 298 92 84 http://www.comit.ch http://www.quantax.com - Quantax Trading and Risk System

4 3

string find(substring) vs. substring in string
by Fredrik Lundh 17 Feb '05

17 Feb '05

any special reason why "in" is faster if the substring is found, but a lot slower if it's not in there? timeit -s "s = 'not there'*100" "s.find('not there') != -1" 1000000 loops, best of 3: 0.749 usec per loop timeit -s "s = 'not there'*100" "'not there' in s" 10000000 loops, best of 3: 0.122 usec per loop timeit -s "s = 'not the xyz'*100" "s.find('not there') != -1" 100000 loops, best of 3: 7.03 usec per loop timeit -s "s = 'not the xyz'*100" "'not there' in s" 10000 loops, best of 3: 25.9 usec per loop </F> ps. btw, it's about time we did something about this: timeit -s "s = 'not the xyz'*100" -s "import re; p = re.compile('not there')" "p.search(s)" 100000 loops, best of 3: 5.72 usec per loop

7 13

subclassing PyCFunction_Type
by Nick Rasmussen 17 Feb '05

17 Feb '05

tommy said that this would be the best place to ask this question.... I'm trying to get functions wrapped via boost to show up as builtin types so that pydoc includes them when documenting the module containing them. Right now boost python functions are created using a PyTypeObject such that when inspect.isbuiltin does: return isinstance(object, types.BuiltinFunctionType) isintance returns 0. Initially I had just modified a local pydoc to document all functions with unknown source modules (since the module can't be deduced from non-python functions), but I figured that the right fix was to get boost::python functions to correctly show up as builtins, so I tried setting PyCFunction_Type as the boost function type object's tp_base, which worked fine for me using linux on amd64, but when my patch was tried out on other platforms, it ran into regression test failures: http://mail.python.org/pipermail/c++-sig/2005-February/008545.html So I have some questions: Should boost::python functions be modified in some way to show up as builtin function types or is the right fix really to patch pydoc? Is PyCFunction_Type intended to be subclassable? I noticed that it does not have Py_TPFLAGS_BASETYPE set in its tp_flags. Also, PyCFunction_Type has Py_TPFLAGS_HAVE_GC, and as the assertion failures in the testsuite seemed to be centered around object allocation/ garbage collection, so is there something related to subclassing a gc-aware class that needs to be happening (currently the boost type object doesn't support garbage collection). If subclassing PyCFunction_Type isn't the right way to make these functions be considered as builtin functions, what is? -nick

4 6

RE: [Python-Dev] string find(substring) vs. substring in string
by Batista, Facundo 17 Feb '05

17 Feb '05

[Fredrik Lundh] #- any special reason why "in" is faster if the substring is found, but #- a lot slower if it's not in there? Maybe because it stops searching when it finds it? The time seems to be very dependant of the position of the first match: fbatista@pytonisa ~/ota> python /usr/local/lib/python2.3/timeit.py -s "s = 'not there'*100" "'not there' in s" 1000000 loops, best of 3: 0.222 usec per loop fbatista@pytonisa ~/ota> python /usr/local/lib/python2.3/timeit.py -s "s = 'blah blah'*20 + 'not there'*100" "'not there' in s" 100000 loops, best of 3: 5.54 usec per loop fbatista@pytonisa ~/ota> python /usr/local/lib/python2.3/timeit.py -s "s = 'blah blah'*40 + 'not there'*100" "'not there' in s" 100000 loops, best of 3: 10.8 usec per loop . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/

1 0