Mailman 3 February 2004 - Python-Dev

RE: [Python-Dev] What is the ":" for in python?
by Michael Chermside 27 Feb '04

27 Feb '04

> I was asked why python required a ":" in its syntax and then saw > Pete Shinners query on changing the parser to treat "def" to ":" as a unit. > > What is the purpose of the ":"? > > Why doesn't the parser work as Pete suggests already? > Of course the same rules should be true of "if" and ":", "while" and ":" If I recall correctly, the original reason for the ":" is that the designers of ABC (which provided much of the original inspiration for Python) conducted a study and found that people recognized block boundaries better if they were introduced by a ":" in addition to being indentation delimited then if they were just indentation delimited. For more details see this posting of Tim's: http://mail.python.org/pipermail/python-list/2000-December/022506.html > if x > 10 > and x < 20: > do_in_range() > > rather then > > if( x > 10 > and x < 20 ): > do_in_range() Interesting. Everyone has their own preferences, but I find BOTH of these very difficult to read. I would prefer if (x > 10 and x < 20): do_in_range() Of course if (10 < x < 20): do_in_range() is even better <wink>. -- Michael Chermside

1 0

Sprint on Stackless Python March 10-14 in Berlin
by Christian Tismer 27 Feb '04

27 Feb '04

As already announced, the *********************************************** *** *** *** S t a c k l e s s S p r i n t *** *** *** *********************************************** has now a settled date: It will take place in Berlin, March 10-14 2004. We will have a room in the Free University of Berlin in Berlin-Dahlem. Address and room will be announced, soon. How to attend? See bottom of this message. Contents? Well, there is a lot possible. Current topics which come into mind are * autoscheduling * scheduling object * brain storming! * Zope Wiki and Documentation * making channels really stackless * demo applications * more regression tests * real zope apps? * refactoring Stackless: simpler and configurable * create a Stackless tutorial * minimalist Stackless Python with no hardware dependency * assembly-free Stackless with setjmp/longjmp * spreading the internals between developers but this is completely open for discussion. Level? Well, it will be a bit simpler than the pypy-sprints, which I think are very difficult, but Stackless has its built-in difficulties by nature. Usability? This is by far, now and forever, the best possible way to learn about Stackless Python and to become a core developer. But no guarantee possible :-) Payback? Well, it is intended that Stackless Python should be developed further. If you are using or planning to use Stackless for your products, you are highly encouraged to support Stackless Python by money and by submitting your best developers, regardless how painfully they are going to be missed by the company. Coaching? Yes, it is probable and whished, that Stackless Python will become a topic for training and coaching. First of all, we will try to leverage our knowledge. Fun? Guaranteed. Schedule -------- There is no particular schedule, yet, but for the first day. I am planning to give a talk on Stackless technology, and to be available for questions and discussion during the whole first day. Attendees with small or no knowledge about Stackless Python are strongly encouraged to join that session. Accomodation ------------ There are no special arrangements planned. We hope to find a place for every external sprinter at the home of the Berlin habitants. I'm taking two already, please don't ask. How to attend: -------------- Please subscribe to the mailing list stackless-sprint(a)stackless.com which you can find via this interface: http://www.stackless.com/mailman/listinfo/stackless-sprint By subscribing, you state that you want to come to the sprint. We have only limited reources left and can take only a few. ------- I hereby wish to thank *Dirk Pape* and *Christoph v. Stuckrad* from FU Berlin for making this event possible! cheers - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

1 0

new syntax for wrapping (PEP 318) - Timothy's summary
by Jewett, Jim J 27 Feb '04

27 Feb '04

