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

> 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.

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"

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

I'm not sold on this. Often I type the output I want to get, and reverse the code to get there. and that's faster because it's now all auto completing.

Interesting. 100% of the times I encountered this TypeError, I actually wanted to create the concatenated string. It never caught an actual error.

Now, I guess I'm not against and explicit cast and I can imagine how the error could catch an actual bug. It's painful when the error stops the execution when the string concatenation was intended, but it is not really an issue anymore with the possibility to type check before the execution.

> concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123

Why? This sounds like an opinion to me. String interpolation of formatting features are nice but I find them quite clunky in such simple cases.

Of course when you have to be careful to call str(val), it's arguably as clunky...

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.

Here it is. It only underscores the ambiguity of such handling of the section indexes. Flagging the index error would make this less ambiguous/silent.

I knew a Chinese girl whose parents, surnamed 吕 and 郎, wanted to give her the combined surname 吕郎. This was not allowed, so formally she was surnamed 吕 and given a three-syllable personal name starting with 郎.

There are a couple funny things about this:

1. A personal name of three syllables is stranger than a surname of two.

2. Double-syllable surnames are unusual, but definitely not unheard of. This girl told me that she hadn't been allowed to receive the double surname 吕郎, because it was too long. I asked what would have happened if her double surname had been 司马 instead. "That's different!"

(If the government of China tried to pick a legitimacy fight with the name 司马, it would lose, and everyone knows this.)

So this almost looks like an example of the kind of thing you're referring to, except that the database scheme has nothing to do with it. A surname that was nontraditional but within the technical norms was rejected in favor of a personal name that was both nontraditional and well outside the technical norms.

You're distracted by the parentheses? Really?

And that's readable?

What would you have wraps() do for two functions? Concatenate the docstrings and union of the annotations? Perhaps you want only the latter, that seems like it could easily be its own decorator: `@functools.annotate_intersection(f1, f2, …)`

That makes sense. If you have two functions with identical type signatures, then you should be able to invoke @functools.wraps (or its underlying functools.update_wrapper) such that the annotations are propagated correctly. In this case, that might be as simple as "functools.wraps(assigned=('__annotations__'))".

The rest of what "wraps" does isn't really applicable to what you're trying to do, though: propagating __doc__, __name__ or __module__ etc. isn't really meaningful when combining two functions with different names, as toxik points out.

Coming at it from the other side, you can use typing.ParamSpecs to write a higher-order "wrapper()" that wraps 2 arbitrary functions with identical signatures, like this:

    S = typing.ParamSpec('S')
    R = typing.TypeVar('R')
    def wrapper(func1: typing.Callable[S, R], func2: typing.Callable[S, R]) -> typing.Callable[S, typing.Tuple[R, R]]:
        def inner(**kwargs):
            return func1(**kwargs), func2(**kwargs)
        return inner

You can additionally use typing.Concatenate to indicate additive modifications to those signatures if the two inner signatures aren't the same.

However, what I thought you meant originally is the common problem of deduplicating large/complex function type signatures so you don't have to write them out multiple times or risk drift. In the parent post, consider what would happen if the signatures of "wrapper", "foo", and "bar" were all a) large and b) the same/very similar. Python's answers to that problem are much less good:

1. Duplicate them and write a unit test that ensures that the __annotations__ property of the functions that should have the same signatures remain in sync (or sub/supersets of each other, or whatever you'd prefer). This addresses drift, but requires a testing system and doesn't save the duplicate code.

2. A hack: use object constructors for functions. Write the in-common parts of the signature in the constructor of a parent class, and then put the body of "foo" and "bar" in the __init__ methods of child classes whose instances are not used/are useless, taking advantage of the superclass relationship to indicate to typecheckers that the parameters are all shared. For example, many typecheckers will do the right thing when handed code like this:

    class _Super:
        def __init__(self, arg1: SomeType, arg2: SomeOtherType, ...):
            self.arg1, self.arg2 = arg1, arg2
            
            
    class foo(_Super):  # Bizarre casing is intentional, this is not meant to be used as an instance
        def __init__(self, *args, **kwargs):
             super(*args, **kwargs)
             ...  # Business logic of old "foo()" method goes here, using object fields self.arg1 etc. instead of named variables.
             
    class bar(_Super):  # Bizarre casing is intentional, this is not meant to be used as an instance
        def __init__(self, *args, **kwargs):
             super(*args, **kwargs)
             ...  # Business logic of old "bar()" method goes here, using object fields self.arg1 etc. instead of named variables.
             
    class wrapper(_Super):
        def __init__(self, *args, **kwargs):
            foo(*args, **kwargs)
            bar(*args, **kwargs)

This does solve the duplication problem, and you can use dataclasses with __post_init__ methods for your "foo"/"bar" business logic to smooth out some of the boilerplate and weirdness there, but it remains a very bizarre coding style which substantially trades away readability/familiarity (and performance, if this is on a very hot path) in return for type-checker-friendliness.

3. Use a databag object (ideally an immutable slotted class, dataclass, typing.NamedTuple, [c]attrs, or something of that sort) to encompass all the data that would previously go in your argument signature, so that "wrapper", "foo", and "bar" all end up taking a single such object as their sole argument and accessing fields of that argument to do their work. This is probably (maybe? Lots of Scotsmen in this area...) the most traditionally Pythonic of these options, but is still a far cry from the convenience of something like functools.wraps.

Already doing this. The problem is there are 5 layers in between. Copy and paste the same docstring into all layers is doable but do not seem smart.