Mailman 3 January 2003 - Python-Dev

Thunk expressions and thunk arguments
by Gerald S. Williams 31 Jan '03

31 Jan '03

Guido van Rossum wrote: > Note that 'property' and 'synchronized' used as examples are not new > keywords! They are just built-in objects that have the desired > semantics and know about thunks. This seems really elegant. I hope it can be worked out. One thing I find mildly disconcerting is the restriction that nothing can follow the thunk. If you can do this: a = thunkuser: thunk It seems like you should be able to do this (however unwieldy it looks): a,b = (thunkuser: thunk ), thunkuser: thunk And once you allow one-line thunks, following them in an expression won't seem quite as unwieldy: a,b = (thunkuser: thunk), (thunkuser: thunk) My discomfort is an artifact of allowing thunks to be used in expressions. The restriction seems perfectly reasonable in these contexts: thunkuser: thunk thunkuser(a): thunk > What's still missing is a way to add formal parameters to the thunk -- > I presume that J and K are evaluated before interface.interface is > called. The thunk syntax could be extended to allow this; maybe this > can too. E.g.: > > e:(x, y): > S > > would create a thunk with two formal parameters, x and y; and when e > calls the thunk, it has to call it with two arguments which will be > placed in x and y. But this is a half-baked idea, and the syntax I > show here is ambiguous. Doesn't lambda already accomplish this? Everything between "lambda" and ":" is interpreted as an argument list. In the same light, def stores the function name, interprets the argument list, and sets the function body to the thunk code. Perhaps the following could be equivalent: def func(args): body def(func) lambda args: body -Jerry

1 0

import.c:load_source_module() confusion
by Skip Montanaro 31 Jan '03

31 Jan '03

I'm working on a patch implementing PEP 304 behavior and am a little confused about how import.c:load_source_module() works. When a source module is found, it's called. The first thing it does is check for and try to read a .pyc/.pyo file: cpathname = make_compiled_pathname(pathname, buf, (size_t)MAXPATHLEN + 1); if (cpathname != NULL && (fpc = check_compiled_module(pathname, mtime, cpathname))) { co = read_compiled_module(cpathname, fpc); fclose(fpc); if (co == NULL) return NULL; if (Py_VerboseFlag) PySys_WriteStderr("import %s # precompiled from %s\n", name, cpathname); pathname = cpathname; } I don't understand why it returns when co is NULL. Shouldn't it compile the source code (later on in the function) and return the code object generated from that? It seems like it would be rare in most circumstances (unless your name is Paul DuBois ;-) for read_compiled_module() to return NULL (corrupt marshal data or a .pyc containing something other than a code object). Skip

2 2

SF patch #677429 (PEP293 callbacks)
by Walter Dörwald 31 Jan '03

31 Jan '03

SF patch #677429 (Out of bounds indizes in PEP293 callbacks) fixes a small open issue with PEP293 callbacks: How to treat negative or out-of-bounds positions returned from an error callback. This was unspecified before (the implementation silently clipped values to the valid range). MvL discovered that and requested that to PEP and docs are clarified and the implementation fixed. MvL is on vacation, so can somebody else review the patch, so it gets in before 2.3a2? Bye, Walter Dörwald

1 0

RE: [Python-Dev] Property syntax (Re: [Python-Dev] Extended Function syntax)
by Moore, Paul 31 Jan '03

31 Jan '03

From: Greg Ewing [mailto:greg@cosc.canterbury.ac.nz] > But anyway, here's another idea: > > def foo as property: I quite like this - "as" as a modifier has a bit of prior art in import, and it reads well. Paul.

1 0

thunks (for all the fish)
by Manuel Garcia 31 Jan '03

31 Jan '03