Delaney, Timothy C (Timothy): > a. def foo (bar) [baz]: > b. def foo (bar) as baz: > c. def [baz] foo (bar): Note that c. is like Quixote > d. def baz foo (bar): > e. def foo [baz] (bar): > (1b) is the most visually pleasing, but the > lack of syntax means that the decorator doesn't > stand out as well as (a). However, it's simple > to syntax-colour 'as', so that's close to a non-issue. > (1a) seems to be the most understandable, and is > quite visually pleasing - the decorator is obviously special, > but feels more like it's an explanatory note. You left out f. def foo (bar) mod [baz]: pass The current patch is not really using a list, it is using magic characters "[" and "]". Given that, it could as easily use magic characters "mod [" and "]" Option 1.f. still has all the syntax-coloring advantages of 1.a., but makes it more obvious that the "mod [baz]" is truly an optional annotation. ("as" is the shortest suggestion for "mod", but not the only one. Also suggested are many variations on "transformed_by", "modified_by", "decorators", "providing", "extended_by", etc.) -jJ

1 0

Re: [Python-checkins] python/dist/src/Modules cStringIO.c, 2.45, 2.46
by Thomas Heller 27 Feb '04

27 Feb '04

rhettinger(a)users.sourceforge.net writes: > if (PyObject_Size(args) < 0) return NULL; > > ! args = PyTuple_Pack(1, args); > ! if (args == NULL) > ! return NULL; > ! tmp = PyObject_Call(joiner, args, NULL); > ! Py_DECREF(args); > UNLESS (tmp) return NULL; There are both tabs and spaces in this code. Question: is there a convention about tabs and spaces in C code? Thomas

2 1

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Moore, Paul 27 Feb '04

27 Feb '04

From: Michael Hudson > "Delaney, Timothy C (Timothy)" <tdelaney(a)avaya.com> writes: >> Anyway, those are my thoughts on the whole topic. I'm: > > Nice work. > >> +1 on syntax for decorators attached to function definitions >> +1 on def foo (bar) [baz]: >> +0 on def foo (bar) as baz: if there's a way to extend it multi-line. >> -1 on all the other proposed syntaxes. >> -1 on restricting it to specific decorators such as classmethod > > I agree, FWIW. Agreed, on all counts. Also, while people are currently coming up with some fairly extreme uses of the new feature, I don't think that's a particularly bad thing. As with any new construct, it can be abused, but in practice, good taste will prevail, and in the meantime, the experimentation just proves the flexibility of the feature. Paul.

1 0

Accumulation module
by Tony Vignaux 26 Feb '04

26 Feb '04

Raymond, You asked: > * Is there a way to compute the standard deviation without multiple > passes over the data (one to compute the mean and a second to sum the > squares of the differences from the mean? > > I do not understand the problem in getting stdev in a single pass. Perhaps I not understood your problem. If you have a series of values you merely have to calculate their sum and sum-of-squares and use the usual formula. Ignore this if this is dumb. -- Prof G A Vignaux Mathematical and Computing Sciences, Victoria University, PO Box 600, Work: +64 4 463 5276 Wellington, NZ Home: +64 4 934 7851 Tony.Vignaux.Remove_This_Bit(a)mcs.vuw.ac.nz Mobile: +64 21 89 7851 http://www.mcs.vuw.ac.nz/~vignaux

4 4

threading issue: preventing starting twice
by Russell E. Owen 26 Feb '04

26 Feb '04

In the threading module, one must of course only start a thread once. I have some questions about handling this gracefully. First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)? Anyway, if it is always AssertionError, I'd like to get the docs updated to say that. Also...if possible, it'd be nice to have some way to ask if a thread has ever been started. More generally, it'd be nice to be able to determine what state a thread is in. I'm not sure if there are any states other than ready to run, running and finished. If that's it, perhaps one could add methods isReady and didRun (a getState method would probably be better if there are more states, but then one has to deal with magic constants). I realize it is a common Python paradigm to assume something will work (such as starting the thread) and catch the exception if it doesn't, but: - this is tricky if the exception is not documented - sometimes one simply wants to know, without actually starting the thread -- Russell

3 5

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Jewett, Jim J 26 Feb '04

26 Feb '04

