Re: [Python-Dev] properties and block statement

2005-10-19 Thread Stefan Rank
on 18.10.2005 19:17 Antoine Pitrou said the following: What would this mythical block statement look like that would make properties easier to write than the above late-binding or the subclass Property recipe? I suppose something like: class C(object): x = prop: Yay for

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Michele Simionato
On 10/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: I wonder if at some point in the future Python will have to develop a macro syntax so that you can write Property foo: def get(self): return self._foo ...etc... This reminds me of an idea I have kept in my drawer for

Re: [Python-Dev] properties and block statement

2005-10-19 Thread Duncan Booth
Stefan Rank [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: I think there is no need for a special @syntax for this to work. I suppose it would be possible to allow a trailing block after any function invocation, with the effect of creating a new namespace that gets treated as

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Paul Moore
On 10/19/05, Michele Simionato [EMAIL PROTECTED] wrote: On 10/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: I wonder if at some point in the future Python will have to develop a macro syntax so that you can write Property foo: def get(self): return self._foo

Re: [Python-Dev] Defining properties - a use case for class decorators?

2005-10-19 Thread Nick Coghlan
Phillip J. Eby wrote: Note that a where or given statement like this could make it a little easier to drop lambda. I think the lambda will disappear in Py3k concept might have been what triggered the original 'where' statement discussion. The idea was to be able to lift an arbitrary

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Michele Simionato
On 10/19/05, Paul Moore [EMAIL PROTECTED] wrote: One question - in the expansion, name is used on both sides of the assignment. Consider something name(): definitions This expands to name = something(name, (), dict) What should happen if name wasn't defined before? A

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Antoine Pitrou
Hi Michele, Property p(): I am a property def fget(self): pass def fset(self): pass def fdel(self): pass In effect this is quite similar to the proposal I've done (except that you've reversed the traditional assignment order from p = Property() to

Re: [Python-Dev] Pythonic concurrency - offtopic

2005-10-19 Thread JanC
On 10/14/05, Josiah Carlson [EMAIL PROTECTED] wrote: Until Microsoft adds kernel support for fork, don't expect standard Windows Python to support it. AFAIK the NT kernel has support for fork, but the Win32 subsystem doesn't support it (you can only use it with the POSIX subsystem). -- JanC

[Python-Dev] Early PEP draft (For Python 3000?)

2005-10-19 Thread Jim Jewett
(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

[Python-Dev] Defining properties - a use case for class decorators?

2005-10-19 Thread Jim Jewett
(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

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Steven Bethard
Michele Simionato wrote: This reminds me of an idea I have kept in my drawer for a couple of years or so. Here is my proposition: we could have the statement syntax callable name tuple: definitions to be syntactic sugar for name = callable(name, tuple, dict-of-definitions) [snip]

Re: [Python-Dev] Defining properties - a use case for class decorators?

2005-10-19 Thread Phillip J. Eby
At 07:47 PM 10/19/2005 +1000, Nick Coghlan wrote: Phillip J. Eby wrote: Note that a where or given statement like this could make it a little easier to drop lambda. I think the lambda will disappear in Py3k concept might have been what triggered the original 'where' statement discussion. The

Re: [Python-Dev] AST branch merge status

2005-10-19 Thread Jeremy Hylton
I'm still making slow progress on this front. I have a versioned merged to the CVS head. I'd like to make a final pass over the patch. I'd upload it to SF, but I can't connect to a web server there. If anyone would like to eyeball that patch before I commit it, I can email it to you. Jeremy

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Phillip J. Eby
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: callable name tuple: definitions ... Steve Wow, that's really neat. And you save a keyword! ;-) Two if you add a builtin called function (get rid of def). Not unless the tuple is passed in as an abstract syntax

Re: [Python-Dev] Pythonic concurrency - offtopic

2005-10-19 Thread Josiah Carlson
JanC [EMAIL PROTECTED] wrote: On 10/14/05, Josiah Carlson [EMAIL PROTECTED] wrote: Until Microsoft adds kernel support for fork, don't expect standard Windows Python to support it. AFAIK the NT kernel has support for fork, but the Win32 subsystem doesn't support it (you can only use it

Re: [Python-Dev] Early PEP draft (For Python 3000?)

2005-10-19 Thread Josiah Carlson
Jim Jewett [EMAIL PROTECTED] wrote: (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

Re: [Python-Dev] Early PEP draft (For Python 3000?)

2005-10-19 Thread Josiah Carlson
Calvin Spealman [EMAIL PROTECTED] wrote: On 10/16/05, Josiah Carlson [EMAIL PROTECTED] wrote: [snip] 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

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread skip
Phillip == Phillip J Eby [EMAIL PROTECTED] writes: Phillip At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: callable name tuple: definitions ... Steve Wow, that's really neat. And you save a keyword! ;-) Two if you add a builtin called

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Josiah Carlson
[EMAIL PROTECTED] wrote: Phillip == Phillip J Eby [EMAIL PROTECTED] writes: Phillip At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: callable name tuple: definitions ... Steve Wow, that's really neat. And you save a keyword! ;-)

Re: [Python-Dev] Defining properties - a use case for class decorators?

2005-10-19 Thread Josiah Carlson
Jim Jewett [EMAIL PROTECTED] wrote: (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

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-19 Thread Phillip J. Eby
At 12:46 PM 10/19/2005 -0700, Josiah Carlson wrote: [EMAIL PROTECTED] wrote: Phillip == Phillip J Eby [EMAIL PROTECTED] writes: Phillip Not unless the tuple is passed in as an abstract syntax tree or Phillip something. Hmmm... Maybe I misread something then. I saw (I

Re: [Python-Dev] Definining properties - a use case for classdecorators?

2005-10-19 Thread Guido van Rossum
On 10/19/05, Fredrik Lundh [EMAIL PROTECTED] wrote: letting class inject a slightly magic self variable into the class namespace ? class C: foo = property(self.getFoo, self.setFoo, None, 'the foo property') def getFoo(self): return self._foo def

Re: [Python-Dev] Coroutines, generators, function calling

2005-10-19 Thread Michel Pelletier
Andrew Koenig wrote: Sure, that would work. Or even this, if the scheduler would automatically recognize generator objects being yielded and so would run the the nested coroutine until finish: This idea has been discussed before. I think the problem with recognizing generators as the

Re: [Python-Dev] enumerate with a start index

2005-10-19 Thread Michel Pelletier
Martin Blais wrote: Hi Just wondering, would anyone think of it as a good idea if the enumerate() builtin could accept a start argument? I've run across a few cases where this would have been useful. It seems generic enough too. +1, but something more useful might be a a cross between

Re: [Python-Dev] Pre-PEP: Task-local variables

2005-10-19 Thread Josiah Carlson
Phillip J. Eby [EMAIL PROTECTED] wrote: For efficiency's sake, however, CPython could simply store the execution context dictionary in its thread state structure, creating an empty dictionary at thread initialization time. This would make it somewhat easier to offer a C API for access to

Re: [Python-Dev] Pre-PEP: Task-local variables

2005-10-19 Thread Phillip J. Eby
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote: What about a situation in which corutines are handled by multiple threads? Any time a corutine passed from one thread to another, it would lose its state. It's the responsibility of a coroutine scheduler to take a snapshot() when a task is

Re: [Python-Dev] Pre-PEP: Task-local variables

2005-10-19 Thread Josiah Carlson
Phillip J. Eby [EMAIL PROTECTED] wrote: It's the responsibility of a coroutine scheduler to take a snapshot() when a task is suspended, and to swap() it in when resumed. So it doesn't matter that you've changed what thread you're running in, as long as you keep the context with the