...

Thanks for the write-up Sully. Two quick questions:

1. what’s the rationale for prohibiting `Final` in loops? I have a hunch this has to do with Python leaking scopes but not entirely sure. IIRC this is fine in Java.

In some sense yes. The point is that Python cycles don't create a separate scope, they just live entirely in the enclosing scope.

Pyre diverges from the runtime here in that we don't allow variables to escape the scope of conditionals and loops. Would appreciate it if we could adapt the PEP to allow for that behavior.

...

2.

...

Type checkers should infer a final attribute that is initialized in a class body as being a class variable. Variables should not be annotated with both ClassVar and Final.

I’m probably missing something here but why not support something like `attribute: ClassVar[Final[int]]`? Isn’t this conflating two unrelated concepts?

The point here is that according to PEP 526 ClassVar is something that can't be _set_ on instances (only on class object itself). While it still can be _accessed_ on instances. So they are not entirely orthogonal, if something is `Final` (can't be set neither on instance nor on class) there is no point in annotating it as a ClassVar.

Haven't looked at class variables that way before. That makes sense. Thanks for the explanation.

On Tue, May 7, 2019 at 10:08 AM Guido van Rossum wrote:

On Tue, May 7, 2019 at 1:01 PM Dominik Gabi wrote:

...

...

...

1. what’s the rationale for prohibiting `Final` in loops? I have a hunch this has to do with Python leaking scopes but not entirely sure. IIRC this is fine in Java.

In some sense yes. The point is that Python cycles don't create a separate scope, they just live entirely in the enclosing scope.

Pyre diverges from the runtime here in that we don't allow variables to escape the scope of conditionals and loops. Would appreciate it if we could adapt the PEP to allow for that behavior.

That sounds like youre deviating from expected behavior of the interpreter, and if you disagree with the interpreter about this, you are welcome to also disagree with this PEP about placement of Final. IOW I don't think the PEP should endorse this deviation.

-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?)

We all diverge from the expected behavior of the interpreter by constraining dynamic behavior that we deem unsafe. E.g. mypy will not support dynamic subclassing. We clearly draw the line here differently but I don't see why the PEP should not be able to accommodate both.

I would simply remove the loop example from the PEP. I agree with the general definition that

There must be exactly one assignment to a final name.

In Pyre this is guaranteed to hold even if you have a final in a loop. In Mypy it’s not and therefore the error from the example makes sense for your particular implementation but not for ours. From: Guido van Rossum Reply-To: "guido@python.org" Date: Tuesday, May 7, 2019 at 10:28 AM To: Dominik Gabi Cc: Ivan Levkivskyi , Michael Sullivan , "typing-sig@python.org" Subject: Re: [Typing-sig] Re: PEP 591 discussion: final What words would you put in the PEP? I would not accept anything that makes mypy not in compliance. OTOH if Pyre supports Final in a for loop, it is still in compliance — only a program that uses that isn’t. On Tue, May 7, 2019 at 13:20 Dominik Gabi mailto:dkgispam@gmail.com> wrote: On Tue, May 7, 2019 at 10:08 AM Guido van Rossum mailto:guido@python.org> wrote:

On Tue, May 7, 2019 at 1:01 PM Dominik Gabi mailto:dkgispam@gmail.com> wrote:

...

...

...

1. what’s the rationale for prohibiting `Final` in loops? I have a hunch this has to do with Python leaking scopes but not entirely sure. IIRC this is fine in Java.

In some sense yes. The point is that Python cycles don't create a separate scope, they just live entirely in the enclosing scope.

Pyre diverges from the runtime here in that we don't allow variables to escape the scope of conditionals and loops. Would appreciate it if we could adapt the PEP to allow for that behavior.

That sounds like youre deviating from expected behavior of the interpreter, and if you disagree with the interpreter about this, you are welcome to also disagree with this PEP about placement of Final. IOW I don't think the PEP should endorse this deviation.

-- --Guido van Rossum (python.org/~guidohttp://python.org/~guido) Pronouns: he/him/his (why is my pronoun here?)

We all diverge from the expected behavior of the interpreter by constraining dynamic behavior that we deem unsafe. E.g. mypy will not support dynamic subclassing. We clearly draw the line here differently but I don't see why the PEP should not be able to accommodate both. -- --Guido (mobile)

On Tue, May 7, 2019 at 12:54 PM Guido van Rossum wrote:

On Tue, May 7, 2019 at 2:30 PM Dominik Gabi wrote:

...

I would simply remove the loop example from the PEP.

OK, but words should be added that a compliant type checker need not allow Final declarations in loops (with the explanation that the Python runtime sees this as multiple assignments to a single variable).

That sounds reasonable to me.

...

I agree with the general definition that

...

There must be exactly one assignment to a final name.

In Pyre this is guaranteed to hold even if you have a final in a loop. In Mypy it’s not and therefore the error from the example makes sense for your particular implementation but not for ours.

Agreed.

-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?)