7 ms·

PEP 526: Variable declaration in Python

48 points by steinsgate 10y ago

raverbashing 10y ago
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_ 10y ago
  What's wrong with optional typing? All it does is formalise docstrings into an integrated syntax.
  - raverbashing 10y ago
    It's a slippery slope People will start using and it will become mandatory at some point
    - Desustorm 10y ago
      I can see the medium post now! "Dynamically typed Python variables considered harmful"
  - mvdwoord 10y ago
    As long as it remains optional I'm all for it.
  - icebraining 10y ago
    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 10y ago
      > 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 10y ago
        That's great for my bosses. I'm not my bosses, though, at least as yet.
        geezerjay 10y ago
        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.
  - 2T1Qka0rEiPr 10y ago
    It does seem odd that a module could be partially static. If it was optional I'd prefer to see it enabled by a different filetype (e.g. pys, heh piss).
  - MollyR 10y ago
    It's optional until the lead developer at work forces you to use it.
    - Alphasite_ 10y ago
      Currently they can force you to use a docstring with types, how is that any different?
      - icebraining 10y ago
        Docstrings are not as interspersed with the code.
- dozzie 10y ago
  > Yeah, it seems it's time to abandon Python since the static typing fundamentalists seem to be getting hold of it. It seems it's time to abandon Erlang since static typing fundamentalists seem to be getting hold of it, with its typespecs and Dialyzer. Oh wait, it's still dynamically typed.
  - raverbashing 10y ago
    Dialyzer seems to be Erlang's Pylint (which does type analysis but still lets you do dynamic typing) And I'm all for Pylint, it also proves type hints are not needed for this kind of type analysis
    - dozzie 10y ago
      Well, sort of. Dialyzer can do quite well if you run it on code with no typespecs whatsoever, but if you add those, it can detect so many more mistakes (which is the whole point of such tools). No typespecs feels like crippling the tool, except it was designed to be as useful as possible for old code without modifying it. It just shows how useful the typespecs are.
- michaelhoffman 10y ago
  No decision yet, this PEP is a draft. Anyone can propose one.
  - ghshephard 10y ago
    Check the author list.
    - michaelhoffman 10y ago
      Didn't notice that.
crdoconnor 10y ago
That's a lot of extra character overhead for not very much gain.
- talideon 10y ago
  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 10y ago
    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 10y ago
      > 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 10y ago
        >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?
webjunkie 10y ago
Why not the other way around: my_class_attr = ClassAttr[bool]: True This seems more familiar somehow.
- talideon 10y ago
  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.
toyg 10y ago
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 10y ago
  > [...] before you know it all "serious codebases" will be statically typed. And this is bad because...?
  - toyg 10y ago
    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.
    - dozzie 10y ago
      >>> [...] before you know it all "serious codebases" will be statically typed. > because they will lose readability and raise the bar for contribution from novices OK, hold for a second. Adding something to make the code easier to follow will make code harder to follow? Is this really your argument? And why would a novice to a language want to contribute to "serious codebase"? I don't think Django, Jinja, or NumPy are popular for Python novices to contribute code.
    - yedpodtrzitko 10y ago
      "Readability" depends on a context. I've worked with a huge codebases where having a variable types attached to the variables there would actually improve the readability. Sure, it would take you a moment longer to skim the line, but overall it would save you a much more time to figure out what's the variable about.
deleted 10y ago
[deleted]
rilut 10y ago
Why [T]? Why not <T>? It confuses with array selection
- sametmax 10y ago
  I imagine it's to avoid to change too much the parser. [] is already used to enclosed stuff, while < and > are operators.
- userbinator 10y ago
  Just to be different (see the ternary operator for a past example)? And <T> confuses with the comparison operators.
alanfranzoni 10y ago
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?
- RubyPinch 10y ago
  for documentation
- IshKebab 10y ago
  IDE code completion and linting, which is admittedly an area where Python sucks. But I'm inclined to agree. It's a little too to add static typing to Python. You're just going to end up with something far worse than a language that was designed with it in mind, like Ceylon or Go.
  - JustSomeNobody 10y ago
    Python is a language where I simply don't miss code completion.
    - IshKebab 10y ago
      Why not? Code completion is definitely useful in Python (when it works, which is rarely). It saves time looking up documentation.
      - JustSomeNobody 10y ago
        I find I can keep most things I currently need in my head with Python. Which is nice as some IDEs tend to offer code completion popups OVER the line I'm typing which is very annoying and breaks my thought process. Also, for _me_, not using code completion helps me think more about what I'm actually doing and not code so much on autopilot. I actually write much better, succinct code without completion. YMMV
        10y ago
berntb 10y ago
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.
w8rbt 10y ago
Do the hints increase performance at all? I would think they could.
- denfromufa 10y ago
  For performance we have cython and numba
