Skip to content

Consider a refinement for class variable declarations #209

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gvanrossum opened this issue Apr 29, 2016 · 3 comments
Closed

Consider a refinement for class variable declarations #209

gvanrossum opened this issue Apr 29, 2016 · 3 comments

Comments

@gvanrossum
Copy link
Member

In mypy we are proposing to implement strict Optional checking per PEP 484, with one exception.

python/mypy#1450

The one exception will be in the case of instance variables defined in the class body. These variables may be assigned None while having a non-Optional type, provided that they are initialized to a non-None value by the end of __init__. They may be initialized in __init__ itself, or in any method on self that __init__ calls, or in __new__. Mypy will not check these variables for use before assignment to a non-None value in __init__ or called methods, though it may make sense to add that at some point in the future.

The purpose of this exception is to allow variables to be typed in a common place rather than scattered around __init__.

I think this is a good idea and we should update PEP 484 to follow this.

@gvanrossum
Copy link
Member Author

Hey, did you delete your comment or is there a GitHub glitch? I can't see
it on the website.

On Thu, May 5, 2016 at 8:56 PM, Caleb Jones [email protected]
wrote:

I saw on #1450 there was some concern about writing code that relied on
control flow analysis; this seems like exactly the sort of rule that would
require control flow analysis to do correctly.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#209 (comment)

--Guido van Rossum (python.org/~guido)

@porglezomp
Copy link

porglezomp commented May 6, 2016

I deleted it since it wasn't really relevant to the specification of the types, it was more an implementation concern that I don't think its relevant concern here, since other typing features already require it.

@gvanrossum
Copy link
Member Author

I'm closing this; it looks like the PEP already has the right words:

In non-stub code, there is a similar special case::

  from typing import IO

  stream = None  # type: IO[str]

Type checkers should not complain about this (despite the value
None not matching the given type), nor should they change the
inferred type to Optional[...] (despite the rule that does this
for annotated arguments with a default value of None). The
assumption here is that other code will ensure that the variable is
given a value of the proper type, and all uses can assume that the
variable has the given type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants