Mailman 3 May 2001 - Python-Dev

Comparison speed
by Tim Peters 15 May '01

15 May '01

Here's a simple test program: from time import clock indices = [1] * 100000 def doit(): s = clock() i = 0 while i < 100000: "ab" < "cd" i += 1 f = clock() return f - s for i in xrange(10): print "%.3f" % doit() And here's output from 2.0, 2.1 and current CVS: C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.107 0.106 0.109 0.106 0.106 0.106 0.106 0.106 0.105 0.106 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.118 0.118 0.117 0.118 0.117 0.118 0.117 0.118 0.117 0.118 C:\Code\python\dist\src\PCbuild>python timech.py 0.119 0.117 0.118 0.117 0.118 0.117 0.118 0.117 0.118 So "something happened" between 2.0 and 2.1 to slow this overall by 10%. string_compare hasn't changed, so rich comparisons are a good guess. Note that the more obvious timing loop obscures the issue: def doit(): s = clock() for i in indices: "ab" < "cd" f = clock() return f - s C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.070 0.069 0.069 0.070 0.069 0.069 0.069 0.070 0.069 0.069 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.076 0.076 0.076 0.076 0.076 0.077 0.076 0.076 0.076 0.076 C:\Code\python\dist\src\PCbuild>python timech.py 0.069 0.070 0.070 0.069 0.069 0.070 0.070 0.069 0.070 0.069 for-loops are faster in current CVS than in 2.0 or 2.1, and that cancels out the comparison slowdown. If we try it with a type of comparison that avoids the richcmp machinery (int < int is special-cased in ceval), current CVS is actually faster than 2.0: def doit(): s = clock() for i in indices: 2 < 3 f = clock() return f - s C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.056 0.056 0.056 0.056 0.055 0.056 0.058 0.058 0.055 0.056 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.059 0.059 0.059 0.060 0.060 0.059 0.059 0.060 0.059 0.059 C:\Code\python\dist\src\PCbuild>python timech.py 0.053 0.052 0.052 0.053 0.053 0.052 0.052 0.054 0.052 0.053 C:\Code\python\dist\src\PCbuild> This also shows that 2.1 was a bit more slothful than 2.0 for some reason other than richcmps. These were all done on a Win2K box; timings vary too much on a Win9x box to be useful. Anybody care to take a stab at making the new richcmp and/or coerce code ugly again? speed-isn't-pretty-but-then-guts-rarely-are-ly y'rs - tim

3 3

Comparison speed
by Martin v. Loewis 14 May '01

14 May '01

> Anybody care to take a stab at making the new richcmp and/or coerce > code ugly again? Hi Tim, With CVS Python, 1000000 iterations, and a for loop, I currently got 0.780 0.770 0.770 0.780 0.770 0.770 0.770 0.780 0.770 0.770 With the patch below, I get 0.720 0.710 0.710 0.720 0.710 0.710 0.710 0.720 0.710 0.710 The idea is to let strings support richcmp; this also allows some optimization for the EQ case. Please let me know what you think. Martin Index: stringobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/stringobject.c,v retrieving revision 2.115 diff -u -r2.115 stringobject.c --- stringobject.c 2001/05/10 00:32:57 2.115 +++ stringobject.c 2001/05/14 21:36:36 @@ -596,6 +596,51 @@ return (len_a < len_b) ? -1 : (len_a > len_b) ? 1 : 0; } +/* In the signature, only a is guaranteed to be a PyStringObject. + However, as the first thing in the function, we check that b + is of that type also. */ + +static PyObject* +string_richcompare(PyStringObject *a, PyStringObject *b, int op) +{ + int c; + PyObject *result; + if (!PyString_Check(b)) { + result = Py_NotImplemented; + goto out; + } + if (op == Py_EQ) { + if (a->ob_size != b->ob_size) { + result = Py_False; + goto out; + } +#ifdef CACHE_HASH + if (a->ob_shash != b->ob_shash + && a->ob_shash != -1 + && b->ob_shash != -1) { + result = Py_False; + goto out; + } +#endif + } + c = string_compare(a, b); + switch (op) { + case Py_LT: c = c < 0; break; + case Py_LE: c = c <= 0; break; + case Py_EQ: c = c == 0; break; + case Py_NE: c = c != 0; break; + case Py_GT: c = c > 0; break; + case Py_GE: c = c >= 0; break; + default: + result = Py_NotImplemented; + goto out; + } + result = c ? Py_True : Py_False; + out: + Py_INCREF(result); + return result; +} + static long string_hash(PyStringObject *a) { @@ -2409,6 +2454,12 @@ &string_as_buffer, /*tp_as_buffer*/ Py_TPFLAGS_DEFAULT, /*tp_flags*/ 0, /*tp_doc*/ + 0, /*tp_traverse*/ + 0, /*tp_clear*/ + (richcmpfunc)string_richcompare, /*tp_richcompare*/ + 0, /*tp_weaklistoffset*/ + 0, /*tp_iter*/ + 0, /*tp_iternext*/ }; void

1 0

deprecated platforms
by Steven D. Majewski 14 May '01

14 May '01

Jack asked me about: https://sourceforge.net/tracker/?func=detail&aid=420601&group_id=5470&atid=… which concerns removing the support for --with-next-framework from the build procedure. I'm all for removing it: it's broken for OSX, if it worked, it doesn't do the whole job ( I think framework support should eventually be added for OSX with a separate post-build script -- a real framework should encapsulate all of the python libs, docs and headers files in one bundle. ) nobody seems to know if it still works on Next or OpenStep. However, I said I thought there ought to be some sort of official procedure for removing platform support. This doesn't seem to be addressed in either PEP 4 (Deprecation of Standard Modules) or PEP 5 (Guidelines for Language Evolution). I don't think it needs to be as involved a process as PEP 4 or 5 -- it's a more reversable decision than removing a feature from the language. Although, removing a platform dependent feature -- like in the long discussion about case sensitivity -- may be a bigger deal. But I'm really thinking more about things like the Next case -- where there are build options and #ifdefs that, as far as we know, haven't been tested in several versions. ( Believe it or not, there are still folks hanging dearly onto their black NeXT cubes, and finding the useful -- but I have no idea if any of them are using Python, and there's lots of users out there whom we only hear from when they discover a problem. ) Perhaps there should be some sort of "Last Call for Platform Saviour" : if nobody steps forward who is willing to do test builds on that platform, support may be removed if maintaining it is getting in the way. Any thougts or opinions on this? Are there any other platforms where this might become an issue ? If this looks like it's unlikely to crop up again, then maybe we don't need to bother with a 'policy'. What about support for particular compilers and build environments: (Borland C on Windows and MPW on Mac are two examples of "minority" compilers.) BTW: As I've though more about this particular issue (--with-next-framework) I don't think it's as big an issue -- removing that switch isn't going to break the build entirely (I think!). Pulling out all of the #ifdefs for Next would be a larger issue, but that hasn't been proposed (yet). If the consensus is that this isn't a big enough issue, in general, to need an official policy, then I vote to pull it out and see if anyone screams. -- Steve Majewski

2 1

deprecated platforms
by Martin v. Loewis 14 May '01

14 May '01

> I'm all for removing it: So am I. There are way too many build options for build Python on the Mac-like systems already (e.g. after that change, you still have --with-dyld - or rather the option of still building .o extensions). If it is clearly broken (even if only on OSX), it should be removed. Anybody interested in the flag would need to make it work correctly before it can be revived. > However, I said I thought there ought to be some sort of official > procedure for removing platform support. I don't think such a procedure is necessary. It is not that any end user would be concerned; building Python is an activity of system administrators. The other PEPs are there because changing the language or removing modules might break *applications* that used to work after an upgrade of Python. With removed platform support, nothing will break - installations would continue to use the last release that did support that platform. Regards, Martin

1 0

State of curses tutorial?
by Eric S. Raymond 14 May '01

14 May '01

A user pointed out a typo in the "Curses Programming with Python" tutorial at <http://py-howto.sourceforge.net/curses/curses.html>. While attempting to fix it, I discovered a few tings: 1. Somebody seems to have removed Andrew Kuchling's namne from it. If it was Andrew, that's OK -- but the reference in the latest version of the library docs still cites him. 2. I don't seem to have the TeX source anymore. Where can I download it? 3. Perhaps it's time to start putting howtos in the nondist part of the CVS tree? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857

2 2

Py_FileSystemDefaultEncoding
by Jack Jansen 14 May '01

14 May '01

I'm not too thrilled with the way the filename encoding stuff was done, with a global var declared in posixmodule.c which is then used by bltinmodule.c. It took me quite a while to figure out why my builds were failing, and how to fix it. And I think other minority platforms may have the same problem, so maybe it's a good idea to move the Py_FileSystemDefaultEncoding declaration to an include file, and do the initialization in a more "common" place? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

ReleaseNode interface in 4XSLT
by Martin v. Loewis 14 May '01

14 May '01

Currently, 4XSLT has a dependency on the DOM implementation in terms of memory management (among other dependencies). I'd like to reduce this dependency, by providing a centralized function that knows how to release nodes. In PyXML, I currently use # Define ReleaseNode in a DOM-independent way import xml.dom.ext import xml.dom.minidom def _releasenode(n): if isinstance(n, xml.dom.minidom.Node): n.unlink() else: xml.dom.ext.ReleaseNode(n) try: from Ft.Lib import pDomlette def ReleaseNode(n): if isinstance(n, pDomlette.Node): pDomlette.ReleaseNode(n) else: _releasenode(n) _XsltElementBase = pDomlette.Element except ImportError: ReleaseNode = _releasenode from minisupport import _XsltElementBase This code knows how to release minidom, 4DOM, and pDomlette nodes, and supports installations without 4Suite (i.e. without pDomlette). I've put this into xslt/__init__.py, so that all callers of Ft.Lib.pDomlette.ReleaseNode now need to call xml.xslt.ReleaseNode. If desired, I could produce a patch against the public Ft CVS. As a slightly independent question, such a function also ought to support DOM implementations not known to it; I'm thinking in particular of the Zope DOMs. I'd like to hear proposals on how such an interface should work; I see three options: a) it is an operation on the document node (or any node), as in minidom. b) it is an operation on the DOM implementation (almost as in 4Suite; you'd need to navigate from the node to the implementation, then you'd need a well-known operation on the implementation) c) the code assumes that no release activity is necessary for unknown DOMs, effectively believing in reference counting, garbage collection, acquisition, and other black art. Any comments appreciated, in particular 1. from the Ft maintainers on introducing xml.xslt.ReleaseNode, and 2. from authors of other DOMs on a general memory management API for Python DOM. Regards, Martin

2 4

Re: [Python-Dev] Mac hierarchy backwards
by Jack Jansen 14 May '01

14 May '01

> It seems, however, that some of the directory structure is backwards: > Mac/Demo should be Demo/Mac, and Mac/Tools should be Tools/Mac. There > may be others of this kind. Yes, now that the Mac stuff is integrated with the mainstream again this might be a good idea. > I also wonder whether all these files are still needed, and meant to > be distributed. E.g. I see chdir.c having the comment > > /* Chdir for the Macintosh. > Public domain by Guido van Rossum, CWI, Amsterdam (July 1987). > Pathnames must be Macintosh paths, with colons as separators. */ > > Is it really the case that the Mac API hasn't grown a chdir call in 13 > years? Hmm, hmm, I'm unsure. MacOS (<= 9) itself doesn't have chdir, because it doesn't believe in current directories (by design. Whether I agree with the design is a different matter:-). Normally MacPython is built with a special unix-compatibility library, GUSI, which does provide these calls. However, it is still possible to build without GUSI, and actually in the process of porting MacPython to Carbon ("MacOSX in it's MacOS API model") I've used these compatibility routines again, until I finally got GUSI ported. But its easy enough to cvs-remove them from the normal tree, to be revived when needed. What do people think? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

status of pre?
by Fred L. Drake, Jr. 13 May '01

13 May '01

Have we formulated a plan of action regarding PCRE and the pre module? Are we planning to leave them in for another version, or is SRE considered sufficiently stable? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

3 3

Type/class
by Paul Prescod 13 May '01

13 May '01

-------- Original Message -------- Log Message: Make attributes of subtypes writable, but only for dynamic subtypes derived in Python using a class statement; static subtypes derived in C still have read-only attributes. -------- Original Message -------- I would like to argue that "plain old C types" should act as if they have __dict__s for consistency with other types. It is sometimes useful to be able to annotate objects by adding attributes to them. But this only works with class instance objects, not instances of types. Paul Prescod

8 17