Pete Shinners: > Some of these may even be bad ideas apon further > thought, but it's something to ponder. Also, many of them don't work with the proposed syntax. Specifically, you're trying to provide a second binding for the function (such as running for __main__, or registering with the exit handler). For me, this is the most common use case, but ... PEP 318 doesn't handle it. (Which is one reason that I don't think this will be the *last* extension, which is one reason I don't want *bare* syntax.) Skip: > Quixote'd PTL uses almost this exact syntax to > distinguish between PTL functions/methods which > return HTML or plain text. The only difference > is that it places the annotation before the argument > list: > def head [html] (title): > I haven't heard any Quixote users complain about the > construct. But they do warn you that it doesn't quite work with standard python. Nobody comes across this syntax until they have gone out of their way to expect it. Even so, would it be better or worse for them to start finding code that says def head [classmethod] (title): I realize that the new syntax (patch version) would actually say something more like def head [html](title)[classmethod]: which goes a fair way toward exhausting special syntax. If they want to get more detailed (xml vs html, only do this if the user is authenticated, etc), then the new syntax starts to be useful to them as well. def head(title) decorators[html4, authenticated_user]: Even if the two cases are combined, I don't see it as useful enough to use up bare syntax. (And so I suggest yet another possible keyword, "decorators") Paul Prescod: > C# allows the wrapping of attributes, not just > functions and classes. > In Python this could be accomplished if we used > delimiters that didn't look like lists (e.g. <> or [! !]). Do this sort of thing often enough, and you have a keyword anyhow -- it just happens to look like line noise. > C# distinguishes between bareword declarations like > "public" and "int" and metadata attachments like > XML serialization information. ... > The Java way does make clear what is a language builtin > ("public", "void") and what is extension metadata > "@remote", "@debug". That may not be a bad thing... Unless we define a specific list (just classmethod and staticmethod?), then this might be more confusing than useful. in __builtins__? In the current standard library? in another module that might become standard someday? Skip Montanaro: > If anything, features which are expected to be used by > more advanced users should require less "COBOL" to be > useful. I'm not arguing that the zen of Python shouldn't > apply, just that advanced features (which will probably > be used a lot less than more basic features) don't > necessarily need quite the English-like structure supporting > them in the language syntax. Features which are used frequently need to be short. Features which are used rarely (like this one?) can be more verbose. I agree that if only advanced users will need it, then it can be a bit more complex to use. It should absolutely not be harder to recognize as irrelevant. If you use an almost meaningless keyword like "extended_syntax_form_a", then the only extra burden is on the advanced users who actually use it. (This is one reason that I'm not too concerned over *which* keyword gets used.) If you use bare syntax, then the burden is on everyone, and you have raised the barrier to entry for the rest of the language. Paul Moore: > Exactly. As a beginner, classes were more advanced than > you needed. So the (relative) difficulty of finding the > relevant details wasn't an issue - you just didn't use > the feature for a while. By the time you needed classes, > you were familiar enough with Python to know where to look. I have never *needed* classes, and have a bias towards functions. If *functions* had seemed awkward, I would have chosen another language instead. People with a bias towards objects - or wanting to learn about them - may well have different criteria. (In real life, most object systems are pretty wordy, so this particular concern may not bother OO folk as much. But the main use cases are for functions.) -jJ

6 11

Weekly Python Bug/Patch Summary
by Kurt B. Kaiser 26 Feb '04

26 Feb '04

