9 ms·

So here I think we differ fundamentally in how we like to read code. I much prefer being able to quickly figure out things of interest about a function by glanc

So here I think we differ fundamentally in how we like to read code. I much prefer being able to quickly figure out things of interest about a function by glancing at its signature, rather than look at documentation, or worse, having to read the implementation of the function and the functions it calls (and so on, recursively). For example, I much prefer a signature like def f(a: int) -> str: over def f(a): because it allows me to see, without reading the implementation of the function (or, if it exists, and I'm willing to bet on its reliability, the documentation), that it takes an integer, and gives me a string. And yes, this requires that I write viral type annotations on all my functions when I write them, but for me the bottleneck at my job is not writing the code, it's reading it. So that's a small upfront cost I'm very much willing to pay. > Do you think we should be annotating functions with `expensive` and/or `networking`? And also annotating all of their callers, recursively? Yes, absolutely, and yes, absolutely. That's just being upfront and honest about an intrinsic property of those functions. A function calling a function that does network I/O by transitivity also does network I/O. I prefer code that's explicit over code that's implicit.

pansa2 2y ago
> Yes, absolutely, and yes, absolutely. Fair enough, that's a valid philosophy, and one in which `async`/`await` makes perfect sense. However, it's not Python's philosophy - a language with dynamic types, unchecked exceptions, and racy multithreading. In Python, `async`/`await` seems to be at odds with other language features - it feels like it's more at home in a language like Rust.
- wesselbindt 2y ago
  I completely agree with you. However I've always found the dynamic typing approach to be a bit at odds with python3 -c "import this" | head -4 | tail -1 I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. But having worked in large codebases which adopt the same style, and ones that avoid it through static typing and in some cases async/await, the difference in productivity I've noticed in both me and my collaborators is too stark for me to ignore. I think I should've been more nuanced in my comments praising async/await. I believe that what I say is valid in large IO-bound applications which go beyond basic CRUD operations. In general it depends, of course.
  - pansa2 2y ago
    > I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. Agreed - I only use Python for scripts like this, preferring statically-typed, AOT-compiled languages for larger programs. That’s why I think Python should have adopted full coroutines - it should play to its strengths and stick to its fast-and-loose style. However, the people who decide how the language evolves are all employees of large companies using it for large codebases - their needs are very different from people who are only using Python for small scripts.

pansa2 2y ago

> Yes, absolutely, and yes, absolutely. Fair enough, that's a valid philosophy, and one in which `async`/`await` makes perfect sense. However, it's not Python's philosophy - a language with dynamic types, unchecked exceptions, and racy multithreading. In Python, `async`/`await` seems to be at odds with other language features - it feels like it's more at home in a language like Rust.

wesselbindt 2y ago
I completely agree with you. However I've always found the dynamic typing approach to be a bit at odds with python3 -c "import this" | head -4 | tail -1 I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. But having worked in large codebases which adopt the same style, and ones that avoid it through static typing and in some cases async/await, the difference in productivity I've noticed in both me and my collaborators is too stark for me to ignore. I think I should've been more nuanced in my comments praising async/await. I believe that what I say is valid in large IO-bound applications which go beyond basic CRUD operations. In general it depends, of course.
- pansa2 2y ago
  > I think the fast and loose style that Python enables is perfect for small scripts and one off data science notebooks and the like. Agreed - I only use Python for scripts like this, preferring statically-typed, AOT-compiled languages for larger programs. That’s why I think Python should have adopted full coroutines - it should play to its strengths and stick to its fast-and-loose style. However, the people who decide how the language evolves are all employees of large companies using it for large codebases - their needs are very different from people who are only using Python for small scripts.