Are decorators really that different from metaclasses...

[Arthur]

"Jeff Shannon" <jeff at ccvcorp.com> wrote in message
news:10jeuh7o69surc0 at corp.supernews.com...
> Arthur wrote:
>
> >"Jeff Shannon" <jeff at ccvcorp.com> wrote in message
> >news:10jcsuh7k4bfl41 at corp.supernews.com...
> >
> >
> >>(I'm sure that you'll argue that the presence of those "magic" variables
> >>is enough distinction between the two radically-different blocks of
> >>code; I'm also pretty confident that very few people will agree with
> >>you, and that nobody with a reasonable understanding of Python internals
> >>will be among those few people.)
> >>
> >>
> >
> >It seems to me if the defining distinction is a different assignment
> >operator rather than magic associated with naming, then much of
objections I
> >am hearing to what Paul is generally suggesting seems to fall away.
> >
> >I like what Paul Rubin suggested for decorators:
> >
> >::
> >
> >It seemed to me that many folks, and certainly including some
sophisticated
> >users - witness the decorator wiki - felt more than comfortable with some
> >declarative/definitional syntax within the function body.  The discussion
> >was stalled mostly by the realization that Guido had definitively ruled
it
> >out, not on the basis that there was general concensus that the approach
had
> >no appeal - intuitive and otherwise.
> >
> >
>
> I agree with what Paul Rubin says there, as well.  However, I don't
> believe that he was considering syntax that *looks* like
> otherwise-ordinary assignment to "magic" names, which are indicated only
> by naming convention.

I can't speak for Paul.

Having just done some experimentation with overriding "magic" class
methods - __copy__, specifically - I realize that *my* problem in
misunderstanding what:

__name__ = "Callable_Name"

within the function body would accomplish is in having thought by analogy
between this and overriding a "magic" method within a class definition.

An elementatry mistake, on one hand. Though I think a naive view that being
able to work within the langauge by drawing on these kinds of analogies
would - ideally - not lead one off a cliff.  That to me is almost the
definition of intuitive.  Unfortunately what is intutive, naively, might be
anti-intuitive, less naively.  Which is I guess what we have here.

I can't help thinking that within my own conception of what Python tries to
accomplish, such circumstances are in some sense a (perhaps unavoidable)
wart. And Python succeeds to the the extent that my
(more naive) intuitions and your (more educated) intuitions do not lead us
to different results. And I think Python does generally succeed quite well
in this regard. But not always.

Art