Patch / Bug Summary ___________________ Patches : 243 open ( +2) / 2319 closed ( +4) / 2562 total ( +6) Bugs : 728 open (+17) / 3904 closed (+12) / 4632 total (+29) RFE : 130 open ( +3) / 119 closed ( +1) / 249 total ( +4) New / Reopened Patches ______________________ Add Py_InitializeEx to allow embedding without signals. (2004-02-19) http://python.org/sf/900727 opened by Dave Wilson catch invalid chunk length in httplib read routine (2004-02-20) http://python.org/sf/900744 opened by Wummel markupbase misses comments (bug 736659) (2004-02-20) http://python.org/sf/901369 opened by Jim Jewett urllib2.parse_http_list bugfix 735248 (2004-02-20) http://python.org/sf/901480 opened by Jim Jewett FreeBSD new pthread problem with system scope (2004-02-23) http://python.org/sf/902444 opened by Hye-Shik Chang dict.update should take a 2-tuple sequence like dict.__init_ (2004-02-25) http://python.org/sf/904720 opened by Bob Ippolito Patches Closed ______________ bdist_wininst pre-install script, and --target-version fix (2004-02-08) http://python.org/sf/892660 closed by theller logging says to call shutdown - make it more likely (2004-01-21) http://python.org/sf/881676 closed by vsajip Refactored patch #815911 for logging with SocketHandler (2003-12-01) http://python.org/sf/851993 closed by vsajip Extension logging.handlers.SocketHandler (2003-10-01) http://python.org/sf/815911 closed by vsajip New / Reopened Bugs ___________________ Duplicated <link rel="next"> in <head> (2004-02-18) http://python.org/sf/899423 opened by Joseph Walton 1==float('nan') (2004-02-17) http://python.org/sf/899109 reopened by mwh optparse: usage issues (2004-02-19) http://python.org/sf/900071 opened by Simon Dahlbacka hotshot.stats.load (2004-02-19) http://python.org/sf/900092 opened by Simon Dahlbacka cgi.fieldStorage doesn't grok standards env. variables (2004-02-19) http://python.org/sf/900112 opened by Dominique Hazaël-Massieux win shell interpreter error (arithmetic) (2004-02-19) http://python.org/sf/900494 opened by Mark Okamura IDLE docs broken on OSX (2004-02-19) http://python.org/sf/900580 opened by Jonathan Brandmeyer add logging.shutdown() to python logging module example code (2004-02-19) http://python.org/sf/900626 opened by Manuel Schulte urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr (2004-02-20) http://python.org/sf/900898 opened by James Kruth plat-mac/videoreader.py not working on OS X (2004-02-20) http://python.org/sf/900949 opened by Dinu C. Gherman cygwinccompiler.get_versions fails on `ld -v` output (2004-02-20) http://python.org/sf/900977 opened by Pearu Peterson strange behaviour of xmlrpclib.Server proxy (2004-02-20) http://python.org/sf/901198 opened by Andreas Eisele random.randint fails for some ranges (2004-02-20) http://python.org/sf/901285 opened by paul rubin logging handlers can close without flush (2004-02-20) http://python.org/sf/901330 opened by Jim Jewett random.seed not initialized as advertised (2004-02-21) http://python.org/sf/901605 opened by paul rubin split method documentation can be improved (2004-02-21) http://python.org/sf/901654 opened by Sjoerd Mullender extra_path kwarg to setup() undocumented (2004-02-21) http://python.org/sf/901727 opened by Bob Ippolito relative on-disk SYSTEM id handling is incorrect (2004-02-22) http://python.org/sf/902037 opened by Bob Ippolito pydoc insists upon producing file: URLs (2004-02-22) http://python.org/sf/902061 opened by Matthias Klose fails building C++ extensions when configured --without-cxx (2004-02-22) http://python.org/sf/902065 opened by Matthias Klose urllib2 should be more robust for sloppy proxy URLs (2004-02-22) http://python.org/sf/902075 opened by Matthias Klose Thread start - strange error under Cygwin (2004-02-22) http://python.org/sf/902151 opened by Artur de Sousa Rocha Timezone miscalculation (time.mktime) (2004-02-22) http://python.org/sf/902172 opened by Marti Raudsepp Encodings: koi8-u.py -- errata in decoding map (2004-02-23) http://python.org/sf/902501 opened by Alexander Belchenko doctest confused by super-instances in class-dicts (2004-02-23) http://python.org/sf/902628 opened by Christian Tanzer help("exec") doesn't work (2004-02-23) http://python.org/sf/902998 opened by Tom Lynn OpenVMS file system and UNIVERSAL_NEWLINES support (2004-02-24) http://python.org/sf/903339 opened by Piéronne Jean-François cPickle/pickle incompatibility (2004-02-24) http://python.org/sf/903483 reopened by tismer File read of Chinese utf-16-le treats upper byte 1A as EOF (2004-02-25) http://python.org/sf/904474 opened by Ron Rother threading docs, start error should be specified (2004-02-25) http://python.org/sf/904498 opened by Russell Owen test_tcl fails -- "can't find package Tclx" (2004-02-26) http://python.org/sf/905046 opened by Michael Hudson Bugs Closed ___________ 1==float('nan') (2004-02-17) http://python.org/sf/899109 closed by mwh win shell interpreter error (arithmetic) (2004-02-19) http://python.org/sf/900494 closed by tim_one add logging.shutdown() to python logging module example code (2004-02-19) http://python.org/sf/900626 closed by vsajip logging.shutdown() exception (2003-11-14) http://python.org/sf/842170 closed by vsajip random.randint fails for some ranges (2004-02-20) http://python.org/sf/901285 closed by rhettinger logging handlers can close without flush (2004-02-20) http://python.org/sf/901330 closed by vsajip random.seed not initialized as advertised (2004-02-21) http://python.org/sf/901605 closed by rhettinger Incorrect ZeroDivisionError message with __future__ division (2004-01-26) http://python.org/sf/884841 closed by rhettinger Timezone miscalculation (time.mktime) (2004-02-22) http://python.org/sf/902172 closed by sipsick Encodings: koi8-u.py -- errata in decoding map (2004-02-23) http://python.org/sf/902501 closed by lemburg help("exec") doesn't work (2004-02-23) http://python.org/sf/902998 closed by tlynn cPickle/pickle incompatibility (2004-02-24) http://python.org/sf/903483 closed by tismer codecs.open().readlines(sizehint) bug (2003-11-18) http://python.org/sf/844561 closed by lemburg bsddb btree set_location() semantics changed (2003-08-13) http://python.org/sf/788421 closed by greg New / Reopened RFE __________________ bundlebuilder: some way to add non-py files in packages (2004-02-19) http://python.org/sf/900502 opened by Russell Owen bundlebuilder: an arg to disable zipping the code (2004-02-19) http://python.org/sf/900506 opened by Russell Owen bundlebuilder: easily keep main routine in orig location (2004-02-19) http://python.org/sf/900514 opened by Russell Owen cPickle/pickle incompatibility (2004-02-24) http://python.org/sf/903483 opened by Christian Tismer http://doc.python.org (2004-02-25) http://python.org/sf/904770 opened by Bob Ippolito RFE Closed __________ Enable __slots__ for meta-types (2003-03-02) http://python.org/sf/696184 closed by tismer

