
On Mon, Oct 11, 2021 at 1:52 AM Łukasz Langa <lukasz@langa.pl> wrote:
On 7 Oct 2021, at 18:41, S Pradeep Kumar <gohanpra@gmail.com> wrote:
Note that we considered and rejected using a full def-signature syntax like ```` (record: PurchaseRecord, permissions: List[AuthPermission], /) -> FormattedItem ```` because it would be more verbose for common cases and could lead to subtle bugs; more details in [3].
Is this also why re-using an actual callable at a type was rejected?
I always found the following more obvious:
def data_to_table(d: Iterable[Mapping[str, float]], *, sort: bool = False, reversed: bool = False) -> Table: ...
@dataclass class Stream: converter: data_to_table | None
def add_converter(self, converter: data_to_table) -> None: self.converter = converter
This solves the following problems with the `(P, Q) -> R` proposal: - how should this look like for "runtime" Python - how should we teach this - how can we express callables with complex signatures
One disadvantage of this is that now arguments HAVE TO be named which raises questions: - should they be considered at type checking time? - how to express "I don't care"?
To this I say: - yes, they should be considered at runtime (because kwargs have to be anyway) - ...unless they begin with an underscore
This still leaves a minor problem that you can't have more than one argument literally named `_` so you'd have to do `_1`, `_2`, and so on. I don't think this is a big problem.
In fact, forcing users to name callable arguments can be added as a fourth advantage to this design: making the annotations maximally informative to the human reader.
The only remaining disadvantage that can't be addressed is that you can't create an *inline* callable type this way. I don't think this is a deal breaker as neither TypedDicts, Protocols, nor for this matter any PlainOldClasses can be defined inline inside a type annotation.
Not everyone on typing-sig has the same preferences. For me personally, your proposal is at best a better syntax for callback protocols, not for inline callback types, precisely because it uses statement-level syntax and requires you to think of a name for the type. It also would cause some confusion because people aren't used for functions to be used as type aliases. If I see A = dict[str, list[int]] it's easy enough to guess that A is a type alias. But if I see def Comparison(a: T, b: T) -> Literal[-1, 0, 1]: ... my first thought is that it's a comparison function that someone hasn't finished writing yet, not a function type -- since if it did have at least one line of code in the body, it *would* be that. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>