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
The ctypes sources contain the source code for libffi, in
Modules/_ctypes/libffi.
These sources were pulled from GCC cvs some time ago, and a new configure system
was written by Perky iirc.
Now, it seems that these sources are showing their age and a newer libffi
version
should be used instead.
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
On Oct 30, 2007 4:10 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> My question now is what specific kernel32 functions Python 2.4
> >> calls to determine that NUL is a file; before that question
> >> is sufficiently answered, I don't think any action should be
> >> taken.
> >>
> >
> > os.pa
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
ACTIVITY SUMMARY (10/24/07 - 10/31/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1320 open (+25) / 11530 closed (+20) / 12850 total (+45)
Open issues with patches: 418
Average durati
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):
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, prop.__doc__)
return helper
we can declare getters and sett
28 matches
Mail list logo