1 0

Re: [Python-Dev] new syntax for wrapping (PEP 318)
by Phillip J. Eby 26 Feb '04

26 Feb '04

At 02:12 PM 2/26/04 -0500, Jewett, Jim J wrote: >Jim Jewett: > >> Also, many of them don't work with the proposed > >> syntax. Specifically, you're trying to provide > >> a second binding for the function (such as running > >> for __main__, or registering with the exit handler). > > >> For me, this is the most common use case, but ... > >> PEP 318 doesn't handle it. (Which is one reason > >> that I don't think this will be the *last* extension, > >> which is one reason I don't want *bare* syntax.) > >Bob Ippolito: > > Sorry, but you understate the capabilities of this new > > syntax and overestimate the need for future related syntax. > >Not really; I guess I should have left in the full original >example. > > def foo[__main__]: > >will not work. You mean: def foo()[__main__]: and it will indeed work. Just try it: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> def __main__(f): if f.func_globals['__name__']=='__main__': f() return f >>> def foo(): print "testing" >>> foo = __main__(foo) testing >>> foo <function foo at 0x00A9E990> __main__ could be defined in another module and imported. It's not specific to a particular main function. It simply runs the function if it's defined in the main program module. And in either case, it returns the original function, so that if the module is not "main", then the function is still available for importing. Thus, the 'foo' function would still be the 'foo' function, but it would also be run if it was the main module. The only remaining downside I see is that foo() could not call itself recursively, since it can run before the name 'foo' is bound to it.

1 0