Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Type Hints – *args and **kwargs (2021)

adamj.eu

Post reply on HN
Print view View original

121–130 of 158 posts

Re: Python Type Hints – *args and **kwargs (2021)

#121

Post by throwaway2037 »

LBTables wrote: post #115
bowsamic wrote: post #89

Earlier quoted context omitted.

This is why I hate Python, absolutely none of this is obvious from the design of the language

At an even more basic level, the lack of static typing seems like such a tradeoff getting an incredibly huge nuisance in readability and stupid runtime bugs that shouldn't be a thing in exchange for a feature that's rarely useful. Granted, I'm primarily an embedded developer. Can any Python experts explain to me a highly impactful benefit of dynamic typing?

For small programs, dynamic typing can be faster to write (not read). As soon as your program grows: "uh oh". Once you add maintenance into the cost equation, dynamic typing is a huge negative.

To be fair: 15 years ago, people were writing a lot of Java code that effectively used dynamic typing by passing around Object references, then casting to some type (unknowable to the reader) when using. (C#: Same.) It was infuriating, and also very difficult to read and maintain. Fortunately, most of that code is gone now in huge enterprise code bases.

Re: Python Type Hints – *args and **kwargs (2021)

#122

Post by throwaway2037 »

dontlaugh wrote: post #87
yayachiken wrote: post #38

Earlier quoted context omitted.

For everybody reading this and scratching their head why this is relevant: Python subclassing is strange. Essentially super().__init__() will resolve to a statically unknowable class at run-time because super() refers to the next class in the MRO. Knowing what class you will call is essentially unknowable as soon as you accept that either your provider class hierarchy may change or you have consumers you do not contr…

Having used Python a lot, I was never glad for multiple inheritance. I’d prefer traits.

Are traits and mixins the same? If not, can you please provide a trivial example. It would be useful to better understand what you mean. When I was very young, learning C++, I thought multiple inheritance was so cool. Now, I know it is like sleeping in the open jaws of a saltwater croc.

Re: Python Type Hints – *args and **kwargs (2021)

#123

Post by throwaway2037 »

dragonwriter wrote: post #92
hk__2 wrote: post #36

> In the function body, args will be a tuple, and kwargs a dict with string keys. This always bugs me: why is `args` immutable (tuple) but `kwargs` mutable (dict)? In my experience it’s much more common to have to extend or modify `kwargs` rather than `args`, but I would find more natural having an immutable dict for `kwargs`.

> This always bugs me: why is `args` immutable (tuple) but `kwargs` mutable (dict)? Because python didn’t (still doesn’t, but at this point even if it did backward compatibility would mean it wouldn’t be used for this purpose) have a basic immutable mapping type to use. (Note, yes, MappingProxyType exists, but that’s a proxy without mutation operations, not a basic type, so it costs a level of indirection.)

In Python, except for mutability, is there any difference between tuple and list? In my experience: Pure Python people get so excited about tuples ("oh, it's so Pythonic"); others: much less.

Re: Python Type Hints – *args and **kwargs (2021)

#125

Post by seanhunter »

veber-alex wrote: post #113
krick wrote: post #110

Earlier quoted context omitted.

Any examples? I don't write Python that much nowadays, and while I'm sure its type checker doesn't do everything , I kinda never felt disappointed by what it does. Maybe, a considerable part of that is that I still don't really think of Python as a type-checked language, so everything an IDE does for me still feels like quite a bit of an improvement over how I used to write code in Python for a long, long time. But r…

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error. def foo() -> int: pass I sure hope they improved the type checker in later versions...

That’s not a type error in python. All types in puthon (afaik) accept ‘None’ as a value.

For example, try:

   a : int = None
It will succeed. This is done (I think) so you can tell whether optional arguments are defined, declare variables before use (eg if you have a conditional with two branches both setting a different value for a variable sibce python blocks aren’t expressions) and that kind of thing.

Re: Python Type Hints – *args and **kwargs (2021)

#126

Post by veber-alex »

seanhunter wrote: post #125
veber-alex wrote: post #113

Earlier quoted context omitted.

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error. def foo() -> int: pass I sure hope they improved the type checker in later versions...

That’s not a type error in python. All types in puthon (afaik) accept ‘None’ as a value. For example, try: a : int = None It will succeed. This is done (I think) so you can tell whether optional arguments are defined, declare variables before use (eg if you have a conditional with two branches both setting a different value for a variable sibce python blocks aren’t expressions) and that kind of thing.

Each type checker can implement however strict rules it wants. And pyright gives the correct answer here:

  Expression of type "None" cannot be assigned to declared type "int"
    Type "None" cannot be assigned to type "int"

Re: Python Type Hints – *args and **kwargs (2021)

#127

Post by veber-alex »

mathisfun123 wrote: post #117
veber-alex wrote: post #113

Earlier quoted context omitted.

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error. def foo() -> int: pass I sure hope they improved the type checker in later versions...

Um lol what do you think the error is here? This is widely accepted syntax for a stub. So yes it does return None if run but it's not expected to ever be run. So pretty ironic that you would blame pycharm (which is indeed excellent) for your own misunderstanding. https://mypy.readthedocs.io/en/stable/stubs.html#using-stub-...

> Um lol what do you think the error is here? This is widely accepted syntax for a stub.

No it isn't. The accepted stub syntax is an ellipses (...).

A competent type checker like pyright will error on this code.

  Function with declared return type "int" must return value on all code paths
    Type "None" cannot be assigned to type "int"
And if you need more proof that pycharm is useless as a type checker:

  def foo(b) -> int:
      if b:
          return 1
A classic error where you forget to return a value from all paths and pycharm is silent.

Re: Python Type Hints – *args and **kwargs (2021)

#128

Post by Skeime »

throwaway2037 wrote: post #120
bowsamic wrote: post #89

Earlier quoted context omitted.

This is why I hate Python, absolutely none of this is obvious from the design of the language

To add to your list: During string concatenation, there is no automatic conversion to string. It results in an exception. It is infuriating. This code: "abc" + 123 ... will raise this exception: TypeError: can only concatenate str (not "int") to str I have wasted so many hours fixing this same bug, over and over again.

I strongly disagree. Not converting the int to a string automatically is absolutely the right decision. In all code I write, this TypeError would catch an actual error, because concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123, so I would not use it for that. Hence, if this exception occurs, it indicates that I probably mixed up variables somewhere. Use one of the (admittedly too) many string formatting tools that Python offers, for example an f-string like f"abc{123}". (Also, if you have enough type annotations in your code, the type checker will warn you about these, so you can fix them before they hit testing or even production.)

Re: Python Type Hints – *args and **kwargs (2021)

#129

Post by SushiHippie »

seanhunter wrote: post #125
veber-alex wrote: post #113

Earlier quoted context omitted.

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error. def foo() -> int: pass I sure hope they improved the type checker in later versions...

That’s not a type error in python. All types in puthon (afaik) accept ‘None’ as a value. For example, try: a : int = None It will succeed. This is done (I think) so you can tell whether optional arguments are defined, declare variables before use (eg if you have a conditional with two branches both setting a different value for a variable sibce python blocks aren’t expressions) and that kind of thing.

It's not recommended anymore. Optional types should be explicit. https://peps.python.org/pep-0484/#union-types

Re: Python Type Hints – *args and **kwargs (2021)

#130

Post by hk__2 »

throwaway2037 wrote: post #123
dragonwriter wrote: post #92

Earlier quoted context omitted.

> This always bugs me: why is `args` immutable (tuple) but `kwargs` mutable (dict)? Because python didn’t (still doesn’t, but at this point even if it did backward compatibility would mean it wouldn’t be used for this purpose) have a basic immutable mapping type to use. (Note, yes, MappingProxyType exists, but that’s a proxy without mutation operations, not a basic type, so it costs a level of indirection.)

In Python, except for mutability, is there any difference between tuple and list? In my experience: Pure Python people get so excited about tuples ("oh, it's so Pythonic"); others: much less.

> In Python, except for mutability, is there any difference between tuple and list? In my experience: Pure Python people get so excited about tuples ("oh, it's so Pythonic"); others: much less.

In my experience, people who don’t care about tuples are people who don’t understand them. It’s not much about being Pythonic or not (they exists in other languages) but rather about choosing the right data structure for solving your problem. Tuples are much more than a way of making immutable lists, they offer a type-safe and serializable representation of pairs and triplets; something you can’t have with a list. If you don’t use them yet, I really encourage you to document yourself (and again-- in general, not just in Python) because you’re missing something.

Post reply on HN