23 сент. 2016 г. 20:00 пользователь <python-ideas-request@python.org>
написал:
Send Python-ideas mailing list submissions to
python-ideas@python.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-ideas
or, via email, send a message with subject or body 'help' to
python-ideas-request@python.org
You can reach the person managing the list at
python-ideas-owner@python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-ideas digest..."
Today's Topics:
1. Re: Delay evaluation of annotations (Chris Angelico)
---------- Пересылаемое сообщение ----------
From: Chris Angelico <rosuav@gmail.com>
To: python-ideas <python-ideas@python.org>
Cc:
Date: Sat, 24 Sep 2016 01:58:59 +1000
Subject: Re: [Python-ideas] Delay evaluation of annotations
On Fri, Sep 23, 2016 at 11:58 PM, אלעזר <elazarg@gmail.com> wrote:
What other context you see where the result of an expression is not
to be used at all? Well there's Expression statements, which are
evaluated
for side effect. There's docstrings, which are a kind of annotations.
What
else? The only other that comes to mind is reveal_type(exp)... surely I
don't need evaluation there.
Function annotations ARE used. They're stored as function attributes,
just as default argument values and docstrings are. (It's not the
language's problem if you never use them.)
The PEP that introduced them describes them as expressions:
Syntactically, yes. Just like X in "a = lambda: X" is an expression,
but you
don't see it evaluated, do you? And this is an _actual_ expression,
undeniably so, that is intended to be evaluated and used at runtime.
And the X in "if False: X" is a statement, but you don't see it
evaluated either. This is an actual expression that has to be
evaluated and used just like any other does.
I think its time to give up arguing that annotations aren't
expressions.
I don't care if you call them expressions, delayed-expressions, or
flying
monkeys. The allowed syntax is exactly that of an expression (like
inside a
lambda). The time of binding of names to scope is the same (again like a
lambda) but the evaluation time is unknown to the
non-reflecting-developer.
Decorators may promise time of evaluation, if they want to.
Thing is, literally every other expression in Python is evaluated at
the point where it's hit. You can guard an expression with control
flow statements or operators, but other than that, it will be hit when
execution reaches its line:
def func(x):
expr # evaluated when function called
if cond:
expr # evaluated if cond is true
[expr for x in range(n)] # evaluated if n > 0
(expr for x in [1]) # evaluated when genexp nexted
expr if cond else "spam" # evaluated if cond is true
lambda: expr # evaluated when function called
def func(x=expr): pass # evaluated when function defined
def func(x: expr): pass # evaluated when function defined
Default arguments trip some people up because they expect them to be
evaluated when the function's called, but it can easily be explained.
Function annotations are exactly the same. Making them magically
late-evaluate would have consequences for the grokkability of the
language - they would be special. Now, that can be done, but as
Rumplestiltskin keeps reminding us, all magic comes with a price, so
it has to be strongly justified. (For instance, the no-arg form of
super() is most definitely magical, but its justification is obvious
when you compare Py2 inheritance with Py3.)
"Unknown evaluation time" is scary. _for expressions_, which might have
side
effects (one of which is running time). But annotations must be pure by
convention (and tools are welcome to warn about it). I admit that I
breaking the following code:
def foo(x: print("defining foo!")): pass
Do you know anyone who would dream about writing such code?
Yes, side effects make evaluation time scary. But so do rebindings,
and any other influences on expression evaluation. Good, readable code
generally follows the rule that the first instance of a name is its
definition. That's why we put imports up the top of the script, and so
on. Making annotations not work that way isn't going to improve
readability; you'd have to search the entire project for the class
being referenced. And since you can't probe them at definition time,
you have to wait until, uhh, SOME time, to do that search - you never
know where the actual name binding will come from. (It might even get
injected from another file, so you can't statically search the one
file.)
You want to make them fancy, give them super-powers, in order to solve
the forward reference problem. I don't think that the problem is
serious
enough to justify changing the semantics of annotation evaluation and
make them non-standard, fancy, lazy-evaluated expressions.
My proposal solves the forward reference problem, but I believe in it
because I believe it is aligned with what the programmer see.
This is on par with a proposal to make default argument values
late-bind, which comes up every now and then. It's just not worth
making these expressions magical.
class MyClass:
pass
def function(arg: MyCalss):
...
I want to see an immediate NameError here, thank you very much
Two things to note here:
A. IDEs will point at this NameError
Some or them might. Not everyone uses an IDE, it is not a requirement
for Python programmers. Runtime exceptions are still, and always will
be, the primary way of detecting such errors.
How useful is the detection of this error at production?
The sooner you catch an error, the better. Always.
Can you repeat that? NameError indeed happens at runtime, but the scope
in
which MyCalss was looked up for is determined at compile time - as far
as I
know. The bytecode-based typechecker I wrote rely on this information
being
accessible statically in the bytecode.
def foo():
locals()['MyType'] = str
def bar(a : MyType): pass
foo()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in foo
NameError: name 'MyType' is not defined
What do I miss?
That locals() is not editable (or rather, that mutations to it don't
necessarily change the actual locals). This is equivalent to:
def foo():
locals()['MyType'] = str
print(MyType)
foo()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in foo
NameError: name 'MyType' is not defined
In each case, you have to *call* foo() to see the NameError. It's
happening at run time.
This way or the other, the very least that I hope, is explicitly
forbidding
reliance on side-effect or any other way to distinguish evaluation time
of
annotation expressions. Annotations must be pure, and the current
evaluation time should be deprecated.
Define "pure". Function decorator syntax goes to some lengths to
ensure that this is legal:
@deco(arg)
def f(): pass
PEP 484 annotations include subscripting, even nested:
def inproduct(v: Iterable[Tuple[T, T]]) -> T:
so you'd have to accept some measure of run-time evaluation.
It's worth reiterating, too, that function annotations have had the
exact same semantics since Python 3.0, in 2008. Changing that now
would potentially break up to eight years' worth of code, not all of
which follows PEP 484. When Steve mentioned 'not breaking other uses
of annotations', he's including this large body of code that might
well not even be visible to us, much less under python.org control.
Changing how annotations get evaluated is a *major, breaking change*,
so all you can really do is make a style guide recommendation that
"annotations should be able to be understood with minimal external
information" or something.
Additionally, before making it impossible to go back, we should make
intended
propose
promise of
the new
variable annotation syntax add its annotations to a special object
__reflect__, so that __reflect__.annotations__ will allow forcing
evaluation
(since there is no mechanism to do this in a variable).
Wow, lots of magic needed to make this work. Here's my
counter-proposal. In C++, you can pre-declare a class like this:
class Mutual2; //Pre-declare Mutual2
class Mutual1 {
Mutual2 *ptr;
};
class Mutual2 {
Mutual1 *ptr;
}
Here's how you could do it in Python:
Mutual2 = "Mutual2" # Pre-declare Mutual2
class Mutual1:
def spam() -> Mutual2: pass
class Mutual2:
def spam() -> Mutual1: pass
Problem solved, no magic needed.
ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Святослав Молодских