[Python-Dev] Please reject or postpone PEP 526 (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Fri Sep 2 13:10:24 EDT 2016

I agree about some concerns and disagree about several. I see most use for class/instance attribute annotations, both for type checking and for other uses. I'm least sure about their syntax and about annotations in functions or at module level in the proposed form.

Below some comments:

On Fri, Sep 2, 2016 at 4:47 PM, Mark Shannon <mark at hotpy.org> wrote:

Hi everyone,

I think we should reject, or at least postpone PEP 526. PEP 526 represents a major change to the language, however there are, I believe, a number of technical flaws with the PEP.

[...]

In many cases it makes it more effort than type comments ======================================================== Type hints should be as easy to use as possible, and that means pushing as much work as possible onto the checker, and not burdening the programmer. Attaching type hints to variables, rather than expressions, reduces the potential for inference. This makes it harder for programmer, but easier for the checker, which is the wrong way around.

The more you infer types, the less you check them. It's up to the programmers to choose the amount of annotation.

For example,, given a function: def spam(x: Optional[List[int]])->None: ...

With type comments, this is intuitively correct and should type check: def eggs(cond:bool): if cond: x = None else: x = [] # type: List[int] spam(x) # Here we can infer the type of x With PEP 526 we loose the ability to infer types. def eggs(cond:bool): if cond: x = None # Not legal due to type declaration below else: x: List[int] = [] spam(x)

I'm also a little worried about not being able to reannotate a name.

So we need to use a more complex type def eggs(cond:bool): x: Optional[List[int]] if cond: x = None # Now legal else: x: = [] spam(x)

A good checker should be able to infer that x is a union type at the point that it's passed to spam, even without the type annotation. For example:

def eggs(cond:bool): if cond: x = 1 else: x = 1.5 spam(x) # a good type checker infers that x is of type Union[int, float]

Or with annotations:

def eggs(cond:bool): if cond: x : int = foo() # foo may not have a return type hint else: x : float = bar() # bar may not have a return type hint spam(x) # a good type checker infers that x is of type Union[int, float]

[...]

It limits the use of variables ==============================

In Python a name (variable) is just a binding that refers to an object. A name only exists in a meaningful sense once an object has been assigned to it. Any attempt to use that name, without an object bound to it, will result in a NameError.

IIUC, that would still be the case after PEP 526.

[...]

We should be free to add extra variables, whenever we choose, for clarity. For example, total = foo() - bar() should not be treated differently from: revenue = foo() tax = bar() total = revenue - tax If types are inferred, there is no problem. However, if they must be declared, then the use of meaningfully named variables is discouraged.

Who says they must be declared?

[...]

It is premature ===============

There are still plenty of issues to iron out w.r.t. PEP 484 types. I don't think we should be adding more syntax, until we have a precise idea of what is required. PEP 484 states: "If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version." Has it proved useful in general? I don't think it has. Maybe it will in future, but it hasn't yet.

Yeah, I hope someone has enough experience to know whether this is the right thing for Python as a whole.

It seems confused about class attributes and instance attributes ================================================================

The PEP also includes a section of how to define class attributes and instance attributes. It seems that everything needs to be defined in the class scope, even it is not an attribute of the class, but of its instances. This seems confusing, both to human reader and machine analyser.

I don't see the problem here, isn't that how it's usually done in strongly typed languages? And methods are defined in the class scope too (well yes, they do also exist in the class namespace, but anyway...).

But I agree in the sense that the proposed syntax is far from explicit about these being instance attributes by default.

Example from PEP 526:

class Starship: captain: str = 'Picard' damage: int stats: ClassVar[Dict[str, int]] = {} def init(self, damage: int, captain: str = None): self.damage = damage if captain: self.captain = captain # Else keep the default With type hints as they currently exist, the same code is shorter and doesn't contaminate the class namespace with the 'damage' attribute.

IIUC, 'damage' will not be in the class namespace according to PEP 526.

class Starship:

captain = 'Picard' stats = {} # type: Dict[str, int] def init(self, damage: int, captain: str = None): self.damage = damage # Can infer type as int if captain: self.captain = captain # Can infer type as str

And that's one of the reasons why there should be annotations without setting a type hint (as I wrote in the other thread).

This isn't an argument against adding type syntax for attributes in general, just that the form suggested in PEP 526 doesn't seem to follow Python semantics. One could imagine applying minimal PEP 526 style hints, with standard Python semantics and relying on type inference, as follows: class Starship: captain = 'Picard' stats: Dict[str, int] = {} def init(self, damage: int, captain: str = None): self.damage = damage if captain: self.captain = captain

I don't like this, because some of the attributes are introduced at class level and some inside init, so it is easy to miss that there is such a thing as 'damage' (at least in more complicated examples). I keep repeating myself, but again this where we need non-type-hinting attribute declarations.

-- Koos

The PEP overstates the existing use of static typing in Python ============================================================== [...] Please don't turn Python into some sort of inferior Java. There is potential in this PEP, but in its current form I think it should be rejected. Cheers, Mark.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com

--

More information about the Python-Dev mailing list