Mailman 3 October 2005 - Python-Dev

Defining properties - a use case for class decorators?
by Jim Jewett 19 Oct '05

19 Oct '05

(In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,) Nick Coghlan suggested allowing attribute references as binding targets. > x = property("Property x (must be less than 5)") > def x.get(instance): ... Josiah shivered and said it was hard to tell what was even intended, and (in http://mail.python.org/pipermail/python-dev/2005-October/057437.html) Nick agreed that it was worse than > x.get = f given: > def f(): ... Could someone explain to me why it is worse? I understand not wanting to modify object x outside of its definition. I understand that there is some trickiness about instancemethods and bound variables. But these objections seem equally strong for both forms, as well as for the current "equivalent" of def f(): ... x.get = f The first form (def x.get) at least avoids repeating (or even creating) the temporary function name. The justification for decorators was to solve this very problem within a module or class. How is this different? Is it just that attributes shouldn't be functions, and this might encourage the practice? -jJ

2 1

Re: [Python-Dev] Early PEP draft (For Python 3000?)
by Calvin Spealman 19 Oct '05

19 Oct '05

On 10/16/05, Josiah Carlson <jcarlson(a)uci.edu> wrote: > > Calvin Spealman <ironfroggy(a)gmail.com> wrote: > > > > On 10/14/05, Josiah Carlson <jcarlson(a)uci.edu> wrote: > > > > > > Calvin Spealman <ironfroggy(a)gmail.com> wrote: > > > > > > > > On 10/11/05, Eyal Lotem <eyal.lotem(a)gmail.com> wrote: > > > > > locals()['x'] = 1 # Quietly fails! > > > > > Replaced by: > > > > > frame.x = 1 # Raises error > > > > > > > > What about the possibility of making this hypothetic frame object an > > > > indexable, such that frame[0] is the current scope, frame[1] is the > > > > calling scope, etc.? On the same lines, what about closure[0] for the > > > > current frame, while closure[1] resolves to the closure the function > > > > was defined in? These would ensure that you could reliably access any > > > > namespace you would need, without nasty stack tricks and such, and > > > > would make working around some of the limitation of the closures, when > > > > you have such a need. One might even consider a __resolve__ to be > > > > defined in any namespace, allowing all the namespace resolution rules > > > > to be overridden by code at any level. > > > > > > -1000 If you want a namespace, create one and pass it around. If the > > > writer of a function or method wanted you monkeying around with a > > > namespace, they would have given you one to work with. > > > > If they want you monkeying around with their namespace or not, you can > > do so with various tricks introspecting the frame stack and other > > internals. I was merely suggesting this as something more > > standardized, perhaps across the various Python implementations. It > > would also provide a single point of restriction when you want to > > disable such things. > > What I'm saying is that whether or not you can modify the contents of > stack frames via tricks, you shouldn't. Why? Because as I said, if the > writer wanted you to be hacking around with a namespace, they should > have passed you a shared namespace. > > From what I understand, there are very few (good) reasons why a user > should muck with stack frames, among them because it is quite convenient > to write custom traceback printers (like web CGI, etc.), and if one is > tricky, limit the callers of a function/method to those "allowable". > There may be other good reasons, but until you offer a use-case that is > compelling for reasons why it should be easier to access and/or modify > the contents of stack frames, I'm going to remain at -1000. I think I was wording this badly. I meant to suggest this as a way to define nested functions (or classes?) and probably access names from various levels of scope. In this way, a nested function would be able to say "bind the name 'a' in the namespace in which I am defined to this object", thus offering more fine grained approached than the current global keyword. I know there has been talk of this issue before, but I don't know if it works with or against anything said for this previously.

2 1

Early PEP draft (For Python 3000?)
by Jim Jewett 19 Oct '05

19 Oct '05

(In http://mail.python.org/pipermail/python-dev/2005-October/057251.html) Eyal Lotem wrote: > Name: Attribute access for all namespaces ... > global x ; x = 1 > Replaced by: > module.x = 1 Attribute access as an option would be nice, but might be slower. Also note that one common use for a __dict__ is that you don't know what keys are available; meeting this use case with attribute access would require some extra machinery, such as an iterator over attributes. -jJ

2 1

Pythonic concurrency - offtopic
by Sokolov Yura 19 Oct '05

19 Oct '05

Offtopic: Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. G:\Working\1>c:\Python24\python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from os import fork Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: cannot import name fork >>>

3 4

AST branch merge status
by Jeremy Hylton 19 Oct '05

19 Oct '05

I just merged the head back to the AST branch for what I hope is the last time. I plan to merge the branch to the head on Sunday evening. I'd appreciate it if folks could hold off on making changes on the trunk until that merge happens. If this is a non-trivial inconvenience for anyone, go ahead with the changes but send me mail to make sure that I don't lose the changes when I do the merge. Regardless, the compiler and Grammar are off limits. I'll blow away any changes you make there <0.1 wink>. Jeremy

1 2

Defining properties - a use case for class decorators?
by Jim Jewett 19 Oct '05

19 Oct '05

Greg Ewing wrote: >> ... the standard way of defining properties at the moment >> leaves something to be desired, for all the same reasons >> that have led to @-decorators. Guido write: > ... make that feeling more concrete. ... > With decorators there was a concrete issue: the modifier > trailed after the function body, in a real sense "hiding" > from the reader. I don't see such an issue with properties. For me, the property declaration (including the function declarations) is too verbose, and ends up hiding the rest of the class. My ideal syntax would look something like: # Declare "x" to name a property. Create a storage slot, # with the generic get/set/del/doc. (doc == "property x"?) property(x) # Change the setter, possibly in a subclass property(x) set: if x<5: __x = x If I don't want anything special on the get, I shouldn't have to add any "get" boilerplate to my code. An alternative might be slots=[x, y, z] to automatically create default properties for x, y, and z, while declaring that instances won't have arbitrary fields. That said, I'm not sure the benefit is enough to justify the extra complications, and your suggestion of allowing strings for method names may be close enough. I agree that the use of strings is awkward, but ... probably no worse than using them with __dict__ today. -jJ

4 6

Migrating to subversion
by "Martin v. Löwis" 18 Oct '05

18 Oct '05

AFAICT, everything is now setup to actually switch to subversion. The infrastructure is complete, the conversion procedure is complete, and Guido pronounced that the migration could happen. One open issue is where to do the hosting: whether to pay a commercial hosting company (i.e. wush.net), or whether to let it be volunteer-hosted on svn.python.org. Guido was undecided, like several other developers; the majority of the rest apparently was in favour of trying it on svn.python.org. Anthony Baxter specifically told me that he would now be fine with hosting it on svn.python.org as it gives us more control. If it doesn't work out, we can still go to a commercial hoster. So I would like to start a conversion in the near future. One complication apparently is that SF doesn't manage to create nightly CVS tarballs anymore; the one I just got is 5 days old. So we would submit a support request that they manually trigger tarball generation to shorten the freeze period. If people want to test the installation before the switch happens, this would be the time to do it. Regards, Martin

4 6

Guido v. Python, Round 1
by Neal Norwitz 18 Oct '05

18 Oct '05

We all know Guido likes Python. But the real question is do pythons like Guido? http://python.org/neal/ n

8 10

Coroutines, generators, function calling
by Gustavo J. A. M. Carneiro 18 Oct '05

18 Oct '05

There's one thing about coroutines using python generators that is still troubling, and I was wondering if anyone sees any potencial solution at language level... Suppose you have a complex coroutine (this is just an example, not so complex, but you get the idea, I hope): def show_message(msg): win = create_window(msg) # slide down for y in xrange(10): win.move(0, y*20) yield Timeout(0.1) # timeout yield Timeout(3) # slide up for y in xrange(10, 0, -1): win.move(0, y*20) yield Timeout(0.1) win.destroy() Suppose now I want to move the window animation to a function, to factorize the code: def animate(win, steps): for y in steps: win.move(0, y*20) yield Timeout(0.1) def show_message(msg): win = create_window(msg) animate(win, xrange(10)) # slide down yield Timeout(3) animate(win, xrange(10, 0, -1)) # slide up win.destroy() This obviously doesn't work, because calling animate() produces another generator, instead of calling the function. In coroutines context, it's like it produces another coroutine, while all I wanted was to call a function. I don't suppose there could be a way to make the yield inside the subfunction have the same effect as if it was inside the function that called it? Perhaps some special notation, either at function calling or at function definition? -- Gustavo J. A. M. Carneiro <gjc(a)inescporto.pt> <gustavo(a)users.sourceforge.net> The universe is always one step beyond logic.

3 2

Re: [Python-Dev] Definining properties - a use case for class decorators?
by Phillip J. Eby 17 Oct '05

17 Oct '05

At 08:46 PM 10/17/2005 -0700, Guido van Rossum wrote: >Now, if I were to follow Paul Graham's recommendations strictly >(http://www.paulgraham.com/diff.html), point 7 saysthat Python should >have a symbol type. I've always maintained that this is unnecessary >and that we can just as well use regular strings. Well, unless you're going to also do #8 ("a notation for code"), I'd agree. :) But then again, Graham also lists #6 ("programs composed of expressions"), and even though I'm often tempted by the desire to write something as a big expression, the truth is that most people's brains (mine included) just don't have enough stack space for it. The people that have that much mental stack space can already write lambda+listcomp atrocities for the rest of us to boggle at. :) Logix (http://livelogix.net/logix/) basically adds everything on Graham's list to Python, and then compiles it to Python bytecode. But the result is something that still doesn't seem very Pythonic to me. Of course, with good restraint, it seems to me that Logix allows some very tasteful language extensions (John Landahl created a nice syntax sugar for generic functions with it), but making full-tilt use of Graham's 9 features seems to result in a very Lisp-like experience, even without the parentheses. At the same time, I would note that Ruby does seem to have an edge on Python in terms of ability to create "little languages" of the sort that Logix also excels at. Compare SCons (Python) with Rakefiles (Ruby), for example, or SQLObject (Python) to Rails' ActiveRecord. In each case, the Python DSL syntax is okay, but Ruby's is better. Even PEP 340 in its heydey wasn't going to improve on it much, because Ruby DSL's benefit mainly from being able to pass the blocks to functions which could then hold on to them for later use. (Also, in an ironic twist, Ruby requires fewer parentheses than Python for such operations, so the invocation looks more like user-defined syntax.)

1 0