RetroSearch Browse

Sun Nov 23 23:52:51 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040412.html

> I was wondering if there would be any interest for adding a special
> case for properties with string-valued fget/fset/fdel:
> 
>      - if fget is a string, then the getter returns the value of the
>        member variable with the given name.
>      - if fset is a string, then the setter sets the value of the
>        member variable with the given name.
>      - if fdel is a string, then the deleter deletes the member variable
>        with the given name.
> 
> I.e., the following groups would be functionally equivalant:
> 
>      property(fget='_foo')
>      property(fget=lambda self: self._foo)
>      property(fget=lambda self: getattr(self, '_foo'))

Why bother with the getattr() example?

>      property(fset='_foo')
>      property(fset=lambda self, value: setattr(self, '_foo', value))

Also of course (and IMO more readable):
       def _set_foo(self, value): self._foo = value
       property(fset=_set_foo)

>      property(fdel='_foo')
>      property(fdel=lambda self: delattr(self, '_foo'))

(And similar here.)

> This change has 2 advantages:
> 
>      1. It's easier to read.  (In my opinion, anyway; what do other
>         people think?)

Only if you're used to the new syntax.  Otherwise it could mean a
costly excursion into the docs.

>      2. It's faster: for properties whose fget/fset/fdel are strings,
>         we can avoid a function call (since the changes are implemented
>         in c).  Preliminary tests indicate that this results in
>         approximately a 3x speedup for a tight loop of attribute
>         lookups.  (It's unclear how much of a speed increase you'd get
>         in actual code, though.)

Which makes me wonder if this argument has much value.

> and one disadvantage (that I can think of):
> 
>      - It's one more special case to document/know.

Right.  It feels like a hack.

> This change shouldn't break any existing code, because there's
> currently no reason to use string-valued fget/fset/fdel.

Correct.

> Does this change seem useful to other people?  Do the advantages
> outweigh the disadvantage?  Or are there other disadvantage that I
> neglected to notice?  If this seems like a useful addition, I'd be
> happy to work on making a patch that includes test cases & doc
> changes.

It feels somewhat un-Pythonic to me: a special case that just happens
to be useful to some folks.  I want to be very careful in adding too
many of those to the language, because it makes it harder to learn and
makes it feel full of surprises for casual users.  (I'm trying hard to
avoid using the word "Perl" here. :-)

I'm curious about the use case that makes you feel the need for speed.
I would expect most properties not to simply redirect to another
attribute, but to add at least *some* checking or other calculation.

I'd be more in favor if you used a separate "renamed" property:

  foo = renamed("_foo")

being a shortcut for

  def _get_foo(self): return self._foo
  def _set_foo(self, value): self._foo = value
  def _del_foo(self): del self._foo
  foo = property(_get_foo, _set_foo, _del_foo)

but I've got a suspicion you want to combine some string argument
(most likely for fget) with some function argument.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040412.html below:

[Python-Dev] string-valued fget/fset/fdel for properties