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
(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
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
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
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
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
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
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
