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?
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?
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?
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?
Nick Coghlan <[EMAIL PROTECTED]> wrote: > > 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. The rules for which metaclass is used is listed in the metaclass documentation. I personally never claimed it was perfect, and neither is this one... class NAME(_(TYPE, ARGS)): BLOCK But it does solve the problem without needing syntax (and fixes any possible metaclass order choices). > 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. That's perfectly reasonable. > (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) Perhaps, but because the metaclass can return anything (in this case, it returns a property), being able to modify the object that is created may be desireable...at which point, we may as well get class decorators for the built-in chaining. - 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?
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?
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?
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/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?
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> 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)
And is equivalent to the class/metaclass abuse...
#suport code
def BlockMetaclassFactory(constructor):
class BlockMetaclass(type):
def __new__(cls, name, bases, dct):
return constructor(name, bases, dct)
return BlockMetaClass
#non-syntax syntax
class NAME(ARGS):
__metaclass__ = BlockMetaclassFactory(TYPE)
BLOCK
Or even...
def BlockClassFactory(constructor):
class BlockClass:
__metaclass__ = BlockMetaclassFactory(constructor)
return BlockClass
class NAME(BlockClassFactory(TYPE), ARGS):
BLOCK
To be used with properties, one could use a wrapper and class definition...
def _Property(names, bases, dct):
return property(**dct)
Property = BlockClassFactory(_Property)
class foo(object):
class x(Property):
...
With minor work, it would be easy to define a subclassable Property
which could handle some basic styles: write once, default value, etc.
I am unconvinced that a block syntax is necessary or desireable for this
case. With the proper support classes, you can get modules, classes,
metaclasses, properties, the previous 'given:' syntax, etc.
- 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?
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?
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
___
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?
[EMAIL PROTECTED] wrote: > > > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: > > Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: > >> >> : > >> >> > >> ... > >> > 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?
> "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: >> >> : >> >> >> ... >> 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?
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: > >> : > >> > ... > > 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?
>> : >> ... Steve> Wow, that's really neat. And you save a keyword! ;-) Two if you add a builtin called "function" (get rid of "def"). 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?
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 > > : > > > to be syntactic sugar for > > = (, , ) > [snip] > BTW, if the proposal was implemented, the 'class' would become > redundant and could be replaced by 'type': > > class : > > > <=> > > type : > 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?
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?
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():
>
>
> This expands to
>
> name = something(name, (), )
>
> What should happen if name wasn't defined before? A literal
> translation will result in a NameError. Maybe an expansion
>
> name = something('name', (), )
>
> would be better (ie, the callable gets the *name* of the target as an
> argument, rather than the old value).
>
> Also, the bit needs some clarification. I'm guessing
> that it would be a suite, executed in a new, empty namespace, and the
> is the resulting modified namespace (with
> __builtins__ removed?)
>
> In other words, take , and do
>
> d = {}
> exec in d
> del d['__builtins__']
>
> then is the resulting value of d.
>
> Interesting idea...
>
> Paul.
>
would be a string and a dictionary.
As I said, the semantic would be exactly the same as the current
way of doing it:
class :
__metaclass__ =
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?
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
>
> :
>
>
> to be syntactic sugar for
>
> = (, , )
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():
This expands to
name = something(name, (), )
What should happen if name wasn't defined before? A literal
translation will result in a NameError. Maybe an expansion
name = something('name', (), )
would be better (ie, the callable gets the *name* of the target as an
argument, rather than the old value).
Also, the bit needs some clarification. I'm guessing
that it would be a suite, executed in a new, empty namespace, and the
is the resulting modified namespace (with
__builtins__ removed?)
In other words, take , and do
d = {}
exec in d
del d['__builtins__']
then 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/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
:
to be syntactic sugar for
= (, , )
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 :
__metaclass__ =
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 :
<=>
type :
;)
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?
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 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?
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?
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 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?
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?
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?
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?
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?
[Barry]
> > > IMO, there's not enough advantage in having the property() call before
> > > the functions than after.
[Guido]
> > 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.
[Barry]
> 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 :).
[...]
Nice try. I guess it's similar to this, which is a bit more concise
and doesn't require as many underscores:
class B:
def get_x(self): return self._x
def set_x(self, x): self._x = x
x = property(lambda self: self.get_x(), lambda self, x: self.set_x(x))
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!
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. This makes it easy
to constructs names on the fly that you pass to getattr() and
setattr() using standard string operations. Suppose the symbol type
were written as \foo (meaning a quoted reference to the identifier
'foo'). Then the above could be written like this:
x = property(\get_x, \set_x)
But I'm not sure this buys us anything, so I still believe that using
'set_x' and 'get_x' is just fine here. Greg Ewing, whose taste in
language features is hard to beat, seems to agree.
--
--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?
[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?
Barry Warsaw wrote: > 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. That's not the only benefit - you also get overridability of the accessor methods. -- 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 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?
[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: > 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?
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?
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?
[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
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 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?
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?
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, 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 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?
>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
[Python-Dev] Definining properties - a use case for class decorators?
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. And that thought led me to this decorator: def def_property(cls_func): cls = cls_func() try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) Obviously, this decorator can only be used by decorating a function that returns the class of interest: class Demo(object): @def_property def test(): class prop: """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" return prop Which gives the following behaviour: Py> Demo.test Py> Demo().test Getting attribute on instance Py> Demo().test = 1 Setting attribute on instance Py> del Demo().test Deleting attribute on instance Py> help(Demo.test) Help on property: This is a test property = get(self) = set(self, value) = delete(self) If we had class decorators, though, the decorator could be modified to skip the function invocation: def def_property(cls): try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) And the usage would be much more direct: 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" Comments? Screams of horror? 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
