PEP 0526 -- variable declarations (#70)
This PEP is *not* ready for review! This commit is just to claim the PEP number.
This commit is contained in:
parent
e7f539fb87
commit
82fbafb118
|
@ -0,0 +1,57 @@
|
|||
PEP: 526
|
||||
Title: Variable Declaration Syntax
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: Ryan Gonzalez <rymg19@gmail.com>, Philip House <phouse512@gmail.com>, Guido van Rossum <guido@python.org>
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 09-Aug-2016
|
||||
Python-Version: 3.6
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
PEP 484 introduced type hints and; In particular, it introduced the notion of
|
||||
type comments::
|
||||
|
||||
# a is specified to be a list of ints.
|
||||
a = [] # type: List[int]
|
||||
# b is a string
|
||||
b = None # type: str
|
||||
class Cls:
|
||||
my_class_attr = True # type: bool
|
||||
|
||||
This PEP aims at adding syntax to Python for declaring the types of variables and
|
||||
attributes, instead of expressing them through comments::
|
||||
|
||||
a: List[int] = []
|
||||
b: str
|
||||
class Cls:
|
||||
my_class_attr: ClassAttr[bool] = True
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
Although type comments work well, the fact that they're expressed through
|
||||
comments has some downsides:
|
||||
|
||||
- Text editors often highlight comments differently from type declarations.
|
||||
- There isn't a way to declare the type of an undefined variable; you need to
|
||||
initialize it to ``None`` (e.g. ``a = None # type: int``).
|
||||
- Variables declared in a conditional branch are difficult to read::
|
||||
|
||||
if some_value:
|
||||
my_var = function() # type: Logger
|
||||
else:
|
||||
my_var = another_function() # Why isn't there a type here?
|
||||
|
||||
- Since type comments aren't actually part of the language, if a Python script
|
||||
wants to parse them, it would require a custom parser instead of just using
|
||||
``ast``.
|
||||
- It's impossible to retrieve the annotations at runtime outside of attempting to
|
||||
find the module's source code and parse it at runtime, which is inelegant, to
|
||||
say the least.
|
||||
|
||||
The majority of these issues can be alleviated by making the syntax a core part of
|
||||
the language.
|
Loading…
Reference in New Issue