5 ms·

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 inter

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.

dagmx 3y ago
Yeah but my rebuttal is that even with type hints and adequate type checking, that Python is too dynamic to trust consistent behaviour. An object can conform to a type in name only, but that’s not enough to tell you what methods or attributes exist on it at any given time.
- formulathree 3y ago
  monkey patching is rarely done. In practice, your rebuttal almost never occurs. I believe these type checkers can detect monkey patching and trigger a type error or warning.
  - dagmx 3y ago
    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.
    - formulathree 3y ago
      [flagged]
      - dagmx 3y ago
        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
still_grokking 3y ago
[flagged]
- formulathree 3y ago
  [flagged]
  - still_grokking 3y ago
    [flagged]
    - formulathree 3y ago
      [flagged]

dagmx 3y ago

Yeah but my rebuttal is that even with type hints and adequate type checking, that Python is too dynamic to trust consistent behaviour. An object can conform to a type in name only, but that’s not enough to tell you what methods or attributes exist on it at any given time.

formulathree 3y ago
monkey patching is rarely done. In practice, your rebuttal almost never occurs. I believe these type checkers can detect monkey patching and trigger a type error or warning.
- dagmx 3y ago
  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.
  - formulathree 3y ago
    [flagged]
    - dagmx 3y ago
      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

still_grokking 3y ago

[flagged]

formulathree 3y ago
[flagged]
- still_grokking 3y ago
  [flagged]
  - formulathree 3y ago
    [flagged]