On Tuesday 2004-06-29 08:04, Jeff Bone wrote:
[Philip Eby:]
>> 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.
[Jeff:]
> 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?
Excuse me, but when you're implying that Philip is "strategically
myopic and slightly programming-language illiterate" and asking
"what is your damage?" and calling his comments "bullshit" and
likening him to "an ignorant school-marm", you are not in a great
position to take the moral high ground about being either "aggressive"
or "defensive".
> 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?
This topic has already been extensively discussed in python-dev.
It is not, in fact, questionable whether the intent of the spec
is to permit a broader range of operations on functions than you
think desirable. It is.
> 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."
Please consider the possibility that other people may understand
your concerns but disagree with them. Being unable to read Philip's
mind, I don't know whether that's his situation, but it certainly
seems plausible to me.
*
Let's rewind a bit here. Unless my mail archives are broken,
your first entry into this discussion was when you declared
that "Decorators are metadata about the function to which they
refer.". Not "it would be preferable to restrict decorators to
[etc]" -- not, that is, a statement about what sort of
decoration ought to be done, or ought to be permitted,
but a statement about what decorators *are*.
Now, doubtless analytic philosophers could spend hours arguing
about what it actually means to make such a statement when
decorators aren't currently part of the language spec. But
it seems reasonable to me to take their meaning to be defined
by some combination of (1) the PEP that proposes their introduction,
(2) the discussion that preceded and followed the writing of
that PEP, and (3) the actual implementations people have produced.
And, according to all three of those, your statement about what
decorators are is, simply, not true. And as long as you're making
statements about what decorators *are* it seems entirely
appropriate for Philip, or anyone else, to point you to the
nearest thing we have to a definition of decorators in Python
when you say something that just ain't so.
Now, certainly, it's also reasonable to discuss what decorators
*should* be, and I think that's what you actually intend in this
thread.
So, your main argument is that decorations should be "declarative".
Unfortunately, it isn't clear to me quite what you mean by
"declarative"; from your response to Michael Chermside's and
Barry Warsaw's examples, it appears that you want to define
it at a rather high level of abstraction -- but at a high enough
level of abstraction (doubtless higher than you have in mind)
*anything* can be construed as "declarative" :-), and it's not
obvious to me where your boundaries are.
So, let me make a proposition that I haven't yet seen anything
to refute:
It is good for decorators to be, in some sufficiently
high-level sense, "declarative". However, at that level,
the meaning of "declarative" is broad enough that any
mechanism that enables the full range of desirable,
"declarative" decorators will also enable the "non-declarative"
uses that you deplore. There is no Python-level restriction
(such as "no functions" or "nothing that looks like functions")
agree are legitimate, and prevent (or even discourage) the
uses of which you disapprove.
I'm willing to guess that you don't agree with that proposition.
Would you care to offer some evidence against it?
Here are a couple of more specific comments you've made:
"Using the same syntax for decorators as for functions
conceptually weakens this distinction and encourages
misuse of decorators, even to the point of potentially
encouraging (or implying) side-effects as a result of
decoration."
It's not clear to me what you mean by "using the same
syntax for decorators as for functions", and the context
in the thread doesn't help. Could you explain in what
way the existing proposals use the same syntax for
decorators as for functions, and how you think that
should be changed?
"To the extent that decorators either (a) are evaluated
conditionally based on runtime state, or (b) modify and
are in turn modified by runtime state, decorators as
mutable environments or with true side effects make a
mess of that."
So presumably you would like the decoration mechanism
to prevent, or at least discourage, decorators that
"modify and are in turn modified by runtime state".
But at the implementation level, *everything* in Python
is runtime state. Changing a function's docstring is a
modification of runtime state. Presumably, then, you have
some more abstract notion of what is "runtime state" and
what isn't. But I can't tell what it is. Can you explain?
--
g
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4