Paul Boddie wrote:
> The principal advantage of the property function was to permit the
> definition of "active" attributes without having a huge
> "if...elif...else" statement in the __getattr__ method. So the
> motivation was seemingly to externalize the usually simple logic in
> __getattr__ so that one could know a bit more about the supported
> properties of an object without having to read the source code.
>
> Java should be able to support Python-style properties by converting
> property accesses to accessor method calls before runtime, but with
> this capability within easy reach (and in all irony), the creators of
> the language instead decided to force programmers to explicitly call
> these rigidly-named methods, despite the raw property names actually
> being exposed to external tools like property editors, JavaServer
> Pages, and so on.
The accessor() was dedicated to someone in another newsgroup who came
from Java to Python and was annoyed by the _get, _set clutter which
reminds him to Java. He replaced property() alltogether by an own
construct. I wanted to convince him ( and also myself! ) that
property() can be customized for creating accessors with very few
syntax.
>
> [accessor code cut]
>
> > class X(object):
> > a = accessor("a")
> > b = accessor("b", types = (tuple,list))
> > c = accessor("c", check = lambda x:hasattr(x,"__len__"))
>
> Hmmm, lambda!
Hi,Hi :)
This would not be much more code is even generic:
def are_attrs_present(*attrs):
def check_for_attrs(x):
return not False in [hasattr(x,attr) for attr in attrs]
return check_for_attrs
class X(object):
a = accessor("a")
b = accessor("b", types = (tuple,list))
c = accessor("c", check = are_attrs_present("__len__","__add__"))
>>> x = X()
>>> x.c = 0 # raise TypeError ...
>>> x.c = "ok" # ok
> This is a nice example, but I do wonder why so many examples of
> Python's dynamicity, especially with many of the newer features, seek
> to provide static type checking or some other variant on that theme.
> It would be nice to see more work done at the level of the compiler
to
> achieve those kinds of goals.
The motto "changing everything any time" demands a complete flow
analysis if one wants to make the compiler doing the typechecks. Even
the PyPy team has struggling with type inference ( "annotation" ) for a
long time and has not yet finished. So everyone is adding an ad-hoc
typechecker which means that there is really a need and Guido is right
in proposing some "type guards" allthough this hurts again a lot of
souls as we can observe in this thread too. His current suggestions are
either too restricted for each of the peoples requirements (
isinstance-typechecking, duck-typechecking, adaption ) or it is overly
permissive and is in danger to mean everything and nothing. Not to
speak about performance gains doing typechecks at runtime :-(
Regards Kay
--
http://mail.python.org/mailman/listinfo/python-list
