5 ms·

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you

• pansa2 1y ago
  > They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.
  • graynk 1y ago
    the whole language violates this principle tbh, so it's very in spirit
    • tdeck 1y ago
      Yeah that ship sailed some time before they added a third way to do templated string interpolation.
  • kketch 1y ago
    Well, precisely: - There is one obvious way to provide type hints for your code, it’s to use the typing module provided by the language which also provides syntax support for it. - You don’t have to use it because not all code has to be typed - You can use formatted strings, but you don’t have to - You can use comprehensions but you don’t have to - You can use async io, but you don’t have to. But it’s the one obvious way to do it in python The obvious way to annotate a generic function isn’t with a giant Union, it’s with duck typing using a Protocol + TypeVar. Once you known that, the obvious way is… pretty obvious. The obvious way not be bothered with type hints because you don’t like them is not to use them! Python is full of optional stuff, dataclasses, named tuples, meta programming, multiple ancestor inheritance. You dont have to use these features, but there are only one way to use them
    • zx8080 1y ago
      > but there are only one way to use them Optional nature of those features conflicts with this statement. As optionality means two ways already.
      • preciousoo 1y ago
        classes are optional in python, does that violate the spirit?
  • TZubiri 1y ago
    How so? There is one way to do it. If you want typing, you use type hints. You wouldn't say that, say, functions are unpythonic because you can either use functions or not use them, therefore there's two ways to do things, would you?
  • bityard 1y ago
    "There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It was originally meant as a counterpoint to Perl's "there's more than one way to do it," to show that the Python developers put a priority on quality and depth of features rather than quantity. But times change and these days, Python is a much larger language with a bigger community, and there is a lot more cross-pollination between languages as basic philosophical differences between the most popular languages steadily erode until they all do pretty much the same things, just with different syntax.
    • dragonwriter 1y ago
      > "There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It never was a thing in Python, it is a misquote of the Zen of Python that apparently became popular as a reaction against the TMTOWTDI motto of the Perl community.
      • bityard 1y ago
        Not misquoted, paraphrased. I didn't feel like bothering to check the output of "import this" before posting.
  • lexicality 1y ago
    on that note, which is better, using `map()` or a generator expression?
  • xzel 1y ago
    And Python failed at that decades ago. People push terribly complicated, unreadable code under the guise of Pythonic. I disagree with using Pythonic as reasoning for anything.
  • xzel 1y ago
    And Python failed at that decades ago. People push terribly complicated, unreadable code under the guise of Pythonic. I disagree with using Pythonic as reasoning for anything.
  • dragonwriter 1y ago
    This is a popular misquote from the Zen of Python. The actual quote is “There should be one—and preferably only one—obvious way to do it.” The misquote shifts the emphasis to uniqueness rather than having an obvious way to accomplish goals, and is probably a result of people disliking the “There is more than one way to do it” adage of Perl (and embraced by the Ruby community) looking to the Zen to find a banner for their opposing camp.
• zelphirkalt 1y ago
  Yeah, but then you get into the issues with when and where generic types are bound and narrowed, which can then make it more complicated, at which point one might be better off stepping back, redesigning, or letting go of perfect type hint coverage, for dynamic constructs, that one couldn't even write in another type safe language.
• yladiz 1y ago
  Actually in Python it can. Since the type hints are accessible at runtime, library authors can for example change which values in kwargs are allowed based on the type of the argument. So on the language level it doesn’t directly change the behavior, but it is possible to use the types to affect the way code works, which is unintuitive. I think it was a bad decision to allow this, and Python should have opted for a TypeScript style approach.
  • kketch 1y ago
    You can make it change the behaviour at runtime is different than it changes the behaviour at runtime I think? Lots of very useful tooling such as dataclasses and framework like FastAPI rely on this and you're opinion is that it's a bad thing why? In typescript the absence of type annotations reflection at runtime make it harder to implement things that people obviously want, example, interop between typescript and zod schemas. Zod resorts instead to have to hook in ts compiler to do these things. I'm honestly not convinced Typescript is better in that particular area. What python has opted for is to add first class support for type annotations in the language (which Javascript might end up doing as well, there are proposals for this, but without the metadata at runtime). Having this metadata at runtime makes it possible to implement things like validation at runtime rather than having to write your types in two systems with or without codegen (if Python would have to resort to codegen to do this, like its necessary in typescript, I would personally find this less pythonic). I think on the contrary it allows for building intuitive abstractions where typescript makes them harder to build?