7 ms·

After watching this 2018 talk on typing: https://www.youtube.com/watch?v=hWV8t494N88 https://www.youtube.com/watch?v=hWV8t494N88 and this one last year: https:

After watching this 2018 talk on typing: https://www.youtube.com/watch?v=hWV8t494N88 https://www.youtube.com/watch?v=hWV8t494N88 and this one last year: https://www.youtube.com/watch?v=ST33zDM9vOE&t=68s https://www.youtube.com/watch?v=ST33zDM9vOE&t=68s and finally this one in 2021: https://www.youtube.com/watch?v=Lj_9TyT3V98 https://www.youtube.com/watch?v=Lj_9TyT3V98 I think I'll finally start using type checking - it really seems to just eliminate a whole class of potential bugs; a class that is often not tested at that.

kbmunchkin 5y ago
I've never had problems that strong typing would have prevented and see no use for them in languages that originally didn't provide them. They add noise to the code and require more effort in reading around them.
jeeeb 5y ago
I started a new project in Python in late 2019. Coming from a C++/Java background I elected from the start to use type checking and data classes heavily. The project has now scaled to multiple developers and many thousands of lines of code. If I compare my experiences this time around with past experiences in Python, I feel those early choices are paying big dividends in terms of code readability and correctness. In particular: The ergonomics of data classes is great (IMO). They avoid a lot of boiler plate, integrate well with type checking and auto completion, and provide clear context to anyone reading the code. I’ve found Mypy a bit flaky (sometimes it misses errors it seemingly should catch) and some things that cannot be expressed in the type system to be pain points but overall having type annotations present and enforced helps document code, works well with IDE auto completion, and occasionally picks up errors that would have been otherwise missed. In particular I’ve found it’s picked up a lot of errors around missing None checks (nullability). These seem to be particularly easy to miss in unit tests. I’ve also found that PyCharm’s built in code code checking has often been able to pick up and highlight problems which it would have otherwise missed thanks to having type annotations. Having early feedback on problems is nice productivity boost. One hint if you do use Mypy make sure to enable check-untuned-defs. You’ll get much better coverage.
BiteCode_dev 5y ago
Above all, it's much more usable now, especially with 3.10 around the corner: - you can use list[] instead of typing.List[]. Same for dicts or sets. - you will be able to use bool | str instead of typing.Union[bool, str] - mypy has saner default, is better supported by IDE and is way faster - a lot of edge cases are now covered, including protocols for duck typing, vartype, etc. - fantastic libs such as pydantic, fastapi and typer make using them a ton of fun
goodoldneon 5y ago
We added mypy last year and it’s been a huge benefit. It catches a lot of bugs and makes onboarding easier. However, mypy is woefully limited when compared to TypeScript. Granted, TypeScript is maintained by a trillion dollar company while mypy is a community project.
wonton53 5y ago
Great! I am so glad more people see types as a useful tool. Personally I see it as essential, so I struggle to understand the mind set of people who do not want to use them. I understand that people think it feels like a lot of work, but that is like nothing compared to the 90% of time people who dont use types spend on reading logs and fixng the same issues every day. I assume people have some sort of amnesia and thinking «oh the value was undefined, I have never seen THAT error before», but that is probably just me being bitter. So I was wondering, since you seem like a super-fresh converted;did you have any specific reservations originally, and whas there any specific type of solution to a issue that finally changed your mind?
- cuddlybacon 5y ago
  > I struggle to understand the mind set of people who do not want to use them. I've posted a few reasons before. I think I've refined the list slightly since last time: * People's first exposure to programming often came from using C++ or Java. An old version with really crappy type errors. Schools are often conservative about updating their tech stacks. * Types are most useful when reading or changing code. New learners are mostly writing new code. * Writing `Person person = new Person()` seems highly redundant. In the kinds of small programs you are writing as a newbie, you are likely to write a lot of this. The reasons so far make types seem like overhead: you are having to do more work and getting little in return for doing so. The next two get a bit deeper. * In the small codebases you'll have as a newbie[0] at disproportionate amount of the codebase is interacting with the outside world. The outside world is untyped. In both typed or dynamic languages, you have to shuttle this untyped data into your language's type system. But when there is a type error in this process, I find it is generally easier to debug in a dynamic language. That makes sense to me: they need to have good workflows for dealing with runtime type errors. * Classes tend not to teach technique[1]. Students are expected to invent it on their own as they learn programming. As professionals, we often don't teach technique to each other either. If you invent techniques that leverage the strengths of types, then the appeal of types will seem pretty obvious. If you don't you may go years without before you are exposed to these techniques. If you invent techniques where static types get in the way, then you may find static types to be a severe hindrance to getting things done. [0] I think this also applies a lot of the time when starting a new project. [1] By technique I mean the steps you do to produce working code. This doesn't just include generating new code, but understanding existing code and debugging code.
