Mailman 3 May 2006 - Python-Dev

A Horrible Inconsistency
by Fredrik Lundh 27 May '06

27 May '06

>>> -1 * (1, 2, 3) () >>> -(1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for unary - We Really Need To Fix This! [\F]

16 30

patch for mbcs codecs
by H.Yamamoto 26 May '06

26 May '06

Hello. This is my first post. I sent the patch for fixing mbcs codec bug to SourceForge, and I was adviced to find someone here with a multibyte version of Windows to look at the patch. http://sourceforge.net/tracker/index.php?func=detail&aid=1455898&group_id=5… Is there anyone? Any help will be appriciated. Thank you.

1 0

partition() variants
by A.M. Kuchling 26 May '06

26 May '06

I didn't find an answer in the str.partition() thread in the archives (it's enormous, so easy to miss the right message), so I have two questions: 1) Is str.rpartition() still wanted? 2) What about adding partition() to the re module? --amk

5 6

Low-level exception invariants?
by Tim Peters 26 May '06

26 May '06

In various places we store triples of exception info, like a PyFrameObject's f_exc_type, f_exc_value, and f_exc_traceback PyObject* members. No invariants are documented, and that's a shame. Patch 1145039 aims to speed ceval a bit by relying on a weak guessed invariant, but I'd like to make the stronger claim (which allows for stronger speedups) that, at any moment, all three are NULL or all three are not NULL Now I know that's not true, although Python's test suite doesn't provoke a violation. In particular, PyErr_SetNone() forces tstate->curexc_value to NULL. Other code then special-cases the snot out of XYZ_value, replacing NULL with Py_None on the fly, like PyErr_Fetch(&exc, &val, &tb); if (val == NULL) { val = Py_None; Py_INCREF(val); } in the main eval loop. I'd much rather change PyErr_SetNone() to set the value to Py_None to begin with -- that function is almost never called, so special-casing in that is less damaging than special-casing NULL everywhere else. The docs are confused about this now too, claiming: void PyErr_SetNone(PyObject *type) This is a shorthand for "PyErr_SetObject(type, Py_None)". It's actually a shorthand for PyErr_SetObject(type, NULL) now. Does anyone see a real problem with _establishing_ an "all NULL or none NULL" invariant? It makes outstanding ;-) _conceptual_ sense to me, and would allow removing some masses of distributed test-branch special-casing in code trying to use these guys.

2 2

Re: [Python-Dev] [Python-checkins] r46247 - in python/branches/sreifschneider-newnewexcept: Makefile.pre.in Objects/exceptions.c Python/exceptions.c
by Richard Jones 26 May '06

26 May '06

On 25/05/2006, at 9:00 PM, Jim Jewett wrote: >> +/* >> + * OverflowWarning extends Warning >> + */ >> +SimpleExtendsException(PyExc_Warning, OverflowWarning, "Base >> class for warnings about numeric overflow. Won't exist in Python >> 2.5."); > > Take it out now? What do people say? I implemented this one because it was implemented in the old code in 2.5. Happy to remove it. Richard

2 1

Returning int instead of long from struct when possible for performance
by Bob Ippolito 26 May '06

26 May '06

Python ints are a heck of a lot faster to work with than Python longs and have the additional benefit that psyco <http:// psyco.sourceforge.net> can optimize the hell out of int but can't do anything at all for long. This is important because psyco is currently in pretty wide-spread use amongst people who need to squeeze every bit of performance out of their Python programs, and often yields 4x or better performance improvement in real-world tests. A more far reaching change would be to add a new PyInteger_From* API for code that doesn't care if long or int is returned, but I don't see much of a reason to go that far at this point since the rest of the standard library wouldn't benefit much. Unfortunately, this change to the struct module slightly alters the documented API for the following format codes: I, L, q, Q. Currently it is documented that those format codes will always return longs, regardless of their value. I've prototyped this change on the trunk (behind a currently undefined PY_USE_INT_WHEN_POSSIBLE macro). The standard library test suite passes with this enabled, but it would break any doctests in third party code that check the result of an unpack operation with one of those format codes. Given the interchangeability of int and long, I don't foresee any other complications with this change. Thoughts? -bob

4 3

SQLite status?
by Aahz 26 May '06

26 May '06

We're coming down to the wire on _Python for Dummies_, and I'm trying to persuade the publisher to stick a blurb about SQLite on the cover, but my last understanding was that there was a small chance we might pull SQLite for insufficient docs. Is that still true? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes

2 1

Cost-Free Slice into FromString constructors--Long
by Runar Petursson 26 May '06

26 May '06

We've been talking this week about ideas for speeding up the parsing of Longs coming out of files or network. The use case is having a large string with embeded Long's and parsing them to real longs. One approach would be to use a simple slice: long(mystring[x:y]) an expensive operation in a tight loop. The proposed solution is to add further keyword arguments to Long (such as): long(mystring, base=10, start=x, end=y) The start/end would allow for negative indexes, as slices do, but otherwise simply limit the scope of the parsing. There are other solutions, using buffer-like objects and such, but this seems like a simple win for anyone parsing a lot of text. I implemented it in a branch runar-longslice-branch, but it would need to be updated with Tim's latest improvements to long. Then you may ask, why not do it for everything else parsing from string--to which I say it should. Thoughts? -- Runar Petursson Betur runar(a)betur.net -- http://betur.net

10 11

SQLite header scan order
by Ronald Oussoren 26 May '06

26 May '06

Hi, The current version of setup.py looks for the sqlite header files in a number of sqlite-specific directories before looking into the default inc_dirs. I'd like to revert that order because that would make it possible to override the version of sqlite that gets picked up. Any objections to that? Ronald

2 2

Re: [Python-Dev] [Python-checkins] whatever happened to string.partition ?
by Guido van Rossum 25 May '06

25 May '06

On 5/25/06, Fredrik Lundh <fredrik(a)pythonware.com> wrote: > Raymond Hettinger wrote: > > > IIRC, Skip had developed a smart version that returned lazy string > > objects that kept a reference and pointers to the original string > > (instead of making its own copy of the string components). The string > > subclass would expand itself and free the reference if necessary for a > > subsequent string operation. The main purpose was to handle the cases > > where one fragment of the other was never used or just had a length > > check. Also it was helpful when partition was used lisp-style to > > repeatedly break-off head/tail fragments. > > that sounds nice in theory, but I completely fail to see how that can be > implemented without ripping out the existing string object and replacing > it with something entirely different, or (via horrible macro tricks) > slow down virtually all other use of PyStringObject. > > skip? was this a real design or a Py3K bluesky idea? I suggest to forget about that particular idea and just do what you were thinking of originally. str.partition() and unicode.partition() should be as simple as possible, to cover the 80% use case FAST. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1