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
Gustavo J. A. M. Carneiro wrote:
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?
You mean like a for
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
On Tue, 2005-10-18 at 09:07 -0400, Jim Jewett wrote:
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)
Jim Jewett wrote:
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.
An
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 subject of yield
On Mon, 2005-10-17 at 23:46, Guido van Rossum wrote:
But I still like the version with strings better:
x = property('get_x', 'set_x')
This trades two lambdas for two pairs of string quotes; a good deal IMO!
You could of course just do the wrapping in property(). I put that in
quotes
Le mardi 18 octobre 2005 à 10:57 -0400, Barry Warsaw a écrit :
On Mon, 2005-10-17 at 23:46, Guido van Rossum wrote:
But I still like the version with strings better:
x = property('get_x', 'set_x')
This trades two lambdas for two pairs of string quotes; a good deal IMO!
You
At 12:01 PM 10/18/2005 +0100, Gustavo J. A. M. Carneiro wrote:
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
At 11:59 PM 10/18/2005 +1000, Nick Coghlan wrote:
An idea that was kicked around on c.l.p a long while back was statement
local
variables, where you could define some extra names just for a single simple
statement:
x = property(get, set, delete, doc) given:
doc = Property x (must be
On 10/18/05, Antoine Pitrou [EMAIL PROTECTED] wrote:
Le mardi 18 octobre 2005 à 10:57 -0400, Barry Warsaw a écrit :
Currently I never use properties, because it makes classes much less
readable for the same kind of reasons as what Jim wrote.
Me too, I never use properties directly. However I
On Tue, Oct 18, 2005, Barry Warsaw wrote:
You could of course just do the wrapping in property(). I put that in
quotes because you'd have the problem of knowing when to wrap and when
not to, but there would be ways to solve that. But I won't belabor the
point any longer, except to ask what
Aahz [EMAIL PROTECTED] wrote:
On Mon, Oct 17, 2005, Guido van Rossum wrote:
If an argument is a string, it should be a method name, and the method
is looked up by that name each time the property is used. Because this
is late binding, it can be put before the method definitions, and a
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 property x!
def __get__(self):
return
Nick Coghlan [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
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
Le mardi 18 octobre 2005 à 19:17 +0200, Antoine Pitrou a écrit :
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:
Le mardi 18 octobre 2005 à 12:56 -0700, Josiah Carlson a écrit :
You are saving 3 lines over the decorator/function approach [...]
Well, obviously, the point of a block statement or construct is that it
can be applied to many other things than properties. Otherwise it is
overkill as you imply.
Martin If people want to test the installation before the switch
Martin happens, this would be the time to do it.
Martin,
Can you let us know again the magic incantation to check out the source from
the repository?
Thx,
Skip
___
Python-Dev
Antoine Pitrou wrote:
I suppose something like:
class C(object):
x = prop:
Yay for property x!
def __get__(self):
return self._x
def __set__(self, value):
self._x = x
I've just looked at Steven Bethard's recipe, and it seems
to give
[EMAIL PROTECTED] wrote:
Neal This URL should work for a while longer.
Neal http://creosote.python.org/neal/
Ah, the vagaries of URL redirection. Thanks...
The front of his shirt says ++ungood; Is that the whole joke or is the
punchline on the back?
-Michel
On 10/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Martin If people want to test the installation before the switch
Martin happens, this would be the time to do it.
Martin,
Can you let us know again the magic incantation to check out the source from
the repository?
And any
Michel Pelletier wrote:
[EMAIL PROTECTED] wrote:
Neal This URL should work for a while longer.
Neal http://creosote.python.org/neal/
Ah, the vagaries of URL redirection. Thanks...
The front of his shirt says ++ungood; Is that the whole joke or is the
punchline on the back?
Phillip J. Eby wrote:
What will the procedure be for getting a login? I assume our SF logins
won't simply be transferred/transferrable.
You should send your SSH2 public key along with your preferred logname
(firstname.lastname) to [EMAIL PROTECTED]
Regards,
Martin
Brett Cannon wrote:
And any other problems people come across or questions they have about
Subversion and its use, please do ask. I will try to start a new
section in the dev FAQ for svn-specific issues.
Please integrate
http://www.python.org/dev/svn.html
(linked from 1.3 of devfaq.html) if
24 matches
Mail list logo