denfromufa 10y ago
I wish mypy, cython, and numba type annotations converge to something common.
super_mario 10y ago
This is why Python 2.7 will just continue indefinitely.
RodericDay 10y ago
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 10y ago
  Where can we voice our opposition to this? https://github.com/python/typing/issues/258 https://github.com/python/typing/issues/258
haney 10y ago
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.

48 points by steinsgate 10y ago

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_ 10y ago
What's wrong with optional typing? All it does is formalise docstrings into an integrated syntax.
- raverbashing 10y ago
  It's a slippery slope People will start using and it will become mandatory at some point
  - Desustorm 10y ago
    I can see the medium post now! "Dynamically typed Python variables considered harmful"
- mvdwoord 10y ago
  As long as it remains optional I'm all for it.
- icebraining 10y ago
  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 10y ago
    > 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 10y ago
      That's great for my bosses. I'm not my bosses, though, at least as yet.
      - geezerjay 10y ago
        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.
- 2T1Qka0rEiPr 10y ago
  It does seem odd that a module could be partially static. If it was optional I'd prefer to see it enabled by a different filetype (e.g. pys, heh piss).
- MollyR 10y ago
  It's optional until the lead developer at work forces you to use it.
  - Alphasite_ 10y ago
    Currently they can force you to use a docstring with types, how is that any different?
    - icebraining 10y ago
      Docstrings are not as interspersed with the code.
dozzie 10y ago
> Yeah, it seems it's time to abandon Python since the static typing fundamentalists seem to be getting hold of it. It seems it's time to abandon Erlang since static typing fundamentalists seem to be getting hold of it, with its typespecs and Dialyzer. Oh wait, it's still dynamically typed.
- raverbashing 10y ago
  Dialyzer seems to be Erlang's Pylint (which does type analysis but still lets you do dynamic typing) And I'm all for Pylint, it also proves type hints are not needed for this kind of type analysis
  - dozzie 10y ago
    Well, sort of. Dialyzer can do quite well if you run it on code with no typespecs whatsoever, but if you add those, it can detect so many more mistakes (which is the whole point of such tools). No typespecs feels like crippling the tool, except it was designed to be as useful as possible for old code without modifying it. It just shows how useful the typespecs are.
michaelhoffman 10y ago
No decision yet, this PEP is a draft. Anyone can propose one.
- ghshephard 10y ago
  Check the author list.
  - michaelhoffman 10y ago
    Didn't notice that.

crdoconnor 10y ago

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

talideon 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      >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?

webjunkie 10y ago

Why not the other way around: my_class_attr = ClassAttr[bool]: True This seems more familiar somehow.

talideon 10y ago
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.

toyg 10y ago

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 10y ago
> [...] before you know it all "serious codebases" will be statically typed. And this is bad because...?
- toyg 10y ago
  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.
  - dozzie 10y ago
    >>> [...] before you know it all "serious codebases" will be statically typed. > because they will lose readability and raise the bar for contribution from novices OK, hold for a second. Adding something to make the code easier to follow will make code harder to follow? Is this really your argument? And why would a novice to a language want to contribute to "serious codebase"? I don't think Django, Jinja, or NumPy are popular for Python novices to contribute code.
  - yedpodtrzitko 10y ago
    "Readability" depends on a context. I've worked with a huge codebases where having a variable types attached to the variables there would actually improve the readability. Sure, it would take you a moment longer to skim the line, but overall it would save you a much more time to figure out what's the variable about.

deleted 10y ago

[deleted]

rilut 10y ago

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

sametmax 10y ago
I imagine it's to avoid to change too much the parser. [] is already used to enclosed stuff, while < and > are operators.
userbinator 10y ago
Just to be different (see the ternary operator for a past example)? And <T> confuses with the comparison operators.

alanfranzoni 10y ago

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?

RubyPinch 10y ago
for documentation
IshKebab 10y ago
IDE code completion and linting, which is admittedly an area where Python sucks. But I'm inclined to agree. It's a little too to add static typing to Python. You're just going to end up with something far worse than a language that was designed with it in mind, like Ceylon or Go.
- JustSomeNobody 10y ago
  Python is a language where I simply don't miss code completion.
  - IshKebab 10y ago
    Why not? Code completion is definitely useful in Python (when it works, which is rarely). It saves time looking up documentation.
    - JustSomeNobody 10y ago
      I find I can keep most things I currently need in my head with Python. Which is nice as some IDEs tend to offer code completion popups OVER the line I'm typing which is very annoying and breaks my thought process. Also, for _me_, not using code completion helps me think more about what I'm actually doing and not code so much on autopilot. I actually write much better, succinct code without completion. YMMV
      - 10y ago

berntb 10y ago

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.

w8rbt 10y ago

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

denfromufa 10y ago
For performance we have cython and numba

denfromufa 10y ago

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

super_mario 10y ago

This is why Python 2.7 will just continue indefinitely.

RodericDay 10y ago

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 10y ago
Where can we voice our opposition to this? https://github.com/python/typing/issues/258 https://github.com/python/typing/issues/258

haney 10y ago

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.