Python becoming less Lisp-like

[Kay Schluehr]

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