Mailman 3 June 2000 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1
by rob＠hooft.net 27 Jun '00

27 Jun '00

AMK> Update of /cvsroot/python/python/dist/src/Lib/curses AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079 AMK> Added Files: AMK> ascii.py textpad.py AMK> Log Message: AMK> Added two modules for ASCII characters and a simple editing form (ESR) AMK> --- NEW FILE --- AMK> # AMK> # ascii.py -- constants and memembership tests for ASCII characters AMK> # ^^^^^ two letters too much? Rob

3 2

Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3
by Greg Stein 27 Jun '00

27 Jun '00

I just don't buy this. Look at that code. Look at the definition of finally. That code simply screams for the use of finally. Eric: just what happens? What is "broke things"? Do you have a reproducible test case that I can use? In good conscience, I have to disagree with reverting this stuff. If we're seeking to make the code the best possible, then this is a backward step. Besides its redundancy, it also places the traceback into a local variable and then raises an exception -- a perfect recipe for creating a ref loop. Cheers, -g On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/curses > In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153 > > Modified Files: > wrapper.py > Log Message: > Drop back to old version of wrapper(); ESR reports that it broke things, > and I lack the time to track down the cause. > > > Index: wrapper.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** wrapper.py 2000/06/10 23:39:05 1.2 > --- wrapper.py 2000/06/27 00:50:40 1.3 > *************** > *** 18,24 **** > --- 18,26 ---- > """ > > + res = None > try: > # Initialize curses > stdscr=curses.initscr() > + > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > *************** > *** 30,39 **** > stdscr.keypad(1) > > ! return apply(func, (stdscr,) + rest) > ! > ! finally: > ! # Restore the terminal to a sane state on the way out. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > > --- 32,51 ---- > stdscr.keypad(1) > > ! res = apply(func, (stdscr,) + rest) > ! except: > ! # In the event of an error, restore the terminal > ! # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > + > + # Pass the exception upwards > + (exc_type, exc_value, exc_traceback) = sys.exc_info() > + raise exc_type, exc_value, exc_traceback > + else: > + # Set everything back to normal > + stdscr.keypad(0) > + curses.echo() ; curses.nocbreak() > + curses.endwin() # Terminate curses > > + return res > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/

5 4

winreg
by Paul Prescod 27 Jun '00

27 Jun '00

[I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant

4 10

Re: [Python-Dev] ANN: Release schedule
by Vladimir.Marangozov＠inrialpes.fr 27 Jun '00

27 Jun '00

I'm resending this msg since it didn't seem to get through the 1st time (and we're experiencing some major hw&sw router problems lately) Vladimir Marangozov wrote: > > Guido van Rossum wrote: > > > > Here at BeOpen we're scrambling to get the release schedule for the > > rest of Python 1.6 planned. We're now looking at releasing Python > > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > > This means that if SRE isn't ready, we'll go with an incomplete SRE. > > Still better than no SRE! > > > > Please, PLEASE, if you have pending patches that you think should go > > into 1.6b1, submit them to SourceForge. We'll do our best to have a > > look at every patch submitted; but don't wait until the last moment. > > So, to sum up (because I'm a bit lost after all this patch-related > messages), what should I do to avoid at best adding to the collective > burden : > > 1. Should I send patches to SF and be quiet until June 30 ? > > 2. Should I apply for privileges and spend <big time> installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? > > 3. If I volunteer for help with the patches backlog, what do I do ? > > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches(a)python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

semaphore support in thread_*.h
by David Ascher 27 Jun '00

27 Jun '00

I noticed that the support for the semaphore calls in the various thread_* is very very spotty, with a comment in the BeOS implementation that read: * Guido says not to implement this because it's not used anywhere; * I'll do it anyway, you never know when it might be handy, and it's * easy... (that last bit is not true of all implementations, apparently =). 1) Is it true that the sema_ calls are never used? 2) If yes, shouldn't we remove the sema_ calls from the thread API and have similar functionality on all platforms? (There are related issues re: for example whether async thread locking is available, whether threads are joinable or not (see thread_cthread.h), etc.) --david

3 3

Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3
by Trent Mick 27 Jun '00

27 Jun '00

On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501 > > Modified Files: > test_pyexpat.py > Log Message: > Change pyexpat test suite to exercise the .returns_unicode attribute, > parsing the sample data once with 8-bit strings and once with Unicode. > Does this require a new Lib/test/output/test_pyexpat? Trent -- Trent Mick trentm(a)activestate.com

1 0

Now that the man is back...
by Eric S. Raymond 26 Jun '00

26 Jun '00

Guido, can we get these into 1.6? They're needed for the the ncurses extensions I'm working on. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861

5 6

winreg
by Paul Prescod 26 Jun '00

26 Jun '00

I haven't seen this message come through: http://www.python.org/pipermail/python-dev/2000-June/006346.html I'm not sure if I missed it due to an email problem. Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999

1 0

Fw: Access violation when no memory
by Mark Hammond 26 Jun '00

26 Jun '00

3 3

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

26 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. This is one of the reasons I never asked for committer status: the fewer people doing commits the better. I can live with the <2days delay we had upto recently, and for now I'm expecting it to go down to that again after all the turmoil is over. -- 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