Python is becoming a Turing tarpit language that’s black-holing on its own syntactic complexity. Soon every single ASCII character will have a special syntactic meaning and the syntax itself will become Turing complete in more than one way, similar to C++ that has already collapsed in syntax hell. JavaScript is following the same path by adding every feature from every other programming language. Soon all programming languages will have exactly the same features where everything is possible but nothing is doable or practical.
Python’s “type hints” are a bit of a disappointment to me
371–380 of 597 posts
Re: Python’s “type hints” are a bit of a disappointment to me
#372Landing in a large-ish python project without type annotations is a pain. Author says that he won't use type annotations because they "can be wrong", well, you only rely on variables names and documentation for that, you have even less chance to get that right.
Is that "line" variable a "LineInvoice" or "InvoiceLine" (yes, two different classes) ? Oh, right, both can be used in this place exclusively because one is subset of the other... sigh
Re: Python’s “type hints” are a bit of a disappointment to me
#373Love typing, if you are writing code with a lot of Data Frame Inputs and Outputs I encourage you to check out Pandera.
Re: Python’s “type hints” are a bit of a disappointment to me
#374About this section:
Sadly, dataclasses ignore type hints as well
this is excatly what pydantic was made for. As well as its integration with FastApi.
FastApi, is really the most beautiful way, I have seen. To use the python type system to its fullest.
Re: Python’s “type hints” are a bit of a disappointment to me
#375Landing in a large-ish python project without type annotations is a pain. Author says that he won't use type annotations because they "can be wrong", well, you only rely on variables names and documentation for that, you have even less chance to get that right. Is that "line" variable a "LineInvoice" or "InvoiceLine" (yes, two different classes) ? Oh, right, both can be used in this place exclusively because one is s…
Python's base philosophy is duck typing. Whenever I read complaints like this the root cause is almost always trying to turn Python into something that it isn't instead of embracing what it is (if this isn't feasible, then Python is the wrong choice).
Programming in Python worrying about types instead of behavior reminds me of the quote "you can write FORTRAN in any language".
Re: Python’s “type hints” are a bit of a disappointment to me
#376This 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 stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks. Christ. What a mess. With a stack like that, it's a stretch to say you're "writing in Python" anymore.
> Most of their main arguments (...) evaporate as soon as you start using the correct tooling.
You silly! Just use these carefully curated list of 28 different tools (that I got to after years of trial and error) and you'll have a somewhat acceptable tooling and type support in Python.
Re: Python’s “type hints” are a bit of a disappointment to me
#377Earlier quoted context omitted.
As long as you don't have to rely on 3rd party libraries, sure, type hints are fine. Many popular libraries, however, don't have type hints or use them inconsistently (looking at you numpy, pytorch, tensorflow, scipy, ...). Always great fun to see function signatures that use type hints for the parameters and return Any . So it really depends what kind of code you write - web frameworks might be fine, data science an…
You can write type stubs for other libraries. Over past year my team had a 100k line codebase that we’ve gotten mostly typed. But we still use a lot of other untyped libraries like tensorflow. So in past couple months we’ve started adding type stubs to the parts of the api we use. While tensorflow/numpy/etc are massive libraries most people only use a small subset of api. You can write type stubs for the subset you u…
https://github.com/python/typeshed also provides community maintained stub packages for packages that are lacking upstream type hints
Re: Python’s “type hints” are a bit of a disappointment to me
#378Earlier quoted context omitted.
What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…
> Pandas does is notoriously hard to fit into a compile-time type system What, mutate data with known structure? What exactly do you imagine is hard about this, let alone notoriously so?
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.
Re: Python’s “type hints” are a bit of a disappointment to me
#379Earlier 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.
That’s quite a strongly worded opinion. It sounds like it should be utterly trivial in this case to show that typed code causes less harm. I’m happy with whatever definition of harm you’re happy with. So where can i review the data supporting such a strongly worded position?
Re: Python’s “type hints” are a bit of a disappointment to me
#380Earlier quoted context omitted.
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.
That’s quite a strongly worded opinion. It sounds like it should be utterly trivial in this case to show that typed code causes less harm. I’m happy with whatever definition of harm you’re happy with. So where can i review the data supporting such a strongly worded position?
You can review it by talking to people that inherit your code, especially if they're still acclimating to it :)