PEP318: property as decoration

[Sean Ross]

Here's a side "benefit" of this():
# and by "benefit", I mean DUBIOUS side effect <wink>

def f():
        "ffffff"
        my = this()
        print my.__doc__
        print my.__name__

        def g():
                "gggggg"
                my = this()
                print my.__doc__
                print my.__name__
        g()
        my.__dict__['g'] = g

f()
print f.g

"""OUTPUT
ffffff
f
gggggg
g
<function g at 0x00961C70>
"""

If this worked with methods (which it currently does not) it would address
another of the issues I raised in the very long post that started this
thread, that issue being:

If you wanted to declare a property using decorator syntax, in the manner
people appear to be wanting, e.g.

# see the top thread post for the idea behind the use of foo.fget
def foo() as property(foo.fget, None, None, foo.fdoc):
        "foo doc"
        def fget(self):
                ...
        ...

Then, if this() worked inside of methods as it appears to work inside of
functions, you could add the following to foo:

        my = this()
        my.__dict__.update({'fget':fget, 'fdoc':my.__doc__}

foo would be evaluated, it's dictionary would be updated, and then when foo
is passed to the property decorator (which would need to take a functor as
its first argument), the required method information would be available for
the transformation that would be something like this:

foo = property(foo, fget=foo.fget, fset=None, fdel=None, doc=foo.fdoc)

or, if property were changed to *just* take a functor, and it would then
know how to use that functors __dict__ to assemble the descriptor info, you
could get away with:

def foo() as property:
        " foo doc "
        def fget(self):
                ...
        ...
        my = this()
        my.__dict__.update({'fget':fget, 'fdoc':my.__doc__}

The last two lines of which could probably be done, behind the scenes, by
the interpreter.

Et voila! You could now implement properties using decorator syntax.
Similarly, you could make eiffel methods, or whatever other kind of methods
apply, e.g.

def eiffel(self) as contract:
        def fpre():
                ...
        def fpost():
                ...
        def finv():
                ...
        ...



Is that a good thing? No idea. I'm not advocating these ideas, I'm just
putting them out there. Personally, I'd rather use thunks, or stick with
what we have.

Anyway, thanks for the __doc__ inspiration...


"Gerrit Holl" <gerrit at nl.linux.org> wrote in message
news:mailman.1055410883.13759.python-list at python.org...
> Sean Ross wrote:
> > Newsgroups: comp.lang.python
> > Subject: Re: PEP318: property as decoration
>
> > "Gerrit Holl" <gerrit at nl.linux.org> wrote in message
> > > Hmm, that doesn't seem to work. __doc__ is not in my local namespace
yet.
> >
> > Here`s a brittle hack to resolve that issue:
>
> Such a hack isn't that hard of course.
> I solved it by adding "d=" just before my docstring: __doc__
> doesn't need to stay anyway, because this outer function gets overwritten
> by the property.
>
> [skipped code]
>
> > As I say, "this" is a very brittle hack, so don't try this at home
(pardon
> > the pun)
>
> The only place I use frames is in by debug() function: this way, it
> prints the function and lineno of the caller, which easy's debugging.
>
> yours,
> Gerrit.
>
> --
> 168. If a man wish to put his son out of his house, and declare before
> the judge: "I want to put my son out," then the judge shall examine into
> his reasons. If the son be guilty of no great fault, for which he can be
> rightfully put out, the father shall not put him out.
>         -- 1780 BC, Hammurabi, Code of Law
> --
> Asperger Syndroom - een persoonlijke benadering:
> http://people.nl.linux.org/~gerrit/
> Het zijn tijden om je zelf met politiek te bemoeien:
> http://www.sp.nl/
>