Mailman 3 June 2000 - Python-Dev

Re: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache]
by Jack Jansen 26 Jun '00

26 Jun '00

> Actually, I'd be glad to give you committer status (your colleague > Sjoerd just got his :-). I expect that the majority of the > subscribers to python-dev can be trusted as committers. Oww, grumble grumble... Okay, I'll apply for committer status. So there. > BTW, I would heartily recommend putting the Macintosh tree for Python > under SourceForge! I don't think MacCVS can do ssh authorization, and if I followed the discussion here that is needed, right? But if that hurdle can be taken: fine! -- 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

1 0

Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing)
by Greg Stein 26 Jun '00

26 Jun '00

On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote: > Greg Stein: > > When could I get to it? eek. I *will*, but dunno when. It is amazing just > > how much stuff can fall on a person's plate despite having no job :-). I've > > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil > > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading > > changes, Python/Apache integration, and coding for Subversion. Fuggin > > frightening. > > Ooh! Ooh! Can you tell us more about the Python/Apache integration item? > We've been discussing distributing a 4Suite kit bundled with PyApache, but > that package is quite complex and I'm not sure how strongly maintained. Are > you talking about improvements to PyApache? Another approach entirely > (PyApache still has much more overhead than, say mod_perl)? Do you have an > approximate time-line? A project URL? There are several Python/Apache efforts (where Python is embedded into the Apache process): *) PyApache: essentially this is just a CGI accelerator. Take a standard CGI script and it will "run faster." (URL? dunno) *) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its version 2.4, it is still a bit rough. I've been working with the author to improve the code. I did a code review a while back with a lot of suggestions. It is reasonable, but not as mature as mod_perl. http://www.modpython.org/ *) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0, with the intent of making use of Apache 2.0's threadedness (plus a few of A2's other internal features). The code is very good looking. - available at SourceForge *) mod_slimpy: my name for an Apache 2.0 module which will be even lighter weight than mod_snake. There will be only the slimmest layer of C code to interface Apache and Python. Most/all operational logic will be deferred to the Python side. I've used this design to good effect in some of the Python/COM work and its univgw package in particular. Obviously, the latter two will compete, but oh well :-). The first two fit their problem environment without particular complications. When I start the mod_slimpy work, I'm also going to push on setting up python.apache.org. Essentially, it will host (under the ASF umbrella) the mod_slimpy work plus any other efforts that may want to operate there. I'm going to ask the authors of the other packages whether they would like to be hosted there, too. Of course, python.apache.org can host any Python project. It doesn't have to be related to the web server, or any other ASF project for that matter. Consider all the non-web stuff that operates under xml.apache.org, java.apache.org, and jakarta.apache.org. Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0

[rasmus@apache.org: Re: PMCs and Apache]
by Greg Stein 25 Jun '00

25 Jun '00

Woah... this is an interesting factoid about the number of committers for a project. I had no idea PHP had this many... Can this work with Python? Dunno. I think if a "true core" group pays attention to the -checkins alias, then yah. If that review is ever lost, then those "edge" committers could introduce crap. I'm not asking for more committers to Python. But if some people were worried about the "explosion" of committers from about six a couple months ago to the current 13, then just look to PHP and count your thanks :-) Mostly, this email is for pondering... Cheers, -g ----- Forwarded message from Rasmus Lerdorf <rasmus(a)apache.org> ----- Reply-To: members(a)apache.org Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT) From: Rasmus Lerdorf <rasmus(a)apache.org> To: members(a)apache.org Subject: Re: PMCs and Apache > More relevant is the process by which I became a contributor. For PHP, I > sent a note describing what I was exploring, and I was sent a note with a > password. I didn't know CVS. I didn't know PHP. I didn't know open > source. But like a stranger offering to help at a barn raising, I was > simply handed a hammer and expected to get busy. That has always been the atmosphere. It isn't quite as free as that. We get 10-20 cvs write account requests every week and tend to only hand out 1 or 2 actual accounts. There are a lot of clueless people out there. However, if the person has shown any sign of being competent by explaining in a rational manner what they plan on working on, I see no reason not to let them bash away. Reversing somebodys' changes and removing a cvs account is trivial, and in the past 5 years we have yet to revoke an account. We have reversed changes of course, but even that doesn't happen too often. There are currently 165 people with write access to the PHP source tree. This does also relate to the fact that the PHP project is a very broad project. No single person could possibly know all 16 supported low-level database apis, for example. For other projects with a much more limited scope, this approach is probably not optimal, but for PHP it works nicely. Someone will write a bit of broken code that shows some good ideas, and others will pounce on it and fix it. Often the people who fix it are poor sods who tried to use the broken feature and had to dive in and fix it themselves. They request a cvs account to do this, and they are hooked. They tend to never stop at fixing just one thing once they have been given the golden keys. This approach has also done wonders for the PHP documentation. The current manual is around 1100 pages long and has been fully translated to German, Italian and Japanese with more languages on the way. (check out http://snaps.php.net/manual/) -Rasmus ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/