heavyset_go 5y ago
Use an editor with an LSP client, along with pyls-mypy[1], and you'll get type checking support as you write your code. I just use the typing module and not Mypy, and it still works great. [1] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy
travisgriggs 5y ago
I like typing in Python because I can choose how much I want to use it. If I want to script something, or prototype something, or test something in a repl, no overhead of typing needed. It's also been my experience (C(++), Kotlin, Swift) that as the complexity of typing increases, 10% of the time I spend servicing types accounts for 90% of the sites I need typing, and the other 90% of the time spent on types is me cursing at the compiler trying to make it accept the odd 10%. An optional type annotation system allows ME to pick where I want that effort/payback balance to be at on a case by case basis.
tiew9Vii 5y ago
The thing with Python types is that they are “type hints” and not true types, hints is the keyword. There’s also two type checker implementations. As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. The paper “Python 3 types in the wild” at https://news.ycombinator.com/item?id=26788177 https://news.ycombinator.com/item?id=26788177 is a good read. I enjoyed reading it and found it useful. I’m a fan of types as the compiler tells me I made a mistake and blocks me making mistakes. You can use the type system to make certain errors unrepeatable (impossible to make). With that my preference is use a language where types are first class rather than a language trying to retrofit some loose form of type checking on top which is nothing more than linting. Being a fan of strongly typed languages I was eager to use types in Python when I had to involuntarily use Python. After a few instances of putting in type hints and things type checking when they shouldn’t I mainly don’t bother with them now outside of data classes as they where not catching bugs I wanted so still getting runtime errors.
- joshuamorton 5y ago
  > As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. Could you elaborate. When can you pass in wrong values? The type checkers aren't always precisely the same (some do inference, mypy doesn't), but the cases where they disagree are usually because one is correct and one wants more information, not because you're able to do the wrong thing despite having annotations.
  - takeda 5y ago
    I believe GP means that they are not checked at runtime. But I don't think that matters much in case of finding bugs, because you run mypy and it will scream that you are assigning wrong type. I use it whenever I can and it helped me find many bugs in the code (especially not checking if value is None through the Optional). It also makes refactoring your code in IDEs that understand types (like PyCharm) much much easier.
rychco 5y ago
I personally don’t think Python type hints are particularly useful for solo projects, but are very useful for communicating the intent of my code to others.
- ehsankia 5y ago
  Sometimes, "others" is yourself in a few months trying to look at the code :) If my project is something beyond a small script that I plan on working on on or off for a while, I do find that annotations definitely help. Also, it fuels IDE completions between functions if you annotate your input.
fulafel 5y ago
Is this eliminated class of bugs just generally the ones that aren't caught by tests but could be caught by static type annotations, or was there a discussion of the kinds of bugs that had some convincing details?
- aix1 5y ago
  I think there's considerable overlap between classes of bugs that could be caught by static type checking and those that could be caught by unit tests. That said, I view the two as complementary and use both extensively. One particularly interesting (though in my experience, rare) class of bugs are typing errors _in unit tests_. For example, an API under test expects one thing and a unit test supplies something else. If the test passes, it's hard to spot the problem without static type checking.

kbmunchkin 5y ago

I've never had problems that strong typing would have prevented and see no use for them in languages that originally didn't provide them. They add noise to the code and require more effort in reading around them.

jeeeb 5y ago

I started a new project in Python in late 2019. Coming from a C++/Java background I elected from the start to use type checking and data classes heavily. The project has now scaled to multiple developers and many thousands of lines of code. If I compare my experiences this time around with past experiences in Python, I feel those early choices are paying big dividends in terms of code readability and correctness. In particular: The ergonomics of data classes is great (IMO). They avoid a lot of boiler plate, integrate well with type checking and auto completion, and provide clear context to anyone reading the code. I’ve found Mypy a bit flaky (sometimes it misses errors it seemingly should catch) and some things that cannot be expressed in the type system to be pain points but overall having type annotations present and enforced helps document code, works well with IDE auto completion, and occasionally picks up errors that would have been otherwise missed. In particular I’ve found it’s picked up a lot of errors around missing None checks (nullability). These seem to be particularly easy to miss in unit tests. I’ve also found that PyCharm’s built in code code checking has often been able to pick up and highlight problems which it would have otherwise missed thanks to having type annotations. Having early feedback on problems is nice productivity boost. One hint if you do use Mypy make sure to enable check-untuned-defs. You’ll get much better coverage.

BiteCode_dev 5y ago

Above all, it's much more usable now, especially with 3.10 around the corner: - you can use list[] instead of typing.List[]. Same for dicts or sets. - you will be able to use bool | str instead of typing.Union[bool, str] - mypy has saner default, is better supported by IDE and is way faster - a lot of edge cases are now covered, including protocols for duck typing, vartype, etc. - fantastic libs such as pydantic, fastapi and typer make using them a ton of fun

goodoldneon 5y ago

We added mypy last year and it’s been a huge benefit. It catches a lot of bugs and makes onboarding easier. However, mypy is woefully limited when compared to TypeScript. Granted, TypeScript is maintained by a trillion dollar company while mypy is a community project.

wonton53 5y ago

