[Python-Dev] Re: decorators and 2.4

[Jeff Bone]

On Jun 28, 2004, at 9:05 PM, Phillip J. Eby wrote:

> At 04:29 PM 6/28/04 -0500, Jeff Bone wrote:
>> If you allow conditional evaluation or parameterization of decorators 
>> w/o some consideration about their impact on static type analysis --- 
>> as in the nightmare scenario I offered previously --- AND if you 
>> believe that adding some optional static typing and type analysis to 
>> Python in the future is at least possibly desirable, then it leads 
>> one to consider whether additional constraints  *might* be in order.
>
> No, it doesn't.

Yes, it does --- as the examples offered indicate.				
> You can already make weird decorators that disassemble the bytecode of 
> the function and create a new function object, for example.  PEP 318 
> does nothing to change that fact.

True, but irrelevant unless you happen to be strategically myopic and 
slightly programming-language illiterate.  Tell me, Phil --- what is 
your damage here?  I believe we both want the same outcome.  So why are 
you getting so aggressive (or defensive, I can't tell which) about the 
route to the particular, and shared, outcome?  As surely as I'm 
convinced about the need for and worthiness of certain considerations 
about static type-checking and the future of this language, I'm willing 
to grant that you're equally concerned about something else, even 
though I don't yet know what.  Why can't we have the discussion on that 
factual basis instead of bogus third-hand references to the 
questionable intent (though somewhat clear, but still questionable 
relative to desiderata) of a spec you didn't write?

The only legit explanation I can think of is that *you know how to 
implement the PEP as you understand it now, but fail to understand the 
longer-term implications of said interpretation of PEP / 
implementation."  Take the time to connect w/ me or others on these 
concerns;  I think you will find them not entirely out of sync.  I may 
not have posted here much over the years, but I'm sure both I and 
countless others have put in the time to get the hearing for our 
concerns w/o being swatted down w/ an inconclusive spec like and 
ignorant school-marm swatting an overly-inquisitive 2nd-grader.

> Thus, attempting to define restrictions for them is moot,

No, it's not -- as demonstrated previously.

> as far as anybody attempting to create program analysis tools -- they 
> already have to deal with this dynamism today, and restricting PEP 318 
> simply won't help.

What a completely BS response.

Yet --- true, but only if one accepts a particular and rather 
simple-minded and overly-literal interpretation of the ***GOALS*** of 
PEP 318, driven by hackers that are inclined to hack certain changes 
into THE (and that in itself is an indictment) implementation of the 
language --- changes that that are very lightly implied by the PEP into 
the interpreter, rather than considering the longer-term goals and 
objectives of both the PEP and the language.  And THAT IS MY POINT.

jb
CTO, Deepfile