[Python-ideas] Before and after the colon in funciton defs.

[Devin Jeanpierre]

>  Yes, you're right that this can't be done with today's decorators.

It can work with today's decorators and today's syntax, it just requires magic.

(Magic doesn't mean "impossible things", it means "things that go
below the expected level of abstraction". In this case, things like
directly inspecting fields of the function object and creating a new
one with modified fields -- that, or else mutating a
supposedly-immutable object (also possible))

That doesn't blow down the whole idea of $ special syntactic
decorators, though. And maybe even this case is good for them.
Definitely there might be room for a more general-case thing for
compile-time annotations than new extra-special syntax. Magical
decorators that get understood by the compiler have been mentioned
before, and are inappropriate for obvious reasons. But if they were
prefixed by $ instead of @...

I still like real decorators because they can be applied at run-time
instead of just compile-time, which gives them additional use-cases.

Devin

On Thu, Sep 22, 2011 at 10:18 PM, Bruce Leban <bruce at leapyear.org> wrote:
>
> On Thu, Sep 22, 2011 at 6:11 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On Fri, Sep 23, 2011 at 9:51 AM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>> > With decorator syntax, the scoping rules are obvious and
>> > straightforward:
>> >
>> > a = 10
>> > @inject(b=a)
>> > def foo():
>> >    a = 20
>> >    return b+a
>>
>> Please read the previous thread from June (linked earlier in this
>> thread). Decorator syntax cannot work without deep magic, because the
>> compiler *doesn't know* that injected names need to be given special
>> treatment.
>>
>
>  Yes, you're right that this can't be done with today's decorators. That
> doesn't mean it's impossible. Any of the other changes would also require
> compiler changes. Instead of @inject being a standard decorator, imagine a
> new kind of decorator that works as follows:
>
> a = 10
> $inject(b=a)
> def foo()
>     a = 20
>     return b+a
>
> where the effect of a $inject decorator is that it modifies the behavior of
> the function as follows:
>
> a = 10
> _inject_ = inject_decorator(b=a)
> def foo():
>     locals().update(_inject_)
>     a = 20
>     return b + a
>
> Yes, I know that update on locals() won't do the right thing but pretend it
> does. I think the semantics of this are pretty clear and more obvious than
> the suggested alternatives. Now what about these $-decorators? As defined
> here, it's pretty specialized to this one operation. Let's imagine that we
> define $-decorators to be a special class of decorators that are built into
> Python. We use $-decorators for cases we would like users to think of as
> decorators but that do some kind of magic that's beyond the capability of a
> regular decorator. To the user the $ is a signal to the user that this
> decorator is a bit more special than usual. Right now, there would only be
> one $-decorator but it's available next time it's desired to add something
> that just can't quite be a regular decorator.
> A good objection to adding new things to the language is that they increase
> the load on people trying to learn the language. If I see a syntax like:
>
> def f() [i=i]: pass
>
> I can't imagine how I would find out what that does. Search engines don't
> readily allow searching on special characters. On the other hand, when I see
> $inject, I go type "python $inject decorator" into my favorite search engine
> and whether it ignores the $ or not, I'm fairly likely to get good results.
> Whether the decorator-like syntax is spelled $inject, @@static or something
> else, I think it's going to be much easier to figure out and remember what's
> going on.
>
> --- Bruce
> Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>