1 0

test failures...
by Skip Montanaro 25 Jun '00

25 Jun '00

Using the latest CVS code, I get failures for three tests on my Linux Mandrake 6.1 laptop: test test_exceptions failed -- Writing: 'spam', expected: 'Attr' test test_types crashed -- exceptions.OverflowError : long int too long to convert test test_long failed -- int(long(-sys.maxint-1)) overflowed! Are these known/expected or unknown/unexpected failures?

7 11

updated exit.py and supporting files for your perusal
by Skip Montanaro 25 Jun '00

25 Jun '00

This message contains four attached files: Lib/exit.py - a module that allows users to register cleanup functions Lib/test/test_exit.py - a simple test script Lib/test/output/test_exit - expected test output Doc/lib/libexit.tex - library reference manual section Besides adding documentation and a test script, the following two mods were made to exit.py since I previously posted it: 1. It implements a LIFO execution order 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is treated as an exit function and appended to the exit function list. Comments, please. Also, can someone tell me how to coax CVS into creating a unified diff that actually contains new files? I tried cvs diff -RNau without success. Thanks, -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 """ exit.py - allow programmer to define multiple exit functions to be executed upon normal program termination. One public function, register_exitfunc, is defined. """ _exithandlers = [] def _run_exitfuncs(): """run any registered exit functions _exithandlers is traversed in reverse order so functions are executed last in, first out. """ while _exithandlers: func, targs, kargs = _exithandlers[-1] apply(func, targs, kargs) _exithandlers.remove(_exithandlers[-1]) def register_exitfunc(func, *targs, **kargs): """register a function to be executed upon normal program termination func - function to be called at exit targs - optional arguments to pass to func kargs - optional keyword arguments to pass to func """ _exithandlers.append((func, targs, kargs)) import sys try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs else: # if x isn't our own exit func executive, assume it's another # registered exit function - append it to our list... if x != _run_exitfuncs: register_exitfunc(x) del sys if __name__ == "__main__": def x1(): print "running x1" def x2(n): print "running x2(%s)" % `n` def x3(n, kwd=None): print "running x3(%s, kwd=%s)" % (`n`, `kwd`) register_exitfunc(x1) register_exitfunc(x2, 12) register_exitfunc(x3, 5, "bar") register_exitfunc(x3, "no kwd args") # Test the exit module from test_support import verbose import exit def handler1(): print "handler1" def handler2(*args, **kargs): print "handler2", args, kargs # save any exit functions that may have been registered as part of the # test framework _exithandlers = exit._exithandlers exit._exithandlers = [] exit.register_exitfunc(handler1) exit.register_exitfunc(handler2) exit.register_exitfunc(handler2, 7, kw="abc") # simulate exit behavior by calling exit._run_exitfuncs directly... exit._run_exitfuncs() # restore exit handlers exit._exithandlers = _exithandlers test_exit handler2 (7,) {'kw': 'abc'} handler2 () {} handler1 \section{\module{exit} --- exit handlers} \declaremodule{standard}{exit} \sectionauthor{Skip Montanaro}{skip(a)mojam.com} \modulesynopsis{Register and execute cleanup functions.} The \module{exit} module defines a single function to register cleanup functions. Functions thus registered are automatically executed upon normal interpreter termination. \begin{funcdesc}{register_exitfunc}{func\optional{, *args\optional{, **kargs}}} Register \code{func} as a function to be executed at termination. Any optional arguments that are to be passed to func must be passed as arguments to \func{register_exitfunc}. At normal program termination (for instance, if \func{sys.exit} is called or the main module's execution completes), all functions registered are called in last in, first out order. The assumption is that lower level modules will normally be imported before higher level modules and thus must be cleaned up later. \subsection{Example} The following simple example demonstrates how a module can initialize a counter from a file when it is imported and save the counter's updated value automatically when the program terminates. \begin{verbatim} try: _count = eval(open("/tmp/counter").read()) except IOError: _count = 0 def incrcounter(n): global _count _count = _count + n def savecounter(): open("/tmp/counter", "w").write("%d" % _count) import exit exit.register_exitfunc(savecounter) \end{verbatim}

10 17

atexit.py patch
by Skip Montanaro 25 Jun '00

25 Jun '00

Here's the latest version of my exit module. Per the earlier discussion, the module has been renamed to atexit.py. I also took the suggestion from someone (Guido?) that the registration function be renamed to simply "register". Other than that everything else should be the same. I'm only sending this to python-dev, operating under the assumption that the patches list is about to take a long vacation... -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings."

2 1

Fwd: Re: Linux/NT python startup speed
by Neil Schemenauer 24 Jun '00

24 Jun '00

Has this been addressed yet for 1.6? It is probably an easy fix. The original poster claimed it took 4 seconds to start Python on his machine. Neil ----- Forwarded message from Johannes Stezenbach <yawyi(a)gmx.de> ----- Date: Thu, 22 Jun 2000 15:03:01 +0200 From: yawyi(a)gmx.de (Johannes Stezenbach) Subject: Re: Linux/NT python startup speed Niklas Frykholm <r2d2(a)mao.acc.umu.se> wrote: >Can someone explain this difference. (The processor on the Linux system is >certainly not 40 times faster.) This was discussed here a few months ago. The reason for the slow startup is the winsound module (source: PC/winsound.c) which is unnecessarily a builtin. winsound causes Python to load the Windows multimedia DLLs, which can be slow if your sound drivers make it so. Two solutions were discussed: a) make winsound a .pyd b) use some obscure "delayload" feature of the M$ linker. There is a ready to use python15.dll for Python 1.5.2 with this feature somewhere out there (I don't remember where, though, since I use Linux now) IMHO solution a) should be standard in Python 1.6 (it isn't in 1.6a2). Johannes ----- End forwarded message -----

2 1

out of touch
by Fred L. Drake, Jr. 24 Jun '00

24 Jun '00

My laptop has died, so I'm catching up with a couple of days of mail. I've not had time to look at Paul's proposed DOM-like additions to the standard library. Hopefully Andrew can (or has) summarized the relevant portions of our discussion from yesterday; if I don't see it, I'll try to get another message out later. (But I don't have my saved mail or files, so there's still not a lot I can do. ;( ) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

1 0

Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37
by Neil Schemenauer 24 Jun '00

24 Jun '00

On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote: > Round 1 of Neil Schemenauer's GC patches: Yay. :) > + class_traverse(PyClassObject *o, visitproc visit, void *arg) > + { ... > + return 0; > + } > + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg) > + { ... > + return 1; > + } Oops. I think "return 0" is the proper thing to do. There are a few other functions that return 1 as well. Neil

1 0

list comprehensions
by Skip Montanaro 24 Jun '00

24 Jun '00

Did list comprehensions ever make it into 1.6? I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list? -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395

9 10