[Python-Dev] Coroutines, generators, function calling
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): win.move(0, y*20) yield Timeout(0.1) win.destroy() 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) 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 animate() produces another generator, instead of calling the function. In coroutines context, it's like it produces another coroutine, while all I wanted was to call a function. 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? -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
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 loop? ;) def show_message(msg): win = create_window(msg) for step in animate(win, xrange(10)): # slide down yield step yield Timeout(3) for step in animate(win, xrange(10, 0, -1)): # slide up yield step win.destroy() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Defining properties - a use case for class decorators?
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 function declarations) is too verbose, and ends up hiding the rest of the class. My ideal syntax would look something like: # Declare "x" to name a property. Create a storage slot, # with the generic get/set/del/doc. (doc == "property x"?) property(x) # Change the setter, possibly in a subclass property(x) set: if x<5: __x = x If I don't want anything special on the get, I shouldn't have to add any "get" boilerplate to my code. An alternative might be slots=[x, y, z] to automatically create default properties for x, y, and z, while declaring that instances won't have arbitrary fields. 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. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
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) > 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 animate() produces > another generator, instead of calling the function. In coroutines > context, it's like it produces another coroutine, while all I wanted was > to call a function. > > 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? > > - > > I may be missing something, but to me the answer looks like: > > def show_message(msg): > win = create_window(msg) > for v in animate(win, xrange(10)): # slide down > yield v > yield Timeout(3) > for v in animate(win, xrange(10, 0, -1)): # slide up > yield v > win.destroy() 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: def show_message(msg): win = create_window(msg) yield animate(win, xrange(10)) # slide down yield Timeout(3) yield animate(win, xrange(10, 0, -1)) # slide up win.destroy() Sure, it could work, but still... I wish for something that would avoid creating a nested coroutine. Maybe I'm asking for too much, I don't know. Just trying to get some feedback... Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
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 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 less than 5)"
def get(self):
try:
return self._x
except AttributeError:
self._x = 0
return 0
def set(self, value):
if value >= 5: raise ValueError("value too big")
self._x = x
def delete(self):
del self._x
As I recall, the idea died due to problems with figuring out how to allow the
simple statement to both see the names from the nested block and modify the
surrounding namespace, but prevent the names from the nested block from
affecting the surrounding namespace after the statement was completed.
Another option would be to allow attribute reference targets when binding
function names:
x = property("Property x (must be less than 5)")
def x.get(instance):
try:
return instance._x
except AttributeError:
instance._x = 0
return 0
def x.set(instance, value):
if value >= 5: raise ValueError("value too big")
instance._x = x
def x.delete(instance):
del instance._x
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
> 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" statements is that then you can't yield a generator even if you want to. The best syntax I can think of without adding a new keyword looks like this: yield from x which would be equivalent to for i in x: yield i Note that this equivalence would imply that x can be any iterable, not just a generator. For example: yield from ['Hello', 'world'] would be equivalent to yield 'Hello' yield 'world' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
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 subject of "yield" statements is that then you can't yield > a generator even if you want to. > > The best syntax I can think of without adding a new keyword looks like this: > > yield from x > > which would be equivalent to > > for i in x: > yield i > > Note that this equivalence would imply that x can be any iterable, not just > a generator. For example: > > yield from ['Hello', 'world'] > > would be equivalent to > > yield 'Hello' > yield 'world' Hmm, I actually quite like that. The best I came up with was "yield for", and that just didn't read correctly. Whereas "yield from seq" says exactly what it is doing. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
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 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 happens when you typo one of those
strings? What kind of exception do you get and when do you get it?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
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 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 happens when you typo one of those
> strings? What kind of exception do you get and when do you get it?
AttributeError when actually accessing the property, no?
Guido's proposal seems quite nice to me. It helps group all property
declarations at the beginning, and having accessor methods at the end
with other non-public methods.
Currently I never use properties, because it makes classes much less
readable for the same kind of reasons as what Jim wrote:
Le mardi 18 octobre 2005 à 09:37 -0400, Jim Jewett a écrit :
> For me, the property declaration (including the function
> declarations) is too verbose, and ends up hiding the rest
> of the class.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
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 animate() produces >another generator, instead of calling the function. In coroutines >context, it's like it produces another coroutine, while all I wanted was >to call a function. Just 'yield animate(win, xrange(10))' and have the trampoline recognize generators. See the PEP 342 trampoline example, which does this. When the animate() is exhausted, it'll resume the "calling" function. > 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? Yes, it's 'yield' at the function calling. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
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 less than 5)" >def get(self): >try: >return self._x >except AttributeError: >self._x = 0 >return 0 >... > >As I recall, the idea died due to problems with figuring out how to allow the >simple statement to both see the names from the nested block and modify the >surrounding namespace, but prevent the names from the nested block from >affecting the surrounding namespace after the statement was completed. Haskell's "where" statement does this, but the block *doesn't* modify the surrounding namespace; it's strictly local. With those semantics, the Python translation of the above could just be something like: def _tmp(): doc = "blah" def get(self): # etc. # ... return property(get,set,delete,doc) x = _tmp() Which works great except for the part that co_lnotab won't let you identify that "return" line as being the original expression line, due to the monotonically-increasing bit. ;) Note that a "where" or "given" statement like this could make it a little easier to drop lambda. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
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 have experimented
with using helper functions to generate the properties:
_dic = {}
def makeproperty(x):
def getx(self):
return _dic[self, x]
def setx(self, value):
_dic[self, x] = value
return property(getx, setx)
class C(object):
x = makeproperty('x')
c = C()
c.x = 1
print c.x
But in general I prefer to write a custom descriptor class, since it
gives me much more control.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
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 happens when you typo one of those > strings? What kind of exception do you get and when do you get it? AttributeError, just like this: class C: pass C().foo() Last night I was thinking that maybe TypeError would be better, but AttributeError is going to be what the internal machinery raises, and I decided there was no point trying to translate it. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
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
> > subclass can override the methods. Example:
> >
> > class C:
> > foo = property('getFoo', 'setFoo', None, 'the foo property')
>
> +1
>
> The only other alternative is to introduce some kind of block. This is
> a good solution that is not particularly intrusive; it leaves the door
> open to a well-designed block structure later on. The one niggle I have
> is that it's going to be a little unwieldy to explain, but people who
> create properties really ought to understand Python well enough to deal
> with it.
I remember posing an unanswered question back when blocks were being
offered, and being that you brought up blocks again, I'll ask a more
specific variant of my original question:
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?
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
> 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 self._x
def __set__(self, value):
self._x = x
and then:
def prop(@block):
return property(
fget=block.get("__get__"),
fset=block.get("__set__"),
fdel=block.get("__delete__"),
doc=block.get("__doc__", ""),
)
(where "@bargs" would be the syntax to refer to block args as a dict,
the same way "**kargs" already exist)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
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 than
> > using them with __dict__ today.
>
> 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 less than 5)"
>def get(self):
>try:
>return self._x
>except AttributeError:
>self._x = 0
>return 0
>def set(self, value):
>if value >= 5: raise ValueError("value too big")
>self._x = x
>def delete(self):
>del self._x
>
> As I recall, the idea died due to problems with figuring out how to allow the
> simple statement to both see the names from the nested block and modify the
> surrounding namespace, but prevent the names from the nested block from
> affecting the surrounding namespace after the statement was completed.
You wouldn't be able to write to the surrounding namespace, but a
closure would work fine for this.
def Property(fcn):
ns = fcn()
return property(ns.get('get'), ns.get('set'), ns.get('delete'),
ns.get('doc'))
class foo(object):
@Property
def x():
doc = "Property x (must be less than 5)"
def get(self):
try:
return self._x
except AttributeError:
self._x = 0
return 0
def set(self, value):
if value >= 5: raise ValueError("value too big")
self._x = value
def delete(self):
del self._x
return locals()
In an actual 'given:' statement, one could create a local function
namespace with the proper func_closure attribute (which is automatically
executed), then execute the lookup of the arguments to the statement in
the 'given:' line from this closure, but assign to surrounding scope.
Then again, maybe the above function and decorator approach are better.
An unfortunate side-effect of with statement early-binding of 'as VAR'
is that unless one works quite hard at mucking about with frames, the
following has a wholly ugly implementation (whether or not one cares
about the persistance of the variables defined within the block, you
still need to modify x when you are done, which may as well cause a
cleanup of the objects defined within the block...if such things are
possible)...
with Property as x:
...
> Another option would be to allow attribute reference targets when binding
> function names:
*shivers at the proposal* That's scary. It took me a few minutes just
to figure out what the heck that was supposed to do.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
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:
> """ Yay for property x! """
> def __get__(self):
> return self._x
> def __set__(self, value):
> self._x = x
An example of applicating this scheme to Twisted:
domain_name = "www.google.com"
reactor.resolve(domain_name):
def callback(value):
print "%s resolves to %s" % (domain_name, value)
def errback(error):
print "failed to resolve %s!"
And then in the Reactor class:
def resolve(self, name, @block):
...
d = defer.Deferred()
cb = block.pop('callback')
if cb is not None:
d.addCallback(cb)
eb = block.pop('errback')
if eb is not None:
d.addCallback(eb)
if block:
raise ValueError("spurious blockargs: %s" %
str(block))
return d
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
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:
> """ Yay for property x! """
> def __get__(self):
> return self._x
> def __set__(self, value):
> self._x = x
>
> and then:
>
> def prop(@block):
> return property(
> fget=block.get("__get__"),
> fset=block.get("__set__"),
> fdel=block.get("__delete__"),
> doc=block.get("__doc__", ""),
> )
>
> (where "@bargs" would be the syntax to refer to block args as a dict,
> the same way "**kargs" already exist)
You are saving 3 lines over the decorator/function approach at the cost
of possible confusion over blocks and an easily forgotten/not read @
just after an open paren.
Thanks, but I'll stick to the Property decorator, Property subclass,
property late bindings, or even a Property metaclass*, and not need to
modify Python syntax.
- Josiah
* Property metaclass in an embedded class definition:
class Property(type):
def __init__(*args):
pass
def __new__(cls, name, bases, dct):
return property(dct.get('get'),
dct.get('set'),
dct.get('delete'),
dct.get('__doc__', ''))
class foo(object):
class x(object):
__metaclass__ = Property
'hello'
def get(self):
try:
return self._x
except AttributeError:
self._x = 0
return 0
def set(self, value):
if value >= 5: raise ValueError("value too big")
self._x = value
def delete(self):
del self._x
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
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. (I'm not actively advocating this by the way, I was just answering a request for an example) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Migrating to subversion
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 Baxter specifically told me that he would now be fine with hosting it on svn.python.org as it gives us more control. If it doesn't work out, we can still go to a commercial hoster. So I would like to start a conversion in the near future. One complication apparently is that SF doesn't manage to create nightly CVS tarballs anymore; the one I just got is 5 days old. So we would submit a support request that they manually trigger tarball generation to shorten the freeze period. If people want to test the installation before the switch happens, this would be the time to do it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Property syntax for Py3k (properties and block statement)
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 you something very like this. Two problems with it are the abuse of 'class' to define something that's not really used as a class, and the need to explicitly inherit from the base class's property descriptor. In Py3k, I'd like to see 'property' renamed to 'Property', and 'property' become a keyword used something like class C: property x: """This is the x property.""" def __get__(self): ... def __set__(self, value): ... def __del__(self): ... The accessors should be overridable in subclasses, so you can do class D(C): property x: def __get__(self): """This overrides the __get__ property for x in C""" ... Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Guido v. Python, Round 1
[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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
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 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. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Guido v. Python, Round 1
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? http://www.ee.surrey.ac.uk/Personal/L.Wood/double-plus-ungood/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
[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/python/trunk/Misc for read-only access; viewcvs is at http://svn.python.org/view Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
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 possible. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