Great! I am so glad more people see types as a useful tool. Personally I see it as essential, so I struggle to understand the mind set of people who do not want to use them. I understand that people think it feels like a lot of work, but that is like nothing compared to the 90% of time people who dont use types spend on reading logs and fixng the same issues every day. I assume people have some sort of amnesia and thinking «oh the value was undefined, I have never seen THAT error before», but that is probably just me being bitter. So I was wondering, since you seem like a super-fresh converted;did you have any specific reservations originally, and whas there any specific type of solution to a issue that finally changed your mind?

cuddlybacon 5y ago
> I struggle to understand the mind set of people who do not want to use them. I've posted a few reasons before. I think I've refined the list slightly since last time: * People's first exposure to programming often came from using C++ or Java. An old version with really crappy type errors. Schools are often conservative about updating their tech stacks. * Types are most useful when reading or changing code. New learners are mostly writing new code. * Writing `Person person = new Person()` seems highly redundant. In the kinds of small programs you are writing as a newbie, you are likely to write a lot of this. The reasons so far make types seem like overhead: you are having to do more work and getting little in return for doing so. The next two get a bit deeper. * In the small codebases you'll have as a newbie[0] at disproportionate amount of the codebase is interacting with the outside world. The outside world is untyped. In both typed or dynamic languages, you have to shuttle this untyped data into your language's type system. But when there is a type error in this process, I find it is generally easier to debug in a dynamic language. That makes sense to me: they need to have good workflows for dealing with runtime type errors. * Classes tend not to teach technique[1]. Students are expected to invent it on their own as they learn programming. As professionals, we often don't teach technique to each other either. If you invent techniques that leverage the strengths of types, then the appeal of types will seem pretty obvious. If you don't you may go years without before you are exposed to these techniques. If you invent techniques where static types get in the way, then you may find static types to be a severe hindrance to getting things done. [0] I think this also applies a lot of the time when starting a new project. [1] By technique I mean the steps you do to produce working code. This doesn't just include generating new code, but understanding existing code and debugging code.

heavyset_go 5y ago

Use an editor with an LSP client, along with pyls-mypy[1], and you'll get type checking support as you write your code. I just use the typing module and not Mypy, and it still works great. [1] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy

travisgriggs 5y ago

I like typing in Python because I can choose how much I want to use it. If I want to script something, or prototype something, or test something in a repl, no overhead of typing needed. It's also been my experience (C(++), Kotlin, Swift) that as the complexity of typing increases, 10% of the time I spend servicing types accounts for 90% of the sites I need typing, and the other 90% of the time spent on types is me cursing at the compiler trying to make it accept the odd 10%. An optional type annotation system allows ME to pick where I want that effort/payback balance to be at on a case by case basis.

tiew9Vii 5y ago

The thing with Python types is that they are “type hints” and not true types, hints is the keyword. There’s also two type checker implementations. As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. The paper “Python 3 types in the wild” at https://news.ycombinator.com/item?id=26788177 https://news.ycombinator.com/item?id=26788177 is a good read. I enjoyed reading it and found it useful. I’m a fan of types as the compiler tells me I made a mistake and blocks me making mistakes. You can use the type system to make certain errors unrepeatable (impossible to make). With that my preference is use a language where types are first class rather than a language trying to retrofit some loose form of type checking on top which is nothing more than linting. Being a fan of strongly typed languages I was eager to use types in Python when I had to involuntarily use Python. After a few instances of putting in type hints and things type checking when they shouldn’t I mainly don’t bother with them now outside of data classes as they where not catching bugs I wanted so still getting runtime errors.

joshuamorton 5y ago
> As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. Could you elaborate. When can you pass in wrong values? The type checkers aren't always precisely the same (some do inference, mypy doesn't), but the cases where they disagree are usually because one is correct and one wants more information, not because you're able to do the wrong thing despite having annotations.
- takeda 5y ago
  I believe GP means that they are not checked at runtime. But I don't think that matters much in case of finding bugs, because you run mypy and it will scream that you are assigning wrong type. I use it whenever I can and it helped me find many bugs in the code (especially not checking if value is None through the Optional). It also makes refactoring your code in IDEs that understand types (like PyCharm) much much easier.

rychco 5y ago

I personally don’t think Python type hints are particularly useful for solo projects, but are very useful for communicating the intent of my code to others.

ehsankia 5y ago
Sometimes, "others" is yourself in a few months trying to look at the code :) If my project is something beyond a small script that I plan on working on on or off for a while, I do find that annotations definitely help. Also, it fuels IDE completions between functions if you annotate your input.

fulafel 5y ago

Is this eliminated class of bugs just generally the ones that aren't caught by tests but could be caught by static type annotations, or was there a discussion of the kinds of bugs that had some convincing details?

aix1 5y ago
I think there's considerable overlap between classes of bugs that could be caught by static type checking and those that could be caught by unit tests. That said, I view the two as complementary and use both extensively. One particularly interesting (though in my experience, rare) class of bugs are typing errors _in unit tests_. For example, an API under test expects one thing and a unit test supplies something else. If the test passes, it's hard to spot the problem without static type checking.