I haven’t worked in Python for several years, so my only dog in this fight is interest in the evolution of programming generally. But speaking as someone who previously preferred dynamic typing, and largely switched to TypeScript several years ago, I cannot understand this view anymore.

Static types help to eliminate an entire class of bugs, and encourage significantly better design. If you disagree with those claims, or don’t value the benefits as much as others do… Python’s type system is entirely optional. You are welcome to just not use them. That’s not fracturing the language: they're already a part of the language, and have been for years.

It’s fine that you have different preferences, but I think it’s wildly presumptuous to impose that on others.

> They are ugly.

Don't use type hints.

> They require additional knowledge to implement correct type hints.

Don't use type hints.

> It encourages bikeshedding on features useless to the core language. Manpower is wasted on something the majority of Python developers and applications don't really benefit from.

The majority of Python developers and applications benefit from typing improving the quality fo the ecosystem whether or not they directly use type hints.

> It creates the rift in the language.

Not as much as forking the ecosystem between two separate related languages would. (Which is why support for typing was added, mypy was initially a separate language.)

> The editors and IDEs have become too reliant on type hints, so they changed their linting algorithms to basically require typing.

VSCode’s Python support works fine with or without type hints in user code. Obviously, you get more value with them, but that's because there is more information to work with. And even if you don't use any type hints in your code, you get benefits from hints in libraries/stubs for dependencies.

If you have some other tooling that doesn't work for your untyped code, take it up with the tooling vendor.

> It affects the startup performance.

I wouldn't mind seeing a Python -> Python transpiler that removed type specific code, so that dev-time type hinting is zero-cost in production. This is not a non-issue, but it's also not enough to justify dropping typing support from the language.

> How can I avoid type hints when my IDE is "smarter" now with them?

Accept that the IDE won't be smarter for the kind of code you are writing.

> When they changed it's linter to look for type hints and ignore the rest of the code in functions in order to determine types?

Oh, so you mean “now that my IDE changed to be dumber without them than it used to be”. Don't use that IDE. Or complain to them to fix it. Or choose a non-default linter, if it supported. (IDEs can be very opinionated about how languages will be used, but to the extent that this conflicts with your preferences, complaining that the language shouldn't support something because the IDE you were using decided to only support that approach is blaming the wrong party.)

> Sure, it is easier for IDE developers to just leverage type hints and ignore the context of the entire script.

Python has lots of available linters, and most of them don't do that (you can't correctly apply type hints of you do, so its a bad idea even with type hints.) If a linter does that, don't use that linter. If an IDE mandates exclusively using a linter that does that, don't use that IDE.

> Am I now required to type hint my functions just to make use of my IDE's features?

I don't know about your IDE. Mine works as well as it ever did (well, better, as it is continually improving) on non-hinted code, and even better than that with with hinted code.

I think it's telling that Python blew up in popularity back when it didn't have type hints, and also when it was competing with other statically-typed languages out in the wild. A programming language that did away with a lot of ceremony turned out to be useful for a lot of people.

I think static types are useful in general, and they pay off fairly quickly for code at scale. But I also think the overhead of writing statically-typed code is not 0, and there's a long tail of small scripts and applications that don't benefit from being statically typed, and that's where something like Python is useful.

I thought type hints in Python were dumb until I combined them with VSCode. Holy cow the autocomplete and tool tips are incredible, there’s no way I could go back.

Of course, they are almost required there. Microsoft's Pyright extension is useless without type hints. I know this because I tried to use VSCode without them. It reminds me of those free-to-play MMORPGs, where you have to pay to unlock their entire content.

I mentioned the point of making our tools too reliant on type hints in my opening.

> Microsoft's Pyright extension is useless without type hints.

I do lots of work with both annotated and unannotated Python. Pylance (which is what is built into VSCode and based on Pyright) is not useless on unannotated code.

> It reminds me of those free-to-play MMORPGs, where you have to pay to unlock their entire content.

