That's great if you're in a codebase at a workplace which enforces python type annotation checking.
Unfortunately, I can tell you from experience that out in the real world, at fortune 500 companies, there are millions of lines of untyped Python doing critical work while being full of subtle type errors which should be compile time errors but will rear their heads as runtime errors when it's least expected.
Do you work at the majority of companies? I can tell you that I’ve worked with code bases from each of the FAANG companies that don’t use type checking, because it’s optional. Anything that’s optional in a language will not be ubiquitous
Your statements are incongruent with the reality of production.
I've likely worked for more companies then you in the last 5 years or so due to my personality. I don't stay at one place for long. Actually I've probably worked for more in my entire career, but only the last 5 years should be relevant.
Even so where I worked is only part of the equation. You can look up which companies use python types in a google search.
Let me add more nuance, companies that use python as glue code as in scripting languages don't use types. This makes sense as python is considered not as important as the main language.
For companies that are primarily based on python... the majority use types. The ones that don't are actively migrating. This includes faang and subsidiaries. In fact type checkers for python are likely to be built by faang or companies close to that tier.
I’m unsure how you can so confidently make that assertion.
Even at companies that do use type hints, there’ll be tons of legacy code that won’t (and probably tons of new code as well if we’re being realistic).
It’s like saying every company uses bash scripts. It’s not really indicative of the prevalence in actual code bases in production use other than saying it may be used somewhere within the company.
Between this and your other comments, you’re making very widespread comments that can’t logically apply to everything and nor do they in my experience.
>Even at companies that do use type hints, there’ll be tons of legacy code that won’t (and probably tons of new code as well if we’re being realistic).
The first part is true, I agree with that assessment and I never made a contrary claim. Companies are migrating.
The second part in parenthesis, is less common, I don't agree that it's a generality among companies that have python as a primary language.
>It’s like saying every company uses bash scripts. It’s not really indicative of the prevalence in actual code bases in production use other than saying it may be used somewhere within the company.
I don't even know what you're getting at with this example. Tons of companies use python "somehwhere" within the company. I'm sure in those cases it's often not typed.
But for companies or teams that use python as a primary it's typically typed or in the process of getting migrated to be typed. That is the nuance I added to my claim.
>Between this and your other comments, you’re making very widespread comments that can’t logically apply to everything and nor do they in my experience.
Except you made statements that are factually wrong. I literally ran mypy on some code and your statements were categorically incorrect from your other comment. Usually these debates are anecdotal so logic doesn't apply as it's just fuzzy opinions regarding social aspects of society. But that's not the case here. You made factually incorrect statements and that has bearing on the correctness of your anecdotal statements too.
The problem is less the language and more the culture around it. Typing will always be second-class, culturally. Additionally, mypy feels much slower to use versus something like Rust’s ‘cargo check’.
Regarding ADTs: do type checkers ensure totality (all cases covered) when pattern matching?
(I’m not casting aspersions here. It is what it is, you know?)
>The problem is less the language and more the culture around it. Typing will always be second-class, culturally. Additionally, mypy feels much slower to use versus something like Rust’s ‘cargo check’.
Agree with mypy being slow. As for the culture it's largely moving in the right direction and it's at a point where you're more likely to find a python shop to be using typing than not. Of course for scripting I think people may not be so readily adopting types.
>Regarding ADTs: do type checkers ensure totality (all cases covered) when pattern matching?
Yes it does.
Cast your initial presumption aside. This was a huge surprise to me too. Everybody loves typescript but basic usage of types in typescript is actually less powerful because it doesn't support this.
modern python development is used in conjunction with an external type checker. That's what I meant.
My mistake for not being clear. Obviously the python interpreter itself does not do any type checks.
It's sort if like how modern development with javascript is used with an external compiler of another language (typescript) that compiles a typed language into one without types.
In practice it does occur very often. I’d suggest not ascribing your own experience to my own. I’ve been professionally coding in Python for over a decade in very varied codebases.
There are tons of libraries in many companies that use dynamic attribute lookups for efficiency reasons, when adapting to different data sources and the like. Or pass through lookups on nested objects. Or they’re dynamically looked up on bound libraries from other languages and frameworks.
And these type checkers cannot detect it. Python’s dictionary access is not guarded by the type checkers and neither is __getattr__.
If you’re making such wide sweeping statements you need to be more familiar with the subject matter.
Your code is not what I’m describing at all. You’re just talking past me without actually trying to understand what I’m saying or reading the specifics.
A Python instance is effectively a dictionary. The contents of that dictionary can be mutated at runtime to disagree with the type that is specified. This is perhaps an antipattern but it’s not uncommon.
Attribute lookups can be dynamic as well without any typing. The typing can be lofted out and specified at the lookup site but that is also no guarantee of what you’ll get at runtime.
You cannot type check this dunder method access.
class A(dict):
def __getattr__(self, name):
return self[name]
You may say “oh but that’s uncommon or bad practice” but it’s unfortunately quite common in many production systems because Python has encouraged embracing its dynamicism for decades. That’s not a flaw, that’s a power. But it definitely has its pros and cons.
One may also say that “well that’s just void pointer casting in C or other languages”, which is also true and equally problematic. That’s why newer compiled languages like Rust and Swift have options for sum types / enums that carry a value to design around it in a type safe manner.
———
To your other point on courtesy…
If I say you’re unfamiliar with the details, it’s because you yourself said you aren’t sure YET you claim your world view of type checking is correct and dynamicism is rare. You don’t read my comments and substitute your own.
If I am being rude it is only because your default world view appears to be “the ideal in my head is the way it is”.
Take for example when you say “your rebuttal almost never occurs” or when you say pretty much every tech company uses type checking. You ascribe your own world view with no room for greys or real world variance.
If I say: “but this is my experience” your response is “well that’s not the reality for most cases”. So if I am rude it is because you talk in absolutes and only correct yourself when pushed back upon.
Perhaps do not talk so assuredly in general. Your experiences are not that of others yet you talk as if they’re the norm.
So if I am rude, it is because you are being rude in your responses and perhaps don’t realize it. You’ve basically told everyone who’s responded to you that their experiences aren’t correct.
Anyway I shall not respond further to you because this discussion is hyper fixating on something that was only intended to be an example. It serves no purpose to continue arguing
>A Python instance is effectively a dictionary. The contents of that dictionary can be mutated at runtime to disagree with the type that is specified. This is perhaps an antipattern but it’s not uncommon.
Yes I know. but the you will see the code addresses this. Mypy caught the monkey patching. Look at it. I added a property to an instance dynamically and mypy caught it.
>You may say “oh but that’s uncommon or bad practice” but it’s unfortunately quite common in many production systems because Python has encouraged embracing its dynamicism for decades. That’s not a flaw, that’s a power. But it definitely has its pros and cons.
I addressed this in the post you replied to. I specifically stated it. Let me quote it:
"__getattr__ is type checked too as long as you type the method signature, I have seen some weirdness around this area for type checkers but that's not the main problem. I understand where you are getting at with __getattr__. When you use this you're essentially creating something akin to a function with a string as a parameter. The contents of a string can't be type checked and if all methods are defined this way on a class none of it can be checked."
You addressed a point I already addressed, and didn't address the points you were factually wrong about: Dictionary access is type checked. Monkey patching is also type checked.
>Anyway I shall not respond further to you because this discussion is hyper fixating on something that was only intended to be an example. It serves no purpose to continue arguing
Completely agreed let's move on from all the BS. But you said some things that were factually wrong about python Dicts not being type checked. You said dictionary access is not type checked. Please address those things. I am interested in your viewpoint on this matter because I can learn something if my statement is wrong.
>Nonsense.>Python "generates" this: Traceback (most recent call last): File "/home/me/test.py", line 3, in <module> print(x[3]) ~^^^KeyError: 3
So? python generates that but the point was demonstrating type checking. The output you see is not generated by python. It's generated by an external type checker. The type checker caught the python exception without running any code.
>> The contents of a string can't be type checked […] Nonsense. This may be true for Python's type checking tools, but that's not a general limitation of type checking.
The context is python. We're talking about python. I'm making a statement about python. Nobody is talking about scala. I don't know why you're getting into scala stuff.
There is literally nothing in my statement to indicate I'm making a general statement about type checking. But I will say checking for the contents of a string is rare for a type checker to do. That is a general statement that is generally true.
>Some people have indeed infinite egos. If there would be just anything else besides that…
>I wonder every time why the most clueless are the loudest. That's so embarrassing.
Hey can you please stop being rude? The guy made factually incorrect statements and so did you. That's not an ego thing. It's just true that he's wrong. Everybody makes mistakes... people shouldn't get worked up about someone else identifying a mistake.
I too made a mistake. And I admitted my mistake. See my first couple of posts. I admitted I was wrong: the python interpreter doesn't do type checks. It was an error on my part for not clarifying I meant python development in general with external tools.
The type hints have no runtime semantics whatsoever.
The actual type-checking still happens at runtime in Python, and is not related to any static checks. Out of the perspective of Python's interpreter the type hints don't even exist. They're like comments…
Static type checking is not part of Python!
> Python also has ADTs which match it in power to rust.
All Turing-complete languages match each other in power…
Besides that:
Python doesn't have a static type system in the first place, so it can't compete with Rust in this regard. That's not even the same game.
>Of course it still is.
>The type hints have no runtime semantics whatsoever.
I clarified my meaning in another comment. You're right, I meant to SAY modern development involves type checking with python. But not with the interpreter. My mistake for not being clear.
>All Turing-complete languages match each other in power…
I obviously mean type checking. Additionally what you're saying isn't even true. Not all turing complete languages match in power or capability.
>Python doesn't have a static type system in the first place, so it can't compete with Rust in this regard. That's not even the same game.
Modern python development is done in conjunction with a type checker. Sort of like how modern javascript development is done with typescript. That levels up the game to where python is roughly in the same class as rust when it comes to type correctness.
Depending on the type checker python matches the power of rust, roughly. There are differences, but for ADTs they are pretty similar in capability.
