On 10/23/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Very nice indeed. I'd be more supportive if it was defined as a new statement
such as create with the syntax:
create TYPE NAME(ARGS):
BLOCK
I like it, but it would require a new keyword. Alternatively, one
could abuse 'def':
def
Michele Simionato [EMAIL PROTECTED] wrote:
On 10/23/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Very nice indeed. I'd be more supportive if it was defined as a new
statement
such as create with the syntax:
create TYPE NAME(ARGS):
BLOCK
I like it, but it would require a
On 10/24/05, Josiah Carlson [EMAIL PROTECTED] wrote:
I would criticise it for being dangerously close to worthless. With the
minor support code that I (and others) have offered, no new syntax is
necessary.
You can get the same semantics with...
class NAME(_(TYPE), ARGS):
BLOCK
And a
Josiah Carlson wrote:
You can get the same semantics with...
class NAME(_(TYPE), ARGS):
BLOCK
And a suitably defined _. Remember, not every X line function should be
made a builtin or syntax.
And this would be an extremely fragile hack that is entirely dependent on the
murky rules
Nick Coghlan [EMAIL PROTECTED] writes:
Josiah Carlson wrote:
You can get the same semantics with...
class NAME(_(TYPE), ARGS):
BLOCK
And a suitably defined _. Remember, not every X line function should be
made a builtin or syntax.
And this would be an extremely fragile hack that
Michele Simionato [EMAIL PROTECTED] wrote:
On 10/24/05, Josiah Carlson [EMAIL PROTECTED] wrote:
I would criticise it for being dangerously close to worthless. With the
minor support code that I (and others) have offered, no new syntax is
necessary.
You can get the same semantics
On 24-okt-2005, at 12:54, Josiah Carlson wrote:
Metaclass abuse? Oh, I'm sorry, I thought that the point of
metaclasses
were to offer a way to make magic happen in a somewhat pragmatic
manner, you know, through metaprogramming. I would call this
particular
use a practical
On 10/24/05, Ronald Oussoren [EMAIL PROTECTED] wrote:
I'd say using a class statement to define a property is metaclass
abuse, as would
anything that wouldn't define something class-like. The same is true
for other
constructs, using an decorator to define something that is not a
callable
Reinhold Birkenfeld wrote:
Michele Simionato wrote:
As other explained, the syntax would not work for functions (and it is
not intended to).
A possible use case I had in mind is to define inlined modules to be
used as bunches
of attributes. For instance, I could define a module as
module
Michele Simionato wrote:
As other explained, the syntax would not work for functions (and it is
not intended to).
A possible use case I had in mind is to define inlined modules to be
used as bunches
of attributes. For instance, I could define a module as
module m():
a = 1
b = 2
On 10/18/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I wonder if at some point in the future Python will have to develop a
macro syntax so that you can write
Property foo:
def get(self): return self._foo
...etc...
This reminds me of an idea I have kept in my drawer for
On 10/19/05, Michele Simionato [EMAIL PROTECTED] wrote:
On 10/18/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I wonder if at some point in the future Python will have to develop a
macro syntax so that you can write
Property foo:
def get(self): return self._foo
On 10/19/05, Paul Moore [EMAIL PROTECTED] wrote:
One question - in the expansion, name is used on both sides of the
assignment. Consider
something name():
definitions
This expands to
name = something(name, (), dict)
What should happen if name wasn't defined before? A
Hi Michele,
Property p():
I am a property
def fget(self):
pass
def fset(self):
pass
def fdel(self):
pass
In effect this is quite similar to the proposal I've done (except that
you've reversed the traditional assignment order from p = Property()
to
Michele Simionato wrote:
This reminds me of an idea I have kept in my drawer for a couple of years or
so.
Here is my proposition: we could have the statement syntax
callable name tuple:
definitions
to be syntactic sugar for
name = callable(name, tuple, dict-of-definitions)
[snip]
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
callable name tuple:
definitions
...
Steve Wow, that's really neat. And you save a keyword! ;-)
Two if you add a builtin called function (get rid of def).
Not unless the tuple is passed in as an abstract syntax
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
callable name tuple:
definitions
...
Steve Wow, that's really neat. And you save a keyword! ;-)
Two if you add a builtin called
[EMAIL PROTECTED] wrote:
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
callable name tuple:
definitions
...
Steve Wow, that's really neat. And you save a keyword! ;-)
At 12:46 PM 10/19/2005 -0700, Josiah Carlson wrote:
[EMAIL PROTECTED] wrote:
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip Not unless the tuple is passed in as an abstract syntax
tree or
Phillip something.
Hmmm... Maybe I misread something then. I saw (I
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
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
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
On and off, I've been looking for an elegant way to handle properties using
decorators.
Why use decorators when a metaclass will already do the trick, and
save you a line? This doesn't necessarily get around Antoine's
complaint that it looks
Michael Urman wrote:
class Test(object):
class foo(Property):
The foo property
def get(self): return self._foo
def set(self, val): self._foo = val
def delete(self): del self._foo
test = Test()
test.foo = 'Yay!'
assert test._foo == 'Yay!'
Thus proving
Guido van Rossum wrote:
With decorators there was a concrete issue: the modifier trailed after
the function body, in a real sense hiding from the reader.
A similar thing happens with properties, the property
definition (which is the public interface) trailing
after the accessor methods (which
[Guido]
I looked at that, and now I believe it's actually *better* to mention
the property name twice, at least compared to Tim' s approach.
[Greg Ewing]
I'm inclined to agree. Passing functions that you're not
going to use as functions but just use the name of doesn't
seem right.
And in
Guido van Rossum wrote:
Let's change the property built-in so that its arguments can be either
functions or strings (or None).
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.
That sounds reasonable.
--
Greg
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.
If an argument is a string, it should be a method name, and the
[Guido]
Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.
If an argument is a string, it should be a method name, and the method
is looked up by that name each
On Mon, 2005-10-17 at 22:24, Guido van Rossum wrote:
IMO, there's not enough advantage in having the property() call before
the functions than after.
Maybe you didn't see the use case that Greg had in mind? He wants to
be able to override the getter and/or setter in a subclass, without
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.
At 08:46 PM 10/17/2005 -0700, Guido van Rossum wrote:
Now, if I were to follow Paul Graham's recommendations strictly
(http://www.paulgraham.com/diff.html), point 7 saysthat Python should
have a symbol type. I've always maintained that this is unnecessary
and that we can just as well use regular
Barry Warsaw wrote:
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.
If an argument is a string, it should be
On 10/17/05, Steven Bethard [EMAIL PROTECTED] wrote:
I'm not sure if you'll like it any better, but I combined Michael
Urman's suggestion with my late-binding property recipe to get:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418
It solves the name-repetition problem and
class Demo(object):
@def_property
class test:
This is a test property
def get(self):
print Getting attribute on instance
def set(self, value):
print Setting attribute on instance
def delete(self):
On Oct 16, 2005, at 9:56 AM, Nick Coghlan wrote:
On and off, I've been looking for an elegant way to handle
properties using
decorators.
This isn't my idea, and it might have been brought up here in the
past to the same sorts of screams of horror to which you refer later,
but I use the
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
On and off, I've been looking for an elegant way to handle properties using
decorators.
It hasn't really worked, because decorators are inherently single function,
and properties span multiple functions.
However, it occurred to me that
On 10/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
On and off, I've been looking for an elegant way to handle properties using
decorators.
It hasn't really worked, because decorators are inherently single function,
and properties
On 10/16/05, Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick, and everybody else trying to find a solution for this
problem, please don't. There's nothing wrong with having the three
accessor methods explicitly in the namespace, it's
Guido van Rossum wrote:
Nick, and everybody else trying to find a solution for this
problem, please don't.
Denying that there's a problem isn't going to make it
go away. Many people, including me, have the feeling that
the standard way of defining properties at the moment leaves
something to
Greg Ewing wrote:
class C:
foo = overridable_property('foo', The foo property)
def get_foo(self):
...
def set_foo(self, x):
...
This has the advantage that the accessor methods can be
overridden in subclasses with the expected effect.
This is a
[Guido]
Nick, and everybody else trying to find a solution for this
problem, please don't.
[Greg Ewing]
Denying that there's a problem isn't going to make it
go away. Many people, including me, have the feeling that
the standard way of defining properties at the moment leaves
something to
44 matches
Mail list logo