Well, yeah, there are things that type annotations allow that you can't statically determine without them. That's...rather the point.

Although I tend to agree with you, unfortunately this is not gonna happen.

With new programming languages popping up everywhere, they need to make python attractive for developers, otherwise developers will migrate to other languages.

Since asyncio we already have two languages, because synchronous python is one beast, and asynchronous python is a totally different beast. If you put type hints on top of that, it is really difficult to call python python.

You have a point. Sadly, they misunderstand what attracts more developers. It's all about the quality, not the quantity of features.

Asyncio is like black magic to me. The rules of the language change too much. I don't really believe it's even needed, because we already have threading in the standard library.

Sync, using requests:

  import requests

  def main():
    with requests.Session() as s:
      r = s.get('https://...')
      result = r.json()
  
  main()
 

Async, using aiohttp:

  import aiohttp
  import asyncio

  async def main():
    async with aiohttp.ClientSession() as s:
      async with s.get('https://...') as r:
        result = await r.json()
  
  loop = asyncio.get_event_loop()
  loop.run_until_complete(main())

If you're making many HTTP requests, you can use async, queue them up and it greatly improves performance.

See also https://docs.aiohttp.org/en/stable/http_request_lifecycle.ht...

Here are some more realistic examples utilizing the official HN API. The async version is about 30 times faster than the sync version when you set the total to a high number, the maximum is about 500. Performance tables are in the code itself.

https://github.com/gabrielsroka/hn

See also https://news.ycombinator.com/item?id=30172433

Asyncio is weird. But check out Trio, an alternative and easier-to-understand async framework: https://trio.readthedocs.io/en/stable/tutorial.html

