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)
[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
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
__
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
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?
[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
_
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
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
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.
__
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
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.
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 à 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 =
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
> 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):
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
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
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
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
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
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
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
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
> 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
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
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)
>
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
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
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
29 matches
Mail list logo
