61–70 of 158 posts
Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.
It is used when the number of argument can vary, like: def sum(*args: int) -> int: if len(args) == 0: return 0 return args[0] + sum(*args[1:])
Although these two comes in handly, people have been using them wrong. Often in scientific open source package, they slap *kwargs in function definition without documentation. How am I suppose to know what to pass in? https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives...
Earlier quoted context omitted.
What do you do when inheriting from a base class with a defined __init__ ?
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…
Earlier quoted context omitted.
> Then why doesn’t a[1] return None? Because there would be no way to distinguish between "a[1] contains None" and "a[1]" doesn’t exist.
And with a[1:] returning the empty list there’s no way to distinguish between a is empty and a only has one element. These are, in the end, relatively arbitrary language design decisions.
Is it just me or are Python type hints like..goofy?
Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.
If you have enough arguments that the signature becomes obscure to read you need a dataclass to pass into the function instead. I would rather: @dataclass(frozen=True, slots=True) class VarThings: n: int ... def variable(a: VarThings): ... Than a million args
Earlier quoted context omitted.
And with a[1:] returning the empty list there’s no way to distinguish between a is empty and a only has one element. These are, in the end, relatively arbitrary language design decisions.
When you slice a list, you get a list. When you see there is nothing inside the returning list, you know that means end of list, contains zero element. Slicing and indexing return object at different level.
Earlier quoted context omitted.
It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple.
> It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple. `a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.
This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section.
Earlier quoted context omitted.
It is used when the number of argument can vary, like: def sum(*args: int) -> int: if len(args) == 0: return 0 return args[0] + sum(*args[1:])
You should use `Iterable`
print(firstname, lastname)
print((firstname, lastname))
print((surname,))
Variadic functions are rather classic, I think Go, Rust, C and JavaScript also have them.
For typing **kwargs there are TypedDicts https://peps.python.org/pep-0692/ If your function just wraps another you can use the same type hints as the other function with functools.wraps https://docs.python.org/3/library/functools.html#functools.w...
While functools.wraps does propagate __annotations__ by default, be aware that not all IDE-integrated type checkers handle that properly. It's easy in PyCharm, for example, to use functools.wraps such that the wrapper function is treated by the IDE as untyped. Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead p…
I recently switched from Pycharm to vscode which uses pyright and it's night and day on the amount of type errors it catches, it considerably improved the quality of my code and confidence during refactoring.
And to add insult to injury Pycharm doesn't even have a pyright plugin and the mypy plugin is extremely slow and buggy.