On Wed, 29 Jan 2003 23:49:05 -0500, guido(a)python.org (Guido van Rossum) wrote: >(2 or it could be compiled into a "thunk" which is somehow passed to > whatever is called to implement the xdef (like a function body). > >Variant (2) gives much more freedom; it would allow us to create >functions that can be called later, or it could be executed on the >spot to yield its dictionary. (edit) >I think a thunk should be a callable; upon execution it would return >its dict of locals. > >Maybe if a thunk contains a 'return' statement it could return the >return value instead. > >Maybe someone can find a use for a thunk containing 'yield', 'break' >or 'continue'. > >Maybe all control flow in the thunk should raise an exception that the >xdef can catch to decide what happens. Hm, if it did 'yield' >you'd like to be able to call next() on it. So maybe there should be >different types of thinks that one can distinguish. (edit) >One think I'd like to do with extensible syntax like this (and for >which xdef is a poor name) would be to define a "lock" statement, like >Java's "synchronized" block. > >Maybe it could be written like this; I made the name after xdef >optional: > > xdef (mylock) [synchronized]: > ...block... > >which would mean: > > mylock.acquire() > try: > ...block... > finally: > mylock.release() > >It would be nice if control flow statements (return, break, continue) >inside the block would somehow properly transfer control out of the >block through the finally block, so that you could write things like > > def foo(): > for i in sequence: > xdef (mylock) [synchronized]: > if ...condition...: > continue > ...more code... > if ...condition...: > break > ...yet more code... > if ...condition...: > return 42 Wow. I started thinking about this last night, and already there have been many good suggestions. I make no claims of what follows to be Pythonic or even implementable. Assume a tiny man lives in your computer, he answers to the name "Python Thunk", and he always does the right thing, very quickly. OK, a 'thunk' is a generalized generator created from an indented suite. A 'thunk' lets us react to control statements inside the thunk (or the lack of control statements). iter0 = thunk.make_g_iter( [global] [, local] ) makes this generalized iterator, and iter0.next() can return one of these tuples: ('continue', None, None), ('break', None, None), ('nested_continue', None, None), ('nested_break', None, None), ('yield', value, None), ('return', value, dict), ('dead', None, None) Everything except 'yield' implies that 'dead' will be returned next. Nothing is done to prevent these from being mixed and matched in ways that would never otherwise be allowed. In a looping situation, it would be typical to call thunk.make_g_iter() for each step of the loop. These: thunk.dict( [global] [, local] ) thunk.call( [global] [, local] ) # execute as function always do the right thing by examining the output of .next(). If they smell a 'generator' ('dead' not returned at the second .next()), they raise an Exception. There are some subtleties of global and local I am sure I am missing. However, I don't see a problem with 'global' statements in thunks. This is the cast of characters: 1 function: anon_thunk() x = f(anon_thunk()) + g(anon_thunk()): ...thunk body... the less said about this the better 1 line noise operation: magical colon x = expr: ...thunk body... which is the same as: x = expr(anon_thunk()): ...thunk body... This seems to be popular. Magical line noise ( :*.""",)r" ) is hard for new users to look up the documentation. 2 keywords: thunk_d, thunk_c thunk_d for "function-like" things thunk_c for "class-like" (???!!!) things thunk_d: takes "function arguments" in the parenthesis after the name and turns them into a 'arg_helper' function that turns (*args, **kw_args) into a dict suitable for use as a local namespace thunk_d name(func_a, func_kw_a): expr: ...thunk body... thunk_c: takes "base classes or whatever" in the parenthesis after the name and turns them into args and kw_args thunk_c name(a, kw_a): expr: ...thunk body... 2 control keywords: nested_continue, nested_break these work their way up the frame stack, looking for loops to harass (even if they might be loops in other thunks). Would a thunk always get the chance to handle 'nested_continue/nested_break' before moving up the frame stack? I can't get my head around how "try: except:" might be used to handle 'nested_continue/nested_break'. Happily, we assumed an infinitely wise, infinitely fast creature controlling all this. *** synchronized example (much hand waving): for i in sequence: syncronized(mylock): if ...condition...: continue ...more code... if ...condition...: break ...yet more code... if ...condition...: return 42 'synchronized(mylock)' gets the thunk, then does thunk.execute(), and sees if it gets back a 'continue', 'break', or 'return'. Upon seeing a 'continue' or 'break' it issues a 'nested_continue' or 'nested_break' command, which magically works its way up the frame stack to the loop, always being careful to do the right thing. *** more hand waving key, record = recordset_loop('rs1'): if no_more_keys: return None, None if key in skip_keys: continue print key print record if key == good_key: return key, record thunk.next() doesn't care if it is a function, loop, generator, whatever, so why should we? There is the equivalent of a finally: inside recordset_loop, so our recordset gets closed upon Exception. There is great flexibility in programmatically handling control statements with Python code. I can see how if you use the thunk as a body of a loop, almost any control statement could have a contextual meaning, making it valid to mix them in otherwise unsupported ways. Should this be allowed? If somebody is willing to write the code to handle all these cases, why shouldn't it be allowed? *** anon_thunk syntax: x = expr3(expr2(expr1(anon_thunk()))): ...thunk body... x = by_hook(anon_thunk()) or by_crook(anon_thunk()): ...thunk body... a,b = anon_thunk().call(): c = long_expression1(x,y) d = long_expression2(x,y) return min(c,d), max(c,d) print anon_thunk().dict()['c']: a = 'hello' b = 12 c = '%s%i' % (a,b) This isn't a syntax so much as it is a lack of syntax. Here is a shambling horror: the super-lambda. *** property example: p = property: """thunk.__doc__ docstring""" def get(self): ...body... def set(self, value): ...body... Whenever I have an object whose name is a key in a dict, I always make the name an attribute in the object too. Usually it is redundant, but when the object is considered outside of the context of the dict, where else would you get its name from? This is why I prefer the uglier "thunk_d myprop: property:"; property gets a chance to the name. thunk_d myprop: property: """thunk.__doc__ docstring""" def get(self): ...body... def set(self, value): ...body... 'property' is passed tuple ('myprop', None, thunk), and the property is made from thunk.__doc__ and thunk.dict(). *** staticmethod example: thunk_d mymethod(a1, a2, kw_a1=11, kw_a2=13): staticmethod: """thunk.__doc__ docstring""" ...function body... 'staticmethod' is passed tuple ('mymethod', arg_helper, thunk), where arg_helper(1,2,3) == { 'a1':1, 'a2':2, 'kw_a1':3, 'kw_a2':13 } 'staticmethod' makes the method from thunk.__doc__, thunk.call(), arg_helper; the method gets assigned to 'mymethod'. *** class "interface" example: thunk_c klass1(base1, base2): interface1 + interface2: """thunk.__doc__ docstring""" ...class-like body... interface3 = interface1 + interface2, and interface3 gets passed (klass1, (base1, base2), kw_args=(), thunk), and makes a class from thunk.dict() *** other stuff if anon_thunk(): # not allowed ...thunk body... # not allowed for i in expr1: # not allowed ...thunk body... # not allowed x = [: # not allowed ...thunk body... # not allowed ] # not allowed x = [anon_thunk()]: # sure, why not? ...thunk body... # sure, why not?

3 2

Re: Extended Function syntax
by Manuel Garcia 31 Jan '03

31 Jan '03

Maybe something like this would be nice: xdef myprop('myprop docstring') [property]: def __get__(self): ...body... def __set__(self, value): ...body... xdef frame1() [SunkenFrame]: xdef button1('OK') [Button]: def ClickEvent(): ...body... def GotFocus(): ...body... MouseoverText = 'Hello!' xdef text1(datasource=xyz) [TextBox]: pass xdef klass(base1, base2) [interface1, interface2]: ...class body... This is almost exactly what Arne Koewing posted: blockdef myprop [property]: def __get__(self): ... def __set__(self, value): ... def __delete__(self): ... Except I tried to make it look a bit more like 'def'. Obviously, this would go hand-in-hand with 'def' being extended to allow a list of modifiers at the end, like this: def name(args) [staticmethod]: The general syntax for 'xdef' would be something like: xdef name(arg1, arg2, kw_arg1=x, kw_arg2=y) [mod1, mod2]: ...class-like body... So this would work like: name = mod2(mod1(name, args, kw_args, dict)) I guess args and kw_args would work something like how 'bases' are collected in class definitions before being passed to metaclass __new__ and __init__. 'xdef' could return a class just as well as a property: xdef klass(base1, base2) [interface1, interface2]: ...class body... 'interface1','interface2' would have to be clever about sometimes being passed a class and sometimes being passed the tuple (name, args, kw_args, dict). In general, 'xdef' would allow metaclass-like processing on things that are not necessarily a class. Problems: (1) The main problem is that 'xdef' makes things that are pretty close to being classes. So why not just use classes? (2) Also 'xdef' is pointless without [mod1, mod2] xdef name(): would just assign the tuple (name, args, kw_args, dict) to name. (3) 'xdef' isn't a great name, because xdef abc(xyz): def abc(xyz): do completely different things. But the name should be short like 'def' so it doesn't draw much attention to itself, just as 'def' doesn't draw much attention to itself. So xdef myprop() [property]: the thing that sticks out is 'property' More bad stuff: xdef abc(xyz): return 7 would raise a 'SyntaxError: 'return' outside function' xdef name(arg1, kw_arg1=x) [mod1, mod2]: y = arg1 + kw_arg1 would raise NameError. Maybe Arne Koewing has a good idea not making it resemble 'def'.

4 6

StringIO not an iterator?
by Andrew McNamara 31 Jan '03

31 Jan '03

I've just noticed that the StringIO in CVS hasn't been updated to be an iterator, like real file objects. This probably should be fixed before 2.3 is released. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

2 1

RE: [Python-Dev] Re: native code compiler? (or, OCaml vs. Python)
by Delaney, Timothy 31 Jan '03

31 Jan '03

> From: Tim Peters [mailto:tim.one@comcast.net] > > Not any part-time volunteer. Armin did Psycho while > finishing his doctoral dissertation, and applied a > brain the size of a planet to the job, with passion. We really need him to do another doctorate. His brain is starting to shrink. Now it's down to about the size of some of the larger asteroids. Why - he actually thinks it might be possible to implement Python in Python ;) Tim Delaney

1 0

Global interpreter lock/import mechanism
by Joerg Budischewski 31 Jan '03

31 Jan '03

Hi, I am one of the authors of the python binding for the OpenOffice' component model UNO( see http://www.openoffice.org and http://www.budischewski.com/pyuno/python-bridge.html). First of all, let me say, that is real fun to work with python C API and its documentation. However, there are still some open questions, for which I haven't found an answer in the documentation. 1) I can't find an API call to get to know, whether the current thread has the global interpreter lock or not. ( A recursive lock would also help). Some background: UNO objects are also reference counted, when they get destructed, they may need to PY_DECREF python references. However, the OpenOffice object's dtor might either be called with or without global interpreter lock. I currently workaround this by delegating the PY_DECREF to a new thread, however, which has the defined state (it does not have the lock, so it must acquire it), but this is quite inefficient. 2) I would like to hook into the python import mechanism in order to introduce new classes. I currently do this by replacing the __builtin__.__dict__["__import__"] with my own version, which delegates to the original function and in case of failure tries to lookup a UNO type. This allows e.g. by writing from com.sun.star.uno import XComponent to elegantly create such UNO types. However, I think, the replace-__import__-function is quite a nasty solution, I would rather like to have an API for this. Is there an API I have overlooked (or is it planned to have something like that ? ). 3) The Python-UNO bridge can be used within the python process or within the office process itself ( so called UNO components). For the latter, the binding initializes python by calling Py_Initialize(). As you might know, OpenOffice.org comes as a binary (not in source) even on unix platforms. But I don't want to decide at buildtime, which Python version the user should use (and actually I don't want to ship python), instead I want to reuse a python version, which already exists on the system. But currently, the python unix buildprocess does not create a shared library, only a static lib (while on windows a shared library gets built). Are there any plans to add also a shared libs for unix ? Thx in advance, Joerg

4 3

python2.3 on m68k-nommu uClinux, really slow
by Brad Clements 31 Jan '03

31 Jan '03

I'm sorry if this is OT. I have just managed to get Python 2.3a running on an 8meg m68k-nommu 48MHZ (motorola uC5272 board). It's a real dog, and I'm wondering two things: 1. anyone remember pystone values from old Sun 68K machines? I've seen a report that a Psion 5 running 1.5.2 got 90 pystones (I get 72) 2. any ideas how I can speed this up? OPT=-DNDEBUG -g -O0 -Wall -Wstrict-prototypes -m5307 Some snips from pyconfig.h: #define WITH_DOC_STRINGS #undef Py_DEBUG #define WITH_PYMALLOC I haven't enabled optimatization yet because I've had such a difficult time even getting this far, I didn't want to run into compiler errors. It seems so slow, that test/testall doesn't even produce any output. At least, not after 2 minutes.. Perhaps that's a buffering issue. # ./python pystone.py nulltime 0.04 Pystone(1.1) time for 600 passes = 8.27 This machine benchmarks at 72.5514 pystones/second -- Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

2 1

Python-Dev January 2003