3 ms·

Basically, they screwed up by using a monorepo with Python and have decided to try and badly paper over it by using a type checker. For reference, don't do eit

Basically, they screwed up by using a monorepo with Python and have decided to try and badly paper over it by using a type checker. For reference, don't do either of those things in Python.

chc 4y ago
What do you feel makes Python less suited to monorepos than any other language? I've worked in Python-heavy monorepos and they seemed about like any other kind. And there is nothing wrong with using a type checker for your Python type annotations.
- ReflectedImage 4y ago
  Monorepos require static typing as a first class citizen of the language. "And there is nothing wrong with using a type checker for your Python type annotations." There is a lot wrong with that. Python is a dynamically typed language. If you are using a static type checker on a dynamically typed language, you are not taking advantage of the dynamic nature of the language. You are basically not writing Python code at all. This means you get all the disadvantages of using a dynamically typed language with none of the benefits. In summary, you have a made a very poor engineering decision.
  - goodoldneon 4y ago
    This is a terrible take. Using type annotations doesn’t mean Python is no longer a dynamically typed language
    - ReflectedImage 4y ago
      If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project. Typing related bugs that aren't caught in unit testing are very rare.
      - edgyquant 4y ago
        Any additional bugs per lines of code, which would be less in a strictly typed language anyway, is worth the structure you get from a typed language. I disliked JavaScript and love python. Typescript has replaced python as my labor of love language for now but a typed python in a similar manner would be great
        ReflectedImage 4y ago
        Typing doesn't remove many bugs from Python code (probably about 1 bug per year). It's statisically insignificant. JavaScript is a bad language and adding stuff to it makes it better. The same isn't true for Python.
      - throwaway343244 4y ago
        > If you enforce them then you can't do duck typing, This is a little misleading as mypy and pyright both support structural typing.
      - goodoldneon 4y ago
        > If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project. You can still do duck typing. Python's Protocol and TypedDict do that for objects and dicts, respectively. Python also has sum types. I've added type annotations to thousands of lines of legacy code and rarely have I had to change any logic to accommodate. > Typing related bugs that aren't caught in unit testing are very rare. Not true at all. Unless you're writing unit tests that cover every possible code path, your unit tests will miss stuff. And I'd argue that 100% test coverage is a Herculean effort to write and maintain, and isn't worth it. Static analysis gives you tons of checking for free. The biggest benefit is forcing you to properly handle function arguments that could be None. Are you always checking that values aren't None before using them?
        ReflectedImage 4y ago
        Static analysis using static typing gives you almost nothing at all in practice. It searches for a very narrow and rare set of bugs, which hardly ever happen. Typing really exists to help a compiler, it's not a code correctness tool in the way you envision.
    - geekraver 4y ago
      This guy is full of terrible takes. Like his claim that typing catches "one bug a year".
  - kortex 4y ago
    > You are basically not writing Python code at all. I really dislike this take. I believe Python is about rapid iteration, doing more of functionality with less code, and enjoying the process of programming. You know what I enjoy? Easily knowing what features (methods, attributes, keys) an object has. You know what I really don't enjoy? Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes. Nothing about duck typing prohibits saying `def func(duck: Duck)`, because maybe it's a French duck and has .coin() instead of .quack(). Also also, how is static typing completely incompatible with dynamic features? Usually there exists an abstraction with static types that actually captures the behavior you want. Its rare you want to be able to handle literally anything. Ask oneself, "could this function receive absolutely, truly, anything, or is it just shortcut for not finding the right types?"
    - ReflectedImage 4y ago
      You might dislike the take, but it's correct. If I write a side-effect free Python program in Haskell style, that isn't a "real" Python program. Using a static type checker is a similar type of change to the code style. "Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes." Figuring out the attributes and what kwargs a function takes is the role of your intelligent IDE and docstrings. You think you need to static typing for this since you haven't spent the time to learn how Python does these things. Duck typing says, duck doesn't have a type, not even Duck, anything that quacks is a duck even a 115 ton truck.
      - kortex 4y ago
        > You think you need to static typing for this since you haven't spent the time to learn how Python does these things. I've been writing python for over 15 years and use Pycharm extensively. Please don't make assumptions about other users' experiences without evidence. IDEs absolutely do not infer what fields *kwargs take, let alone what types those fields are. I'm not talking named fields, I mean literally def func(*args, **kwargs): ... Afaict, no IDE and no type system can help you there, in python, save for some really arcane type inference magic on every single call site. > duck doesn't have a type, not even Duck It absolutely does, if Duck is a protocol. If you have some object, and you call .quack(), it implements the Quacker interface, even without inheriting BaseDuck. You can still statically type it no problem, and it'll take a Truck no problem, so long as Truck.quack() is defined. Almost everything has a type, it just takes some effort to uncover it.

