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
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 l
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
> trail
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" state
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 a
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
q
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
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 ca
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
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
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
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 definiti
> 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):
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 ... probab
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 =
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>
> > 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.
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 w
At 12:19 AM 10/19/2005 +0200, Martin v. Löwis wrote:
>If people want to test the installation before the switch happens,
>this would be the time to do it.
What will the procedure be for getting a login? I assume our SF logins
won't simply be transferred/transferrable.
__
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
[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?
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
> punchlin
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
__
[EMAIL PROTECTED] wrote:
> Can you let us know again the magic incantation to check out the source from
> the repository?
See
http://www.python.org/dev/svn.html
It's (say)
svn co svn+ssh://[EMAIL PROTECTED]/python/trunk/Misc
for read-write access, and
svn co http://svn.python.org/projects/pyt
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)
29 matches
Mail list logo
