
PEP 526: Variable declaration in Python - steinsgate
https://www.python.org/dev/peps/pep-0526/
======
alanfranzoni
Bah. If you want a statically typed language, get a statically typed language.

What's a type hint for if, after that, the user can actually pass a different
type?

~~~
junke
A type checker for Python can say: _" pass"_, _" reject"_ or _" I don't
know"_.

Statically typed languages (1) introduce limitations so that type checking is
decidable (no incertitude), or (2) or treat _" don't know"_ as _" reject"_,
because the runtime has practically no knowledge of type. This is not the case
in Python, so you don't _have_ to check everything. That does not mean you
shouldn't check anything.

So there are still benefits in Python to have type in order to "reject" code
that is undoubtedly going to produce type errors at runtime (or maybe to
optimize things). In case of uncertainty, you know the runtime is going to
catch errors anyway (including type errors).

~~~
KayEss
For structurally typed languages you really want something like C++'s concepts
so you can talk about `Iterable[str]` rather than forcing it to `List[str]`.
Is this possible with Python's type annotations?

~~~
junke
I don't know exactly for Python. I would expect mixin class to be used for
this. Also, maybe Python will allow you to define union types: e.g. X is
either a "foo", a "bar" or a "zot" (all of them duck types the same implicit
interface).

~~~
raverbashing
And that's why it's bad. Let's throw something useful (duck typing) out of the
window to please the Java people

I'm sincerely disgusted

~~~
junke
> Let's throw something useful (duck typing)

Not sure why you say this is throwing away duck typing, you just don't add a
type hint and you continue working as usual.

> I'm sincerely disgusted

I can sympathize, most of the time when there is a talk about Lisp there is a
guy who comes just to say "dynamic typing is _bad_ ", etc. Well, even though
there are definitely static analyzers for Lisp (see
[https://news.ycombinator.com/item?id=12216701](https://news.ycombinator.com/item?id=12216701)),
the language is still the same and doesn't prevent anyone from using dynamic
features. People who really want statically typed programs won't touch Python
anyway so I don't think you have much to worry.

------
raverbashing
Yeah, it seems it's time to abandon Python since the static typing
fundamentalists seem to be getting hold of it

Extremely frustrated by this decision and even though the multiple denials
that it won't become a statically typed language it's clear that idea has
changed

~~~
Alphasite_
What's wrong with optional typing? All it does is formalise docstrings into an
integrated syntax.

~~~
icebraining
Docstrings are for modules, classes, functions and methods, not variables
mixed with the code.

And "optional" is a misnomer unless you only ever touch your own code.
Programming is generally a social activity, so for most of us, "optional"
means just means "inconsistently required".

I don't have a philosophical objection to typing, but I'm yet to see a syntax
that won't muddy Python's.

~~~
geezerjay
> And "optional" is a misnomer unless you only ever touch your own code.
> Programming is generally a social activity, so for most of us, "optional"
> means just means "inconsistently required".

Optionally means that it's not required or mandatory.

You don't need to use it if you don't want to. If you're working on a project
and the project follows a style guide then you follow the style guide, but
nothing forces your bosses to require it. The code will run anyway.

~~~
icebraining
That's great for my bosses. I'm not my bosses, though, at least as yet.

~~~
geezerjay
It isn't good or bad. It's an optional feature. No one is forced to use it
unless they specifically want it.

Your bosses aren't forced to use it. This means that if they don't want to use
them and they don't believe the official style guide has to impose them, you
don't have to use them.

If your bosses decide to impose them and change teh official style guide to
require type annotation then your personal taste doesn't have any say in the
subject either way, and you only need to act like a professional and be a team
player.

But the key issue is that no one is forced to use optional features unless
they really want to.

------
haney
I see a ton of comments that are dismissing this but from my experience most
code has implicit typing of some sort. This looks like a nice replacement for
hand written input validation, if my function expects a number and I pass a
string there are 3 options AFAIK:

1) I have the ability to define a type that's required so that the function
can't be called without a numeric type.

2) I add boiler plate the the top of my function to validate that I'm
receiving a number.

3) I forget to do 1 or 2 and I get a runtime error when a different developer
inadvertently passes an incorrect type to my function.

------
berntb
Where typing is really useful, in my experience, is in an external API.

Most heavily used libraries in most dynamic languages, not only Python, ought
to have assertions with type checks for parameters. In the external API calls
to the lib.

Inside of a lib you should have tests anyway, so type declarations shouldn't
be important.

------
toyg
A very sad day. We were told type hints were just that, optional hints to help
IDEs and such. Now they're creeping into the language proper; IDEs will start
adding them for you, and before you know it all "serious codebases" will be
statically typed.

The beauty of python was that it could read like pseudocode; more and more
special characters and notations are putting that idea to rest. I guess it's
the price to pay for mainstream success -- when banks get involved, everything
becomes uber-formal and soul-crushing.

~~~
dozzie
> [...] before you know it all "serious codebases" will be statically typed.

And this is bad because...?

~~~
toyg
because they will lose readability and raise the bar for contribution from
novices. Every extra feature you add to the language requires extra effort to
read and extra effort from novices to understand.

~~~
2T1Qka0rEiPr
@dozzie, I don't think static typing does make it easier to read, it makes it
more verbose.

~~~
catnaroek
Are you confusing “static typing” with “type annotations”? You can write large
swathes of statically typed code without a single type annotation, in
languages with proper type inference. This is 70's-era technology, mind you.

~~~
2T1Qka0rEiPr
You're right, I'm conflating the two, though I appreciate that one doesn't
require the other.

------
RodericDay
Where can we voice our opposition to this?

If people really want their bulky IDEs to give them maximum help when
introspecting a codebase, there should just be a TypeScript like superset of
Python that those people can use.

This syntax is awful and will seriously cause antagonism in terms of what
people consider "pythonic" and "good code".

~~~
bakery2k
_Where can we voice our opposition to this?_

[https://github.com/python/typing/issues/258](https://github.com/python/typing/issues/258)

------
rilut
Why [T]? Why not <T>? It confuses with array selection

~~~
sametmax
I imagine it's to avoid to change too much the parser. [] is already used to
enclosed stuff, while < and > are operators.

------
webjunkie
Why not the other way around:

    
    
        my_class_attr = ClassAttr[bool]: True
    

This seems more familiar somehow.

~~~
talideon
A few reasons, not least of which is consistency with function/method
signature declarations.

Also, that style is only more familiar if you're coming from C, C++, Java, &c.
However, the style in the PEP is pretty common in languages outside of the C
family, such as those inspired by Pascal, and there's at least two examples of
C family languages - Go and Swift - which use the style in the PEP.

Also, putting the declaration on the LHS likely results in fewer grammar
ambiguities, but it's well over a decade since I last looked at Python's
grammar, so that's just speculation on my part. I know that's one of the
reasons why Swift and Go went down the route they did, and Python would have
even more reason, given how ':' is used in the language.

------
denfromufa
I wish mypy, cython, and numba type annotations converge to something common.

------
w8rbt
Do the hints increase performance at all? I would think they could.

~~~
denfromufa
For performance we have cython and numba

------
super_mario
This is why Python 2.7 will just continue indefinitely.

------
crdoconnor
That's a lot of extra character overhead for not very much gain.

~~~
talideon
It means that static analysis tools can do a much better job of finding issues
in code, and will make code completion much better. I've worked on some pretty
big Python codebases in my years, and both of those would be big wins.
Currently people do the same thing in a much more janky and inconsistent way
in docstrings.

~~~
crdoconnor
Of the the large python code bases I've worked on (4 at current count), type
errors have tended to account for a small proportion (around 4-8%) of
production issues.

If this feature came at relatively little cost this would be great - 5% of
bugs squashed just like that. It doesn't. It contributes significantly to the
verbosity of the code - chipping away at one of python's main strengths -
concision and clarity.

~~~
geezerjay
> Of the the large python code bases I've worked on (4 at current count), type
> errors have tended to account for a small proportion (around 4-8%) of
> production issues.

Some projects are more than eager to cut up to 8% of potential bugs with such
a trivial change.

>If this feature came at relatively little cost this would be great - 5% of
bugs squashed just like that. It doesn't. It contributes significantly to the
verbosity of the code - chipping away at one of python's main strengths -
concision and clarity.

I'm not sure you're being serious. Stating a type in a variable declaration
doesn't harm concision, and obviously it does exactly the opposite of what you
claim regarding clarity.

~~~
crdoconnor
>Some projects are more than eager to cut up to 8% of potential bugs with such
a trivial change.

Except it's not trivial, it's not 'free' \- it adds noise to the code base and
the idea it will eliminate all typing bugs is ludicrous.

>Stating a type in a variable declaration doesn't harm concision

Java is a good example of language that has explicit type declarations for
every variable. That's one of the reasons why the average Java program is 2x
as long as an equivalent python program.

> obviously it does exactly the opposite of what you claim regarding clarity.

No, not obviously. Are Java programs easier to read than python thanks to
their explicit variable declarations and tendency towards verbosity?

~~~
geezerjay
> Except it's not trivial, it's not 'free' \- it adds noise to the code base
> and the idea it will eliminate all typing bugs is ludicrous.

Except it is trivial. Just add the type declaration like it says in the PEP.
There. Problem solved. Who in their right mind makes a fuss for such a trivial
thing?

> That's one of the reasons why the average Java program is 2x as long as an
> equivalent python program.

That's a ridiculous thing to say, and is entirely oblivious to the issue of
boilerplate code that is mandatory in Java.

> No, not obviously. Are Java programs easier to read than python thanks to
> their explicit variable declarations and tendency towards verbosity?

You're trying to misrepresent a personal (and miss-guided) opinion that you
formed on a particular programming language as being representative of a
single issue.

If your argument was sound and remotely rational, you would've pointed
something in the PEP to discuss the merits of the PEP. Instead, you invent
problems where there are none by making up stuff regarding an entirely
different programming language.

It sounds like you're very opinionated about something you clearly have no
ground to criticize or comment on. Therefore it's pointless to continue with
this discussion.

~~~
crdoconnor
>Except it is trivial. Just add the type declaration like it says in the PEP.

For every single variable declaration. This will increase the length of your
program.

>That's a ridiculous thing to say,

Are you asserting that program length will not go up when adding explicit
types? That seems a peculiarly indefensible position.

>You're trying to misrepresent a personal (and miss-guided) opinion that you
formed on a particular programming language as being representative of a
single issue.

Lack of verbosity is one of python's main strengths.

>If your argument was sound and remotely rational, you would've pointed
something in the PEP to discuss the merits of the PEP.

Which I did which you would have picked up on _if you were remotely reading
what I was actually saying_ : it picks up type errors that would otherwise not
be caught.

It does that at a _cost_ : longer code that does the same thing.

You seem to fail to understand that this is a _trade off_.

> Therefore it's pointless to continue with this discussion.

Agree about that.