Basically, they screwed up by using a monorepo with Python and have decided to try and badly paper over it by using a type checker. For reference, don't do either of those things in Python.

chc 4y ago

What do you feel makes Python less suited to monorepos than any other language? I've worked in Python-heavy monorepos and they seemed about like any other kind. And there is nothing wrong with using a type checker for your Python type annotations.

ReflectedImage 4y ago
Monorepos require static typing as a first class citizen of the language. "And there is nothing wrong with using a type checker for your Python type annotations." There is a lot wrong with that. Python is a dynamically typed language. If you are using a static type checker on a dynamically typed language, you are not taking advantage of the dynamic nature of the language. You are basically not writing Python code at all. This means you get all the disadvantages of using a dynamically typed language with none of the benefits. In summary, you have a made a very poor engineering decision.
- goodoldneon 4y ago
  This is a terrible take. Using type annotations doesn’t mean Python is no longer a dynamically typed language
  - ReflectedImage 4y ago
    If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project. Typing related bugs that aren't caught in unit testing are very rare.
    - edgyquant 4y ago
      Any additional bugs per lines of code, which would be less in a strictly typed language anyway, is worth the structure you get from a typed language. I disliked JavaScript and love python. Typescript has replaced python as my labor of love language for now but a typed python in a similar manner would be great
      - ReflectedImage 4y ago
        Typing doesn't remove many bugs from Python code (probably about 1 bug per year). It's statisically insignificant. JavaScript is a bad language and adding stuff to it makes it better. The same isn't true for Python.
    - throwaway343244 4y ago
      > If you enforce them then you can't do duck typing, This is a little misleading as mypy and pyright both support structural typing.
    - goodoldneon 4y ago
      > If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project. You can still do duck typing. Python's Protocol and TypedDict do that for objects and dicts, respectively. Python also has sum types. I've added type annotations to thousands of lines of legacy code and rarely have I had to change any logic to accommodate. > Typing related bugs that aren't caught in unit testing are very rare. Not true at all. Unless you're writing unit tests that cover every possible code path, your unit tests will miss stuff. And I'd argue that 100% test coverage is a Herculean effort to write and maintain, and isn't worth it. Static analysis gives you tons of checking for free. The biggest benefit is forcing you to properly handle function arguments that could be None. Are you always checking that values aren't None before using them?
      - ReflectedImage 4y ago
        Static analysis using static typing gives you almost nothing at all in practice. It searches for a very narrow and rare set of bugs, which hardly ever happen. Typing really exists to help a compiler, it's not a code correctness tool in the way you envision.
  - geekraver 4y ago
    This guy is full of terrible takes. Like his claim that typing catches "one bug a year".
- kortex 4y ago
  > You are basically not writing Python code at all. I really dislike this take. I believe Python is about rapid iteration, doing more of functionality with less code, and enjoying the process of programming. You know what I enjoy? Easily knowing what features (methods, attributes, keys) an object has. You know what I really don't enjoy? Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes. Nothing about duck typing prohibits saying `def func(duck: Duck)`, because maybe it's a French duck and has .coin() instead of .quack(). Also also, how is static typing completely incompatible with dynamic features? Usually there exists an abstraction with static types that actually captures the behavior you want. Its rare you want to be able to handle literally anything. Ask oneself, "could this function receive absolutely, truly, anything, or is it just shortcut for not finding the right types?"
  - ReflectedImage 4y ago
    You might dislike the take, but it's correct. If I write a side-effect free Python program in Haskell style, that isn't a "real" Python program. Using a static type checker is a similar type of change to the code style. "Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes." Figuring out the attributes and what kwargs a function takes is the role of your intelligent IDE and docstrings. You think you need to static typing for this since you haven't spent the time to learn how Python does these things. Duck typing says, duck doesn't have a type, not even Duck, anything that quacks is a duck even a 115 ton truck.
    - kortex 4y ago
      > You think you need to static typing for this since you haven't spent the time to learn how Python does these things. I've been writing python for over 15 years and use Pycharm extensively. Please don't make assumptions about other users' experiences without evidence. IDEs absolutely do not infer what fields *kwargs take, let alone what types those fields are. I'm not talking named fields, I mean literally def func(*args, **kwargs): ... Afaict, no IDE and no type system can help you there, in python, save for some really arcane type inference magic on every single call site. > duck doesn't have a type, not even Duck It absolutely does, if Duck is a protocol. If you have some object, and you call .quack(), it implements the Quacker interface, even without inheriting BaseDuck. You can still statically type it no problem, and it'll take a Truck no problem, so long as Truck.quack() is defined. Almost everything has a type, it just takes some effort to uncover it.