Re: [Python-Dev] Definining properties - a use case for class decorators?
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 TYPE NAME(ARGS): BLOCK but then people would likely be confused as Skip was, earlier in this thread, so I guess 'def' is a not an option. IMHO a new keyword could be justified for such a powerful feature, but only Guido's opinion counts on this matters ;) Anyway I expected people to criticize the proposal as too powerful and dangerously close to Lisp macros. 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?
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 new keyword. Alternatively, one could abuse 'def': def TYPE NAME(ARGS): BLOCK but then people would likely be confused as Skip was, earlier in this thread, so I guess 'def' is a not an option. IMHO a new keyword could be justified for such a powerful feature, but only Guido's opinion counts on this matters ;) Anyway I expected people to criticize the proposal as too powerful and dangerously close to Lisp macros. 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 suitably defined _. Remember, not every X line function should be made a builtin or syntax. - 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] Definining properties - a use case for class decorators?
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 suitably defined _. Remember, not every X line function should be made a builtin or syntax. - Josiah Could you re-read my original message, please? Sugar is *everything* in this case. If the functionality is to be implemented via a __metaclass__ hook, then it should be considered a hack that nobody in his right mind should use. OTOH, if there is a specific syntax for it, then it means this the usage has the benediction of the BDFL. This would be a HUGE change. For instance, I would never abuse metaclasses for that, whereas I would freely use a 'create' statement. 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?
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 regarding how Python chooses the metaclass for the newly created class. Ensuring that the metaclass of the class returned by _ was always the one chosen would be tricky at best and impossible at worst. Even if it *could* be done, I'd never want to see a hack like that in production code I had anything to do with. And while writing it with __metaclass__ has precisely the correct semantics, that simply isn't as readable as a new block statement would be, nor is it as readable as the current major alternatives (e.g., defining and invoking a factory function). An alternative to a completely new function would be to simply allow the metaclass to be defined up front, rather than inside the body of the class statement: class @TYPE NAME(ARGS): BLOCK For example: class @Property x(): def get(self): return self._x def set(self, value): self._x = value def delete(self, value): del self._x (I put the metaclass after the keyword, because, unlike a function decorator, the metaclass is invoked *before* the class is created, and because you're only allowed one explicit metaclass) 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?
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 is entirely dependent on the murky rules regarding how Python chooses the metaclass for the newly created class. Uh, not really. In the presence of base classes it's always the type of the first base. The reason it might not seem this simple is that most metaclasses end up calling type.__new__ at some point and this function does more complicated things (such as checking for metaclass conflict and deferring to the most specific metaclass). Not sure what the context is here, but I have to butt in when I see people complicating things which aren't actually that complicated... Cheers, mwh -- There's an aura of unholy black magic about CLISP. It works, but I have no idea how it does it. I suspect there's a goat involved somewhere. -- Johann Hibschman, comp.lang.scheme ___ 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?
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 with...
class NAME(_(TYPE), ARGS):
BLOCK
And a suitably defined _. Remember, not every X line function should be
made a builtin or syntax.
- Josiah
Could you re-read my original message, please? Sugar is *everything*
in this case. If the functionality is to be implemented via a __metaclass__
hook, then it should be considered a hack that nobody in his right mind
should use. OTOH, if there is a specific syntax for it, then it means
this the usage
has the benediction of the BDFL. This would be a HUGE change.
For instance, I would never abuse metaclasses for that, whereas I
would freely use a 'create' statement.
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 application of standard Python semantics.
Pardon me while I attempt to re-parse your above statement...
If there is a specific syntax for [passing a temporary namespace to a
callable, created by some sort of block mechanism], then [using it for
property creation] has the benediction of the BDFL.
What I'm trying to say is that it already has a no-syntax syntax. It
uses the magic of metaclasses, but one can make that magic as
explicit as necessary.
class NAME(PassNamespaceFromClassBlock(fcn=TYPE, args=ARGS)):
BLOCK
Personally, I've not seen the desire to pass temporary namespaces to
functions until recently, so whether or not people will use it for
property creation, or any other way that people would find interesting
and/or useful, is at least a bit of prediction. Maybe people will
prefer to use property('get_foo', 'set_foo', 'del_foo'), who knows? But
you know what? Regardless of what people want, they can use metaclasses
right now to create properties, where they would have to wait until
Python 2.5 comes out before they could use this proposed 'create'
statement.
- 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] Definining properties - a use case for class decorators?
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 application of standard Python semantics.
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 would IMHO
also be abuse.
That said, I really have an opinion on the 'create' statement
proposal yet. It
does seem to have a very limited field of use. I'm quite happy with
using property
as it is, property('get_foo', 'set_foo') would take away most if not
all of
the remaining problems.
Ronald
___
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/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 would IMHO also be abuse. +1 That said, I really have an opinion on the 'create' statement proposal yet. It does seem to have a very limited field of use. This is definitely non-true. The 'create' statement would have lots of applications. On top of my mind I can think of 'create' applied to: - bunches; - modules; - interfaces; - properties; - usage in framewors, for instance providing sugar for Object-Relational mappers, for making templates (i.e. a create HTMLPage); - building custom minilanguages; - ... This is way I see a 'create' statement is frightening powerful addition to the language. 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?
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 m():
a = 1
b = 2
where 'module' would be the following function:
def module(name, args, dic):
mod = types.ModuleType(name, dic.get('__doc__'))
for k in dic: setattr(mod, k, dic[k])
return mod
Wow. This looks like an almighty tool. We can have modules, interfaces,
classes and properties all the like with this.
Guess a PEP would be nice.
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
The result would be roughly equivalent to:
kwds = {}
exec BLOCK in kwds
NAME = TYPE(NAME, ARGS, kwds)
Such that the existing 'class' statement is equivalent to:
create __metaclass__ NAME(ARGS):
BLOCK
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?
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
where 'module' would be the following function:
def module(name, args, dic):
mod = types.ModuleType(name, dic.get('__doc__'))
for k in dic: setattr(mod, k, dic[k])
return mod
Wow. This looks like an almighty tool. We can have modules, interfaces,
classes and properties all the like with this.
Guess a PEP would be nice.
Reinhold
___
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, 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 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)
For instance properties could be defined as follows:
def Property(name, args, dic):
return property(
dic.get('fget'), dic.get('fset'), dic.get('fdel'), dic.get('__doc__'))
Property p():
I am a property
def fget(self):
pass
def fset(self):
pass
def fdel(self):
pass
Another typical use case could be a dispatcher:
class Dispatcher(object):
def __init__(self, name, args, dic):
self.dic = dic
def __call__(self, action, *args, **kw):
return self.dic.get(action)(*args, **kw)
Dispatcher dispatch(action):
def do_this():
pass
def do_that():
pass
def default():
pass
dispatch('do_this')
Notice that the proposal is already implementable by abusing the class
statement:
class name tuple:
__metaclass__ = callable
definitions
But abusing metaclasses for this task is ugly. BTW, if the proposal was
implemented, the 'class' would become redundant and could be replaced
by 'type':
class classname bases:
definitions
=
type classname bases:
definitions
;)
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 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
...etc...
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)
Cor. That looks like very neat/scary stuff. I'm not sure if I feel
that that is a good thing or a bad thing :-)
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 literal
translation will result in a NameError. Maybe an expansion
name = something('name', (), dict)
would be better (ie, the callable gets the *name* of the target as an
argument, rather than the old value).
Also, the definitions bit needs some clarification. I'm guessing
that it would be a suite, executed in a new, empty namespace, and the
dict-of-definitions is the resulting modified namespace (with
__builtins__ removed?)
In other words, take definitions, and do
d = {}
exec definitions in d
del d['__builtins__']
then dict-of-definitions is the resulting value of d.
Interesting idea...
Paul.
___
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/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 literal
translation will result in a NameError. Maybe an expansion
name = something('name', (), dict)
would be better (ie, the callable gets the *name* of the target as an
argument, rather than the old value).
Also, the definitions bit needs some clarification. I'm guessing
that it would be a suite, executed in a new, empty namespace, and the
dict-of-definitions is the resulting modified namespace (with
__builtins__ removed?)
In other words, take definitions, and do
d = {}
exec definitions in d
del d['__builtins__']
then dict-of-definitions is the resulting value of d.
Interesting idea...
Paul.
name would be a string and dict-of-definitions a dictionary.
As I said, the semantic would be exactly the same as the current
way of doing it:
class name args:
__metaclass__ = callable
I am just advocating for syntactic sugar, the functionality is already there.
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?
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 Property p()) If others find it interesting and Guido doesn't frown on it, maybe we should sit down and start writing a PEP ? ciao Antoine. ___ 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?
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] BTW, if the proposal was implemented, the 'class' would become redundant and could be replaced by 'type': class classname bases: definitions = type classname bases: definitions Wow, that's really neat. And you save a keyword! ;-) I'd definitely like to see a PEP. STeVE -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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?
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 tree or something. ___ 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?
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 function (get rid of def). 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 think) that type Foo (base): def __init__(self): pass would be equivalent to class Foo (base): def __init__(self): pass and thought that function myfunc(arg1, arg2): pass would be equivalent to def myfunc(arg1, arg2): pass where function a builtin that when called returns a new function. 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
Re: [Python-Dev] Definining properties - a use case for class decorators?
[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! ;-) Two if you add a builtin called function (get rid of def). 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 think) that type Foo (base): def __init__(self): pass would be equivalent to class Foo (base): def __init__(self): pass and thought that function myfunc(arg1, arg2): pass would be equivalent to def myfunc(arg1, arg2): pass where function a builtin that when called returns a new function. For it to work in classes, it would need to execute the body of the class, which is precisely why it can't work with functions. - 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] Definining properties - a use case for class decorators?
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 think) that type Foo (base): def __init__(self): pass would be equivalent to class Foo (base): def __init__(self): pass and thought that function myfunc(arg1, arg2): pass would be equivalent to def myfunc(arg1, arg2): pass where function a builtin that when called returns a new function. For it to work in classes, it would need to execute the body of the class, which is precisely why it can't work with functions. Not only that, but the '(arg1, arg2)' for classes is a tuple of *values*, but for functions it's just a function signature, not an expression! Which is why this would effectively have to be a macro facility. ___ 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] 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] Definining properties - a use case for class decorators?
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 like self refers to the wrong type, but I'm
not convinced anyone would be confused.
class MetaProperty(type):
def __new__(cls, name, bases, dct):
if bases[0] is object: # allow us to create class Property
return type.__new__(cls, name, bases, dct)
return property(dct.get('get'), dct.get('set'),
dct.get('delete'), dct.get('__doc__'))
def __init__(cls, name, bases, dct):
if bases[0] is object:
return type.__init__(cls, name, bases, dct)
class Property(object):
__metaclass__ = MetaProperty
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!'
___
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?
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 once again, that metaclasses are the one true way to monkey with classes ;) Cheers, Nick. P.S. I think I need an email program that disables the send button after 11 pm. . . -- 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?
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 are an implementation detail). Certainly the proposed solutions so far are worse than the problem. I agree with that (except for mine, of course :-). I still feel that the ultimate solution lies in some form of syntactic support, although I haven't decided what yet. But since you define the API, are you sure that you need properties at all? Maybe the users would be happy to write widget.get_foo() and widget.set_foo(x) instead of widget.foo or widget.foo = x? I'm one of my main users, and I wouldn't be happy with it. I *have* thought about this quite carefully. An early version of the PyGUI API (predating properties) did things that way, and people complained. After re-doing it with properties, and getting some experience using the result, I'm convinced that properties are the way to go for this particular application. To which Tim Delaney responded, have a look at my response here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713 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. 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 my version, it's not *really* redundant, since the name is only used to derive the names of the accessor methods. It doesn't *have* to be the same as the property name, although using anything else could justifiably be regarded as insane... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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?
[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 my version, it's not *really* redundant, since the
name is only used to derive the names of the accessor methods.
It doesn't *have* to be the same as the property name, although
using anything else could justifiably be regarded as insane...
OK, so how's this for a radical proposal.
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 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')
def getFoo(self):
return self._foo
def setFoo(self, foo):
self._foo = foo
What do you think?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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?
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 Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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 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 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')
def getFoo(self):
return self._foo
def setFoo(self, foo):
self._foo = foo
What do you think?
Ick, for all the reasons that strings are less appealing than names.
IMO, there's not enough advantage in having the property() call before
the functions than after.
-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?
[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 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')
def getFoo(self):
return self._foo
def setFoo(self, foo):
self._foo = foo
What do you think?
[Barry]
Ick, for all the reasons that strings are less appealing than names.
I usually wholeheartedly agree with that argument, but here I don't
see an alternative.
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
changing the docstring or having to repeat the property() call. That
requires us to do a late binding lookup based on a string.
Tim Delaney had a different solution where you would pass in the
functions but all it did was use their __name__ attribute to look up
the real function at runtime. The problem with that is that the
__name__ attribute may not be what you expect, as it may not
correspond to the name of the object passed in. Example:
class C:
def getx(self): ...something...
gety = getx
y = property(gety)
class D(C):
def gety(self): ...something else...
Here, the intention is clearly to override the way the property's
value is computed, but it doesn't work right -- gety.__name__ is
'getx', and D doesn't override getx, so D().y calls C.getx() instead
of D.gety().
If you can think of a solution that looks better than mine, you're a genius.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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 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 changing the docstring or having to repeat the property() call. That requires us to do a late binding lookup based on a string. True, I missed that use case. But can't you already support override-ability just by refactoring the getter and setter into separate methods? IOW, the getter and setter isn't overridden, but they call other methods that implement the core functionality and that /are/ overridden. Okay, that means a few extra methods per property, but that still doesn't seem too bad. If you can think of a solution that looks better than mine, you're a genius. Oh, I know that's not the case, but it's such a tempting challenge, I'll try anyway :). class A(object): def __init__(self): self._x = 0 def set_x(self, x): self._set_x(x) def _set_x(self, x): print 'A._set_x()' self._x = x def get_x(self): return self._get_x() def _get_x(self): print 'A._get_x()' return self._x x = property(get_x, set_x) class B(A): def _set_x(self, x): print 'B._set_x()' super(B, self)._set_x(x) def _get_x(self): print 'B._get_x()' return super(B, self)._get_x() a = A() b = B() a.x = 7 b.x = 9 print a.x print b.x Basically A.get_x() and A.set_x() are just wrappers to make the property machinery work the way you want. -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?
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.
--
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?
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 strings. Well, unless you're going to also do #8 (a notation for code), I'd agree. :) But then again, Graham also lists #6 (programs composed of expressions), and even though I'm often tempted by the desire to write something as a big expression, the truth is that most people's brains (mine included) just don't have enough stack space for it. The people that have that much mental stack space can already write lambda+listcomp atrocities for the rest of us to boggle at. :) Logix (http://livelogix.net/logix/) basically adds everything on Graham's list to Python, and then compiles it to Python bytecode. But the result is something that still doesn't seem very Pythonic to me. Of course, with good restraint, it seems to me that Logix allows some very tasteful language extensions (John Landahl created a nice syntax sugar for generic functions with it), but making full-tilt use of Graham's 9 features seems to result in a very Lisp-like experience, even without the parentheses. At the same time, I would note that Ruby does seem to have an edge on Python in terms of ability to create little languages of the sort that Logix also excels at. Compare SCons (Python) with Rakefiles (Ruby), for example, or SQLObject (Python) to Rails' ActiveRecord. In each case, the Python DSL syntax is okay, but Ruby's is better. Even PEP 340 in its heydey wasn't going to improve on it much, because Ruby DSL's benefit mainly from being able to pass the blocks to functions which could then hold on to them for later use. (Also, in an ironic twist, Ruby requires fewer parentheses than Python for such operations, so the invocation looks more like user-defined syntax.) ___ 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?
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 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')
def getFoo(self):
return self._foo
def setFoo(self, foo):
self._foo = foo
What do you think?
Ick, for all the reasons that strings are less appealing than names.
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 the late-binding problem (I
believe), at the cost of either adding an extra argument to the
functions forming the property or confusing the self argument a
little.
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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/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 the late-binding problem (I
believe), at the cost of either adding an extra argument to the
functions forming the property or confusing the self argument a
little.
That is probably as good as you can get it *if* you prefer the nested
class over a property call with string arguments. Personally, I find
the nested class inheriting from Property a lot more magical than
the call to property() with string arguments.
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...
which would somehow translate into code similar to your recipe.
But until then, I prefer the simplicity of
foo = property('get_foo', 'set_foo')
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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?
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): print Deleting attribute on instance The code looks like self refers to a test instance, but it will actually refer to a Demo instance. This is quite misleading. ___ 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 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 'apply' pattern without too many internal objections for this: class Foo(object): # just a simple example, practically pointless _my_property = None @apply def my_property(): def get(self): return self._my_property def set(self, value): self._my_property = value return property(get, set) IMHO, I find this easier to parse than either of your two examples. Apologies if this has already been screamed at. :-) Gary ___ 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/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 Python already contains a construct for grouping multiple related functions together: classes. 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 clear, and probably less typing (and certainly less indenting!). Just write this: class C: def getFoo(self): ... def setFoo(self): ... foo = property(getFoo, setFoo) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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/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 span multiple functions. However, it occurred to me that Python already contains a construct for grouping multiple related functions together: classes. 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 clear, and probably less typing (and certainly less indenting!). Just write this: class C: def getFoo(self): ... def setFoo(self): ... foo = property(getFoo, setFoo) Does this necessisarily mean a 'no' still for class decorators, or do you just not like this particular use case for them. Or, are you perhaps against this proposal due to its use of nested classes? ___ 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/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 clear, and probably less typing (and certainly less indenting!). Just write this: class C: def getFoo(self): ... def setFoo(self): ... foo = property(getFoo, setFoo) Does this necessisarily mean a 'no' still for class decorators, or do you just not like this particular use case for them. Or, are you perhaps against this proposal due to its use of nested classes? I'm still -0 on class decorators pending good use cases. I'm -1 on using a class decorator (if we were to introduce them) for get/set properties; it doesn't save writing and it doesn't save reading. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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?
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 be desired, for all the same reasons that have
led to @-decorators.
However, I agree that trying to keep the accessor method
names out of the class namespace isn't necessary, and may
not even be desirable. The way I'm defining properties in
PyGUI at the moment looks like this:
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 particularly important in PyGUI, where I have a generic
class definition which establishes the valid properties
and their docstrings, and implementation subclasses for
different platforms which supply the accessor methods.
The only wart is the necessity of mentioning the property
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL PROTECTED] +--+
___
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?
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 point I was going to bring up.
The only wart is the necessity of mentioning the property
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
Have a look at my comment to Steven Bethard's recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
Tim Delaney
___
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?
[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 be desired, for all the same reasons that have
led to @-decorators.
My challenge to many people, including you, is to make that feeling
more concrete. Sometimes when you have such a feeling it just means
you haven't drunk the kool-aid yet. :)
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. Certainly the proposed solutions so
far are worse than the problem.
However, I agree that trying to keep the accessor method
names out of the class namespace isn't necessary, and may
not even be desirable. The way I'm defining properties in
PyGUI at the moment looks like this:
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 particularly important in PyGUI, where I have a generic
class definition which establishes the valid properties
and their docstrings, and implementation subclasses for
different platforms which supply the accessor methods.
But since you define the API, are you sure that you need properties at
all? Maybe the users would be happy to write widget.get_foo() and
widget.set_foo(x) instead of widget.foo or widget.foo = x?
The only wart is the necessity of mentioning the property
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
To which Tim Delaney responded, have a look at my response here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
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. Looking
at that version, I think it's obscuring the semantics; it (ab)uses the
fact that a function's name is accessible through its __name__
attribute. But (unlike Greg's version) it breaks down when one of the
arguments is not a plain function. This makes it brittle in the
context of renaming operations, e.g.:
getx = lambda self: 42
def sety(self, value): self._y = value
setx = sety
x = LateBindingProperty(getx, setx)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