Trio solves a problem that threading does not: switching between tasks only happens at deterministic points (they don't run in parallel), and tasks are in a hierarchy so that exceptions are handled in reasonable ways (and you can do a lot of other associated cool things like cancel an entire tree of tasks).

Python has a GIL, so you're not getting parallel Python code anyway without multiprocessing.

This means that if I'm writing code that implements, like, a basic network server, by far the easiest way to do it is Trio. Unlike with threading (in Python or any other language) I don't have to worry about locks from concurrent access / tasks switching at unexpected points, and unlike with e.g. the select module, handling both directions of communication and multiple connections is doable with normal straight-line code instead of weird state machines.

It's not needed, yes, but neither is Python itself. You could just write C.

I love Trio, much better than the standard asyncio.

> It's not needed, yes, but neither is Python itself. You could just write C.

I'm currently learning C, so I can use Python as a front-end for C, giving users a nice interface while using C to handle the hard work, which is what lots of Python libraries do under the hood.

If C is not your thing, there are some interesting projects to use other languages with Python [https://github.com/PyO3/PyO3] | [https://github.com/yglukhov/nimpy]

Python and C work wonders together.

I must admit that writing in C gives a more fun challenge.

> You have a point. Sadly, they misunderstand what attracts more developers. It's all about the quality, not the quantity of features.

Unfortunately, people these days like more quantity than quality. Look at Rust. People love Rust. There are others nice, fast and safe languages out there, but Rust has one thing other do not: features, features and features. More and more features every new version.

lol, no.

> typing is not pythonic, at all.

Calling something unpythonic is a best practice.

Typing vastly reduces the amount of low gain tests. It helps navigate the code and catch errors before they hit production. If you don't want types, don't use them.

> They require additional knowledge to implement correct type hints.

That is the point. Maybe PHP with semantic white space is your style.

Casting spells on others in unpythonic.

Not if they're Cleric spells :)

Although I do like typed languages, I agree that we should leave python alone. I think this trend of adding types to everything is harmful. Just use a different language if you like static types! You'll have a better experience anyway.

If you don't want it, don't use it and I will just avoid your library.

I'm a bit surprised at the vitriol here for even just type hints, much less even static typing. I'll admit that static typing is probably more pain than most python devs are willing to pay, but I will die on the hill of type hints being an essential contribution to the language that vastly improves its capabilities.

But don't take it from me, take it from the people who wrote urllib3 [1], who insist that typing is even more powerful than unit tests--and they're the developers of a wildly popular library. "People are making it harder to develop without [type hints]" you say, completely ignoring the productivity boon that the type hints have provided to many other people. (I'm also not clear on how the existence of type hints makes it harder to develop without them.)

In my personal experience, adding type hints and enforcement to our code has eliminated entire classes of runtime errors, and I find that developing with them makes my life significantly easier. I'll admit some of that may be because dev tools are leaning on the hints, but I ask what's the alternative? You can't static-analysis your way to a definitive type in a dynamic language.

I'll try to respond point by point:

> I don't want ugly rust-like typing. [...] It looks horrible in Python.

You don't want a feature because... it looks bad? I could understand if it's "confusing" or "unclear syntax" or "makes it harder to read", but just "ugly" I have trouble both believing and understanding.

> 2. Requires additional knowledge to implement correct type hints. [...] It is even getting hard to track the changes without including typing.

I'll admit I'm not certain what you mean here. Typing is an optional feature, you don't have to use it in your own code. I would also personally expect that knowing the types of the things you're working with (e.g. via hints) would make it easier to hint your own code--but again, that's even optional to do.

I'm not sure what you mean by 'tracking the changes'--Could you elaborate on that?

> 3. It encourages bikeshedding on features useless to the core language.

I'll grant that adding typing to python opens up a whole new class of things for people to grouse about in mailing lists and on forums, and could even be pulling effort away from the core libs: but, python being an open-source open-contribution system, I'm amused that you're taking issue with people who're taking time and effort to contribute to the language simply because they aren't contributing in the way that you want. Sure, it's reasonable for the community to provide feedback to the creators,

There's also the obvious comparison to Typescript, which is widely heralded as a massive improvement to Javascript--or at least enough of an improvement to have drunk who knows how many billions of dollars in developer-effort from Facebook and Microsoft because it's so much of a force-multiplier. While python shouldn't blindly follow other languages for the hell of it, I do think it's paramount to sticking ones head in the sand to ignore the transition of the Javascript ecosystem, absolutely THE largest dynamically-typed language, to a statically-typed variant.

> 4. It creates a rift in the language.

This, I'll grant: if we moved to a fully static python, there'd likely be massive compatability issues throughout the ecosystem as library A adopted static types, but not library B. We already have some of this (as people note in other HN threads [2], though they're definitely in the minority) as you pile on libraries with just type hinting, but it is improving as type hints become more and more popular.

> 5. It affects startup performance

I'm assuming this is about static typing; type hints themselves have negligible performance impact. Or at least, in my experience they've been totally negligible (compared to just loading large untyped libraries), and I'd love to see if you have examples to the contrary. There's plenty of ways for static typing to be done without impacting startup performance, or indeed for static typing to be a performance GAIN (as there's classes of issues the VM won't have to handle, or we can emit more efficient bytecode, etc etc--see also, optimizing compilers).

----

Overall, I think you make a lot of claims that require some amount of evidence to back up, especially when there's so many examples of type hints being an absolute boon to people, both individual developers and maintainers of popular libraries. "Useless typing PEPs" and "Manpower is wasted on something the majority of Python developers and applications don't really benefit from" and even citing type hints as adding complexity to newbies when it's a completely optional feature? I can't bring myself to believe these claims in the face of the community's counter points and my massive opposed experience.

Type hints in python are a joy for me, coming from Rust and Swift and C++ and Typescript. I can remember when python was hell because you'd get hours into a run of a program and then the whole damn thing would come down because of a mismatched type. Having that extra bit of static analysis to ensure things worked properly is wonderful. The very first thing I did in my new role at my current company was to progressively typehint things and slowly fix the mypy errors, which led to 50% reduction in error rate in the application and, eventually, a speed increase in the order of three magnitudes. None of that would be possible if I didn't have type hinting.

And, yes, your original premise is around static typing, I know, but you expend considerable electronic ink against the hints as well, and one begets the other.

Overall, your points read more like resisting change for the sake of resisting change than substantive issues with the system.

[1]: https://sethmlarson.dev/blog/tests-arent-enough-case-study-a...

[2]: https://news.ycombinator.com/item?id=26530381 (but also check the whole parent discussion)

To even have "static typing" in Python, you need type hints. Your example with using mypy is basically an optional static analysis step before running the code.

What I am getting at is this: everything is converging towards new, statically typed Python. "Optional" features are no more optional when majority is pushed towards "professional developing using type hints".

"I'm not sure what you mean by 'tracking the changes'--Could you elaborate on that?"

I meant that the language has accumulated too many features as of late. So it's hard to keep track of them, regardless of typing changes.

"There's also the obvious comparison to Typescript, which is widely heralded as a massive improvement to Javascript"

Please, Javascript is not Python. If Microsoft wants to mess with Python, at least let them fork it and call it differently.

"Overall, your points read more like resisting change for the sake of resisting change than substantive issues with the system."

There is a difference between ressisting any change, and ressisting a harmful change. I consider the current trends around changing Python harmful.

> Please, Javascript is not Python. If Microsoft wants to mess with Python, at least let them fork it and call it differently.

Microsoft did not make the decision for Python to support type hints and thereby prevent mypy from having to be its own language.

GvR did when he was still BDFL.

> 1. They are ugly. Honestly, the code with typing is not pythonic, at all.

Not pythonic according to who, you? Besides, all the ugly type annotations could be moved out of the executing code, and into separate files. https://www.python.org/dev/peps/pep-0484/#stub-files

> 2. They require additional knowledge to implement correct type hints. The language is much less complex without them. It is even getting hard to track the changes without including typing.

Correct, one is required to know how to do something in order to do that thing correctly. This argument is fallacious because it relies on a truism. https://en.wikipedia.org/wiki/Truism

> 3. It encourages bikeshedding on features useless to the core language. Manpower is wasted on something the majority of Python developers and applications don't really benefit from.

So a topic that causes vibrant discussion is a bad thing according to you? Okay, so assuming you actually believe that, would you then agree Python language features should be unilaterally implement without any discussion? If however the result of a discussion is an agreement to move one way or the other, and that outcome is according to you wasted time? Exactly which discussions are or not wastes of times, perhaps just the one's you don't like? People who make tough decisions, and who have tough conversations are the proverbial "adults in the room", so perhaps you should avoid those kind of things? (I'm not trying to disparage you, just say you might better choose what you ignore or pay attention to)

4. It creates the rift in the language. The language is "extended" with features that push the developing tools (such as Pycharm) in the certain direction. The editors and IDEs have become too reliant on type hints, so they changed their linting algorithms to basically require typing. Now they are nearly useless without them. This creates the division in our community and further pushes away those who don't want typing in their code. Sure, they are not required, at least for now. But people are really making it harder to develop without them.

There is no rift in the language. You are not required to use new features you don't want to use. For example: Got an issue with the walrus operator? Fine, write more lines of conditional statements to do the same thing. Don't like type analysis, fine... you run the risk of non-obvious bugs in the code you write, or hitting bugs with imported libraries 5-levels deep. As for the IDE's, you make a fair point... perhaps real programmers should use vim or Notepad instead? Type hints are going into most of the popular libraries, and unless your responsible for one of those, I fail to see your point... no body is forcing you to use type hints, much less vigorously encouraging you to use type hints. There is no type hints conspiracy to encourage you to use them.

5. It affects the startup performance. It is not a big hit if the application is small but it adds up.

I'm super skeptical of your claim. At most the runtime would have __annotations__ attributes declared, and you will have a difficult time persuading people that populating those magic double-under (dunder) variables has any significant cost. https://docs.python.org/3/library/typing.html#introspection-...

> So please, stop with the useless typing PEPs. Fork the language if you must. But don't call it Python anymore.

Don't let the door kick you on the way out.