Mailman 3 October 2005 - Python-Dev

Defining properties - a use case for class decorators?
by Jim Jewett Oct. 19, 2005

Oct. 19, 2005

(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 … [View More]

2 1

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

Oct. 19, 2005

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: &… [View More]gt; > > > > 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. [View Less]

2 1

Early PEP draft (For Python 3000?)
by Jim Jewett Oct. 19, 2005

Oct. 19, 2005

(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 Oct. 19, 2005

Oct. 19, 2005

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 Oct. 19, 2005

Oct. 19, 2005

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 Oct. 19, 2005

Oct. 19, 2005

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 … [View More]

4 6

Migrating to subversion
by "Martin v. Löwis" Oct. 19, 2005

Oct. 19, 2005

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 … [View More]

4 6

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

Oct. 18, 2005

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 Oct. 18, 2005

Oct. 18, 2005

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): … [View More]

3 2

Re: [Python-Dev] Definining properties - a use case for class decorators?
by Phillip J. Eby Oct. 18, 2005

Oct. 18, 2005

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 … [View More]

1 0