On Nov 10, 2007 1:43 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Good work Guido!
With sich a ringing endorsement, I've submitted this to the 2.6 trunk
and the py3k branch.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Pyth
Guido van Rossum wrote:
> Which is sometimes convenient. But thinking about this some more I
> think that if I *wanted* to use the same method as setter and deleter,
> I could just write
>
> @foo.setter
> @foo.deleter
> def foo(self, value=None): ...
>
> So I'm withdrawing the hacks, making the c
On Nov 10, 2007 11:09 AM, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On Nov 10, 2007 11:31 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Unless I get negative feedback really soon I plan to submit this later
> > today. I've tweaked the patch slightly to be smarter about replacing
> > the set
On Nov 10, 2007 11:31 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Unless I get negative feedback really soon I plan to submit this later
> today. I've tweaked the patch slightly to be smarter about replacing
> the setter and the deleter together if they are the same object.
Definitely +1 on
Unless I get negative feedback really soon I plan to submit this later
today. I've tweaked the patch slightly to be smarter about replacing
the setter and the deleter together if they are the same object.
On Nov 9, 2007 10:03 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> D'oh. I forgot to poin
D'oh. I forgot to point to the patch. It's here:
http://bugs.python.org/issue1416
On Nov 9, 2007 10:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> To follow up, I now have a patch. It's pretty straightforward.
>
> This implements the kind of syntax that I believe won over most folks
> in the
To follow up, I now have a patch. It's pretty straightforward.
This implements the kind of syntax that I believe won over most folks
in the end:
@property
def foo(self): ...
@foo.setter
def foo(self, value=None): ...
There are also .getter and .deleter descriptors. This includes the ha
On 11/2/07, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Fred Drake wrote:
> >>@property
> >>def attribute(self):
> >>return 42
> >>
> >>@property.set
> >>def attribute(self, value):
> >>self._ignored =
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Fred Drake wrote:
>>@property
>>def attribute(self):
>>return 42
>>
>>@property.set
>>def attribute(self, value):
>>self._ignored = value
>
> Hmmm... if you were allowed general lvalues as the target
On Nov 1, 2007, at 9:18 PM, Fred Drake wrote:
Thanks! Of all the proposals that have been presented, I still like
that the best.
I've attached a quick hack of an implementation, just to play with it
and see how it feels. Here's an example use:
from property import property
class Base(o
On Oct 31, 2007, at 10:23 PM, Barry Warsaw wrote:
> BTW, +1 on this. I like Fred's suggestion of property.set().
Thanks! Of all the proposals that have been presented, I still like
that the best.
Guido's use case of wanting to give the r/w property a different name
than the r/o property is
On 11/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:11 AM 11/2/2007 +1300, Greg Ewing wrote:
> >Raymond Hettinger wrote:
> > > Let's stick with "propset" which has precedent as an svn action and
> > > serves as a short, simple mnemonic to the functionality.
> >
> >But if we're going to h
At 11:11 AM 11/2/2007 +1300, Greg Ewing wrote:
>Raymond Hettinger wrote:
> > Let's stick with "propset" which has precedent as an svn action and
> > serves as a short, simple mnemonic to the functionality.
>
>But if we're going to have "propset", it raises the question
>of why there isn't a "propg
Raymond Hettinger wrote:
> Let's stick with "propset" which has precedent as an svn action and
> serves as a short, simple mnemonic to the functionality.
But if we're going to have "propset", it raises the question
of why there isn't a "propget".
--
Greg
Fred Drake wrote:
>@property
>def attribute(self):
>return 42
>
>@property.set
>def attribute(self, value):
>self._ignored = value
Hmmm... if you were allowed general lvalues as the target of a
def, you could write that as
def attribute.
Guido van Rossum wrote:
> if you want more control, you can just get the property object out of
> the class you want
You're quite right. I was thinking that getting the
property would trigger the access machinery, but of
course you're getting it from the class rather than
the instance, so that doe
-1. Looks like more magic, not less, to me.
On 11/1/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On Nov 1, 2007, at 10:26 AM, [EMAIL PROTECTED] wrote:
> > This is a minor nit, as with all decorators that take an argument,
> > it seems like it sets up a hard-to-debug error condition if you were
>
On Nov 1, 2007, at 10:26 AM, [EMAIL PROTECTED] wrote:
> This is a minor nit, as with all decorators that take an argument,
> it seems like it sets up a hard-to-debug error condition if you were
> to accidentally forget it:
>
> @property
> def foo(): ...
> @property.set
> def foo(): ...
On 11/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This is a minor nit, as with all decorators that take an argument, it
> seems like it sets up a hard-to-debug error condition if you were to
> accidentally forget it:
>
> @property
> def foo(): ...
> @property.set
> def foo(
On 02:01 pm, [EMAIL PROTECTED] wrote:
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
As long as we're all tossing out ideas here, my 2�. I vastly prefer
this:
>>@property.set
to this:
> @property.set(attribute)
I don't approve of it. It has always been and will always
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 1, 2007, at 10:01 AM, Guido van Rossum wrote:
> On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> As long as we're all tossing out ideas here, my 2¢. I vastly prefer
>> this:
>>
>> On 02:43 am, [EMAIL PROTECTED] wrote:
>>> On 10/31/
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> As long as we're all tossing out ideas here, my 2¢. I vastly prefer
> this:
>
> On 02:43 am, [EMAIL PROTECTED] wrote:
> >On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote:
>
> >>@property.set
> >>def attribute(self, value)
"Steven Bethard" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote:
>> If I had to choose built-in names, though, I'd prefer "property",
>> "propset", "propdel". Another possibility that seems reasonable
>> (perhaps a bit better) would be:
>>
As long as we're all tossing out ideas here, my 2¢. I vastly prefer
this:
On 02:43 am, [EMAIL PROTECTED] wrote:
On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote:
@property.set
def attribute(self, value):
self._ignored = value
to this:
@property.set(attribut
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> I'm not sure about the name "propset" ...
| >Maybe something like "setproperty" would be better.
|
| I think not. Saying "setproperty" has too many ambiguous mental
parsings. When does "set" take place -- assig
On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> If I had to choose built-in names, though, I'd prefer "property",
> "propset", "propdel". Another possibility that seems reasonable
> (perhaps a bit better) would be:
>
>class Thing(object):
>
>@property
>def attribute(self):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2007, at 2:14 PM, Guido van Rossum wrote:
> On 10/31/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> I'd like to make this [propset] a standard built-in,
>>
>> +1 -- I find this to be an attractive syntax
>>
>>> I'd also like to change
On Thu, Nov 01, 2007, Greg Ewing wrote:
>
> But there's something that bothers me about the whole propery
> mechanism -- there's no straightforward way for a property accessor to
> call the inherited version from a base class.
>
> Wrapping property accessors up in decorators makes this worse. At
>
On Oct 31, 2007, at 4:28 PM, Guido van Rossum wrote:
> Given how rarely supporting deletions matters enough to write extra
> code, we can just say that *when using @propset* your setter function
> needs to have a default value for the argument or otherwise support
> being called with one or two arg
> I'm not sure about the name "propset" ...
>Maybe something like "setproperty" would be better.
I think not. Saying "setproperty" has too many ambiguous mental parsings.
When does "set" take place -- assigning a value to a property is different
defining the property itself. Is "set" a verb
On 10/31/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Isn't there? You can just use super() ISTR,
>
> That may work, now that I come to think about it.
>
> However, super() is not a complete solution, because
> it doesn't let you choose which inherited method
> to call in
At 12:06 PM 11/1/2007 +1300, Greg Ewing wrote:
>Guido van Rossum wrote:
> > Isn't there? You can just use super() ISTR,
>
>That may work, now that I come to think about it.
>
>However, super() is not a complete solution, because
>it doesn't let you choose which inherited method
>to call in a multip
Guido van Rossum wrote:
> Isn't there? You can just use super() ISTR,
That may work, now that I come to think about it.
However, super() is not a complete solution, because
it doesn't let you choose which inherited method
to call in a multiple inheritance situation.
--
Greg
_
On 10/31/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > @property
> > def encoding(self):
> > return self._encoding
> >
> > @propset(encoding)
> > def encoding(self, value=None):
> > if value is not None:
> > unicode("0", value)
Guido van Rossum wrote:
> @property
> def encoding(self):
> return self._encoding
>
> @propset(encoding)
> def encoding(self, value=None):
> if value is not None:
> unicode("0", value) # Test it
> self._encoding = value
That's reasonably nice,
On 10/31/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:09 AM 10/31/2007 -0700, Guido van Rossum wrote:
> >Yes, though I think that if prop.fdel is None, we could use func in
> >both slots.
>
> Eh? Isn't prop.fdel supposed to be a single-argument function? ISTM
> that C is the only place w
Guido van Rossum wrote:
> I'd like to make this a standard built-in, in the hope the debate on
> how to declare settable properties.
+0.75
It's still not as good as the C# way to create a property but it's so
simple and obvious that it's ingenious again. Every other implementation
would either re
At 11:09 AM 10/31/2007 -0700, Guido van Rossum wrote:
>Yes, though I think that if prop.fdel is None, we could use func in
>both slots.
Eh? Isn't prop.fdel supposed to be a single-argument function? ISTM
that C is the only place where fset and fdel are the same thing.
On 10/31/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:08 AM 10/31/2007 -0700, Guido van Rossum wrote:
> >I've come up with a relatively unobtrusive pattern for defining
> >setters. Given the following definition:
> >
> >def propset(prop):
> > assert isinstance(prop, property)
> > d
On 10/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > I'd like to make this a standard built-in, in the hope the debate on
> > how to declare settable properties.
>
> +1. I'm waiting for the obligatory cry for @propdel though :)
propdel: just say no.
> > I'd also
On 10/31/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I'd like to make this [propset] a standard built-in,
>
> +1 -- I find this to be an attractive syntax
>
> > I'd also like to change property so that the doc
> > string defaults to the doc string of the getter.
>
> +1 -- This should also
Guido van Rossum schrieb:
> I'd like to make this a standard built-in, in the hope the debate on
> how to declare settable properties.
+1. I'm waiting for the obligatory cry for @propdel though :)
> I'd also like to change property so that the doc string defaults to
> the doc string of the gette
> and have a matching propdel decorator?
-1. That would be a complete waste of builtin space.
Put stuff in when it is really needed. Ideas are
not required to automatically propagate from the
commonly used cases to the rarely used cases.
Raymond
___
P
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> I've come up with a relatively unobtrusive pattern for defining
> Guido> setters. Given the following definition:
>
> ...
>
> I'm a pretty naive user of properties, so can you explain to me how what you
> propose is be
> I'd like to make this [propset] a standard built-in,
+1 -- I find this to be an attractive syntax
> I'd also like to change property so that the doc
> string defaults to the doc string of the getter.
+1 -- This should also be done for classmethod,
staticmethod, and anything else that wraps f
At 10:08 AM 10/31/2007 -0700, Guido van Rossum wrote:
>I've come up with a relatively unobtrusive pattern for defining
>setters. Given the following definition:
>
>def propset(prop):
> assert isinstance(prop, property)
> def helper(func):
> return property(prop.__get__, func, func,
Guido> I've come up with a relatively unobtrusive pattern for defining
Guido> setters. Given the following definition:
...
I'm a pretty naive user of properties, so can you explain to me how what you
propose is better than
class C(object):
def __init__(self):
47 matches
Mail list logo
