I would argue that doing this kind of stuff is bad design.
```foo = { 'hello': 'world', 'bar': ['baz'], } ```
Don't put it on the language not to be able to deal with this kind of stuff.
Python’s “type hints” are a bit of a disappointment to me
411–420 of 597 posts
Re: Python’s “type hints” are a bit of a disappointment to me
#412Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…
Have you (or anyone else on this thread) used retype or MonkeyType? We have a codebase right now that's mostly lacking type hints. But, now that we have added automatic flaking into our build (and pre-commit hooks), I'd like to get some more mileage out of that toolchain we just invested into, but it would be a hassle to go back and add type hinting to everything.
What I'd like to do is integrate something into our pre-commit hooks.
Re: Python’s “type hints” are a bit of a disappointment to me
#413Earlier quoted context omitted.
I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.
You misunderstand the ecosystem. Many folk program in Python because it’s largely forced upon them. It’s often the easiest language to work with for data science, ML Eng, or data engineering, despite many frameworks actually running in the JVM. It’s simply more accessible. The appeal of Python has not been its provenance or design for over 15 years, but rather the ecosystem.
Most engineers I work with are very happy to work with python. They would not say it is forced upon them. You are free to provide a much better alternative (that does not exist as far as I know).
Re: Python’s “type hints” are a bit of a disappointment to me
#414The author seems to have unreasonable expectations of the python typing implementation, most of which can be fixed with mypyc and stricter flags. They also did not check the concept of gradual typing which is key to why everything is not strict by default.
I too am disappointed a bit by the type hints because they are not expressive enough for me, and some natural python constructs are hard to express. And because mypy has bugs I encounter from time to time.
Re: Python’s “type hints” are a bit of a disappointment to me
#415Earlier quoted context omitted.
If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately. The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re hav…
Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…
On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot of things these days because of the deployment simplicity)
Re: Python’s “type hints” are a bit of a disappointment to me
#416Earlier quoted context omitted.
Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.
Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.
pyright is a command line program https://github.com/microsoft/pyright
in my experience it's a far better type checker than mypy, which tends to silently not check things without you ever realising
Re: Python’s “type hints” are a bit of a disappointment to me
#417Earlier quoted context omitted.
Not hard per se, but extremely unergonomic. A pandas dataframe types to something like Iterable[SomeKindOfProductType[int, str, str, ... (78 other columns)]]. The formal type of a dataframe in the middle of a transformation is... not very useful to know.
You wouldn't typically type tabular data in any language. Give it (at most) a DataFrame type if you must, where StoreTransaction describes the structure of a row - maybe declaring only columns that model generation code was doing typed operations on (e.g. numerics vs strings) to avoid the need for reflection.
Either you type the tabular data at compile time or you don't get type checking of tabular data at compile time.
The number and types of the columns aren't necessarily known at compile time. Which leads to runtime errors. Even in a statically typed language, such dataframes are a kind of "dynamic typing escape hatch". As complexity of a software increases, such mechanismus of dynamic typing and throwing runtime errors creep up all over the place.
Re: Python’s “type hints” are a bit of a disappointment to me
#418Earlier quoted context omitted.
Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…
If you write more code that is untyped than typed, you are harming whoever comes after you. Untyped code is an absolute dragon even if it is properly documented (which it practically never is). Glorifying "productivity" and putting it above the greater good is essentially everything that's wrong with the world, at every level.
programming languages : diehard dynamic typing advocates :: global pandemic : mask mandate protesters
Re: Python’s “type hints” are a bit of a disappointment to me
#419Earlier quoted context omitted.
I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.
There are way more differences between Python and Java than just "having explicit types". If that was the only difference, your comment would make more sense. I would even go so far as to say that Java's type system is the very one that left such a bad taste in people's mouth that many people swore off explicitly typed languages for a decade or two. It really was that bad, especially before the last few years. It add…
> C# has done a better job of keeping up, in my opinion, but even it still lacks extremely useful features like proper Sum Types
Does type pattern matching comes close? https://dotnetfiddle.net/Oz2Qyd
Yeah, it doesn't prevent passing unexpected type as object to Print func and getting runtime exceptions. And returning "object" type isn't helpful if we want to prevent runtime errors. But then again, it can be written to spit out compile time errors: https://dotnetfiddle.net/XfKVaa
Re: Python’s “type hints” are a bit of a disappointment to me
#420This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…
My thoughts exactly. Obviously, Python Type hints are an attempt to add type-check to a language "after the fact" and keep it optional. So it's unfair to compare that to a static typed language and conclude that it's bad.
I work with large code bases (100K-1M lines) and can't look back to the time we didn't use Type Hints. Would maybe dismiss it only for scripts or very small projects.