PEP 526: Variable declaration in Python
python.org
python.org
What's a type hint for if, after that, the user can actually pass a different type?
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.
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
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).
I'm sincerely disgusted
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), 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.
Type hinting would be ok for documentation only. But then, a comment is fine and introduces less clutter.
The warnings that are emitted by SBCL (Lisp implementation) are produced when two types don't intersect at all, something like "len(3)". There is no warning when types overlap. And even if the warning is issued, the code is still compiled and can run.
Which statically typed scripting language would you suggest instead of Python?
Would you like something that you can embed? Something that has an interpreter for?
https://en.wikipedia.org/wiki/Scripting_language
> Would you like something that you can embed? Something that has an interpreter for?
I asked about your personal preference regarding a statically typed alternative to Python. Can you propose one?
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
People will start using and it will become mandatory at some point
"Dynamically typed Python variables considered harmful"
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.
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.
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.
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.
And I'm all for Pylint, it also proves type hints are not needed for this kind of type analysis
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.
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.
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.
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.
And this is bad because...?
> 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.
You want Java you use Java. Oh it sucks? I wonder why...
Oh even better, you set a type, does it prevent you from using things with a similar interface? Like iterables in place of lists?
Better code documentation? Static analysis? Compare to Erlang with typespecs and Dialyzer.
> You want Java you use Java.
Why Java? Why not SML, OCaml, Haskell, Rust? Those are statically typed languages, too.
> Oh it [Java] sucks? I wonder why...
Because it's statically typed yet it's dynamically typed ("Object" class thing)? Because its type system is quite primitive and somewhat inconsent? Because it was designed for use in TV sets two dozens years ago, and has barely advanced as a language since then? (No, foreach loops and lambdas don't qualify as a significant step, those are merely syntax sugar.)
> Oh even better, you set a type, does it prevent you from using things with a similar interface? Like iterables in place of lists?
Type specification signifies code author's intent. This is a very good thing, and I want to see it much more in the code. I don't expect type specs/hints to do anything more for a dynamically typed language.
Developers on those languages usually don't push for crap like the Java developers do
And I don't want to use Rust or Haskell where Python can solve the problem just fine. Overhead and development time is also a problem
Type hints add development time and bureaucracy. The 80 columns limit was supposed to be a guidance as well but now it has become almost mandatory
Only for those whose pinnacle of programming editors are from a VT-100 era.
Because thinking and reading the first phrase of PEP 8 is too hard, cargo culting is easier.
> [...] I don't want to use Rust or Haskell where Python can solve the problem just fine. Overhead and development time is also a problem
Yet you suggested using Java. Something in your comments seems inconsistent.
> Type hints add development time and bureaucracy.
That's why they are (going to be) optional. But for larger codebases beaurocracy adds some structure, which can be beneficial.
BTW, did you know that beaurocracy was an invention of ancient times? Yes, an invention. It allowed citizens to know what to do with their requests to authorities. Beaurocracy is generally a desired thing, it's excessive beaurocracy that is awful.
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".
my_class_attr = ClassAttr[bool]: True
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.
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.
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.
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?
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.
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.
Also, while it works almost miraculously well as-is, type annotations would make the likes of Jedi much better. It might not seem like a big thing, but autocompletion is really useful with larger codebases and libraries you don't necessarily use every day.
There's very little extra cost with this over and above what's currently there. All it's doing is formalising something people have been doing in docstrings for decades already.
No, it doesn't. The only places this is meant to be used is at interface points, i.e., declaring object member attributes and method/function signatures. We're not talking Java or C++ levels of type annotation here: we're talking Go, Haskell, and O'Caml levels of type annotation at most.
And this is the core of the FUD around type annotations: people act like it's introducing Java and C++ levels of needless crud into the language, when the actual number of places where it's meant to be used is much smaller.
Furthermore, the most common type errors I do see would be solved more effectively by stricter runtime error checking than they would be by slathering the language in static typing.
For example:
if not x:
do_something()
Ironically just a month ago a junior changed some of my code from :
if x is not None:
do_something()
if not x:
do_something()
Not long after he did that he hit a bug because it wasn't supposed to do_something() if x was a blank string. Whoops.
> I've worked on multiple large projects, and while type
> errors are a problem, they aren't in the top 5 classes
> of 'most commonly reported bugs in production' - not
> if you have tests and a sprinkling of sanity checks, anyhow.
I think sprinkling type annotations all over the code is much preferable to writing test code. We have a type system such that the compiler can produce the code needed to check types, rather than us having to write this code in a test.
In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work.
You literally didn't have to say anything else to let me know that you're a haskell developer :)
My claim is that developers who habitually don't do TDD like the methadone hit that static type checking provides.
I actually write very almost no tests to directly verify type correctness but I always write a test for any new behaviour.I implement. 95% of the type errors I do encounter indirectly come out in the process of writing tests that I would have written anyway in any language.
>I think sprinkling type annotations all over the code is much preferable to writing test code.
And I think if you're avoiding writing tests to define what your code should do you're a shoddy programmer.
I've been sprinkling my programs with sanity checks and runtime type checks for a decade which has been more than sufficient at eliminating almost all bug-causing type issues the tests don't catch.
This isn't something I even need to do often so any alternative to this process isn't going to yield me much of a productivity gain.
>In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work.
Wherein you just indirectly addressed the biggest complaint people have with the haskell community - it's horrendously shitty documentation. You're supposed to figure out the behavior of libraries just by looking at the type.
Good tests tell a story.
The tests I write for libraries double as readable documentation for that library. The tests I write for applications double as readable executable specifications. This is a relatively new thing hampered somewhat by tooling issues but I think it'll catch on.
For libraries that I use I often ignore the official documentation and treat the tests as documentation instead.
Compilers can't do this for you. They don't know how your code is supposed to work.
Ironically one of the best things to come out of the haskell community was quickcheck - a testing library.
> And I think if you're avoiding writing tests to define
> what your code should do you're a shoddy programmer.
I think both viewpoints have merit. But neither one paints the whole picture. Tests are useful to a certain degree, but since time is limited, it's all about striking the right balance between testing and no testing. You can always write more tests, but at some point it becomes more useful to just look at the code you're testing. And, conversely, you can always look at your code one extra time, but sometimes it's better to formalize your doubts into a test.