Mailman 3 March 2002 - Python-Dev

[development doc updates]
by Fred L. Drake 05 Mar '02

05 Mar '02

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Minor accumulated updates.

1 0

N�o Compre... Alugue!
by Bordeaux Buffet 04 Mar '02

04 Mar '02

1 0

forwarded message from Stephen J. Turnbull
by barry＠zope.com 04 Mar '02

04 Mar '02

With permission from Stephen Turnbull, XEmacs' lead maintainer, I am forwarding this response of his to my questions about XEmacs support for the coding cookie. Stephen asked me to include this preamble: So send it but please tag the forward with the gloss that the main content is (1) XEmacs will support the coding cookie for editing purposes, but (2) cookies can not be relied on in practice---it should be treated as a halfway house[1] for people who don't presently have the resources to convert to Unicode. Footnotes: [1] In the addiction rehabilitation sense. I'm hoping that Stephen will soon be able to join the python-dev discussions more directly, and I'm cc'ing him on this message. I admit to wearing the typical American sunglasses on this issue, MM2.1 not withstanding. I think Stephen's view point and experience with this issue is worth bringing up here. -Barry

9 13

Re: [Python-Dev] datetime +/- scalars (int, long, float)?
by Michael Hudson 04 Mar '02

04 Mar '02

Kevin Jacobs <jacobs(a)penguin.theopalgroup.com> writes: > On Mon, 4 Mar 2002, Guido van Rossum wrote: > > > You should name the type timestamp if you want to imply dt + n > > > == dt + n seconds. datetime + n is commonly understood as > > > dt + n *days*. > [...] > > Is this just an mxDateTime convention, or is it in wider use? (URLs > > of docs of other languages / libraries would really help to convince > > me!) > > I'm afraid that this really is the de-facto standard. However, lets be > clear; is t=t+1 adding 1 (calendar) day or 24 hours (86400 seconds)? Wouldn't this fall into the "explicit is better than implicit" bin? I.e. t + 1 should be an error? Cheers, M. -- US elections For those of you fearing that the rest of the world might be making fun of the US because of this: Rest assured, we are. -- http://www.advogato.org/person/jameson/diary.html?start=12

1 0

Psyco testing results
by Itamar Shtull-Trauring 02 Mar '02

02 Mar '02

I downloaded psyco yesterday and did some tests (Python 2.1, P3/866). It works! Basically, the key point is that you need to psyco.bind on the right functions. Doing psyco.gc() just slows things down. It takes a bit of testing to find out which functions to do it on. Results: pystone without psyco: 9000 pystone with psyco: 32000!!! (I did psyco.bind(Proc0) in psytone.py) pystone with psyco.gc(): 4500 So pystone can speed things up by a factor of 3 on meaningless benchmarks ;) I also got a small speedup in twisted.web - 305-320 hits/second instead of 275-285 hits/second, by doing psyco.bind on the function that runs select.select() (Twisted's equivalent of asyncore.poll()).

3 3

help debugging thread deadlocks
by Russ Cox 02 Mar '02

02 Mar '02

If this should be in python-list, say so and I'll move, but python-dev seemed a better match. I've got a python program that's hanging in PyThread_acquire_lock called from fast_cfunction, which I assume means the python program itself is calling the acquire method on a python-allocated (as opposed to C-allocated) lock. There are two threads and both are hung trying to acquire different locks. Unfortunately that's all I can tell from the stack trace. My python program allocates three locks using threading.RLock, and I can't find any other python code (in the standard modules), but the locks that are hanging are not those three locks. I looked in the standard module library code and can't find any that allocate locks. There are some locks allocated in the C interpreter, of course, but I don't see how those would be acquirable from python code. Is there some function I can call from within acquire_lock or allocate_lock (from C) to dump a python stack trace to stdout or stderr? Thanks. Russ

2 1

Advance notice of extensive commit
by Andrew MacIntyre 02 Mar '02

02 Mar '02

As the final phase of committing the OS/2 EMX port, I plan to commit changes to the following files in Modules/ _hotshot.c dbmmodule.c fcntlmodule.c main.c posixmodule.c (extensive changes) pwdmodule.c readline.c selectmodule.c signalmodule.c socketmodule.c (extensive changes) termios.c timemodule.c unicodedata.c All these changes are #ifdef'ed and a patched tree builds and passes regression tests on FreeBSD 4.4, so I don't envision any problems. This is the Modules part of SF patch #450267. I expect to commit these changes between 1000 and 1400 AEST (UTC+1100) tomorrow, Sunday 3 March. If anyone else is planning to commit to these files in this timeframe, or there is some reason not to proceed, please e-mail me before 0500 AEST tomorrow (my offline e-mail collection/CVS update time, though I do a CVS update immediately before contemplating a commit). Cheers. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 andymac(a)pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

1 0

Re: [Python-Dev] proposal: add basic time type to the standard library
by Guido van Rossum 02 Mar '02

02 Mar '02

We had a brief jam on date/time objects at Zope Corp. HQ today. I won't get to writing up the full proposal that came out of this, but I'd like to give at least a summary. (Th0se who were there: my thoughts have advanced a bit since this afternoon.) My plan is to create a standard timestamp object in C that can be subclassed. The internal representation will favor extraction of broken-out time fields (year etc.) in local time. It will support comparison, basic time computations, and effbot's minimal API, as well as conversions to and from the two currently most popular time representations used by the time module: posix timestamps in UTC and 9-tuples in local time. There will be a C API. Proposal for internal representation (also the basis for an efficient pickle format): year 2 bytes, big-endian, unsigned (0 .. 65535) month 1 byte day 1 byte hour 1 byte minute 1 byte second 1 byte usecond 3 bytes, big-endian tzoffset 2 bytes, big-endian, signed (in minutes, -1439 .. 1439) total 12 bytes Things this will not address (but which you may address through subclassing): - leap seconds - alternate calendars - years far in the future or BC - precision of timepoints (e.g. a separate Date type) - DST flags (DST is accounted for by the tzoffset field) Mini-FAQ - Why store a broken-out local time rather than seconds (or microseconds) relative to an epoch in UTC? There are two kinds of operations on times: accessing the broken-out fields (probably in local time), and time computations. The chosen representation favors accessing broken-out fields, which I expect to be more common than time computations. - Why a big-endian internal representation? So that comparison can be done using a single memcmp() call as long as the tzoffset fields are the same. - Why not pack the fields closer to save a few bytes? To make the pack and unpack operations more efficient; the object footprint isn't going to make much of a difference. - Why is the year unsigned? So memcmp() will do the right thing for comparing dates (in the same timezone). - What's the magic number 1439? One less than 24 * 60. Timezone offsets may be up to 24 hours. (The C99 standard does it this way.) I'll try to turn this into a proper PEP ASAP. (Stephan: do I need to CC you or are you reading python-dev?) --Guido van Rossum (home page: http://www.python.org/~guido/)

4 6

Re: [Python-Dev] setup.py deleting files (Was: SSL support in _socket)
by Michael Hudson 01 Mar '02

01 Mar '02

Martin von Loewis <loewis(a)informatik.hu-berlin.de> writes: > Michael Hudson <mwh(a)python.net> writes: > > > > Can we just rename them? I.e. bsddbmodule-failed.so > > > > So long as it's bsddbmodule_failed.so, +1. > > > > It shouldn't be difficult. > > +1. It's about this hard, in fact: Index: setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.82 diff -c -r1.82 setup.py *** setup.py 16 Feb 2002 18:23:29 -0000 1.82 --- setup.py 1 Mar 2002 13:35:04 -0000 *************** *** 176,188 **** except ImportError, why: if 1: ! self.announce('*** WARNING: removing "%s" since importing it' ' failed: %s' % (ext.name, why)) assert not self.inplace ! fullname = self.get_ext_fullname(ext.name) ! ext_filename = os.path.join(self.build_lib, ! self.get_ext_filename(fullname)) ! os.remove(ext_filename) # XXX -- This relies on a Vile HACK in # distutils.command.build_ext.build_extension(). The --- 176,187 ---- except ImportError, why: if 1: ! self.announce('*** WARNING: renaming "%s" since importing it' ' failed: %s' % (ext.name, why)) assert not self.inplace ! basename, tail = os.path.splitext(ext_filename) ! newname = basename + "_failed" + tail ! os.rename(ext_filename, newname) # XXX -- This relies on a Vile HACK in # distutils.command.build_ext.build_extension(). The One little point (or I'd have checked it in already): should we make efforts to not install the _failed.so turds? Cheers, M. -- C is not clean -- the language has _many_ gotchas and traps, and although its semantics are _simple_ in some sense, it is not any cleaner than the assembly-language design it is based on. -- Erik Naggum, comp.lang.lisp

3 2

proposal: add basic time type to the standard library
by Fredrik Lundh 01 Mar '02

01 Mar '02

I propose adding a basic time type (or time base type ;-) to the standard library, which can be subclassed by more elaborate date/time/timestamp implementations, such as mxDateTime, custom types provided by DB-API drivers, etc. The goal is to make it easy to extract the year, month, day, hour, minute, and second from any given time object. Or to put it another way, I want the following to work for any time object, including mxDateTime objects, any date/timestamp returned by a DB-API driver, and weird date/time-like types I've developed myself: if isinstance(t, basetime): # yay! it's a timestamp print t.timetuple() The goal is not to standardize any behaviour beyond this; anything else should be provided by subtypes. More details here: http://effbot.org/ideas/time-type.htm I can produce PEP and patch if necessary. </F>

14 79

Python-Dev March 2002