On Mon, Oct 11, 2021 at 1:52 AM Łukasz Langa <luk...@langa.pl> wrote:
>
> On 7 Oct 2021, at 18:41, S Pradeep Kumar <gohan...@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-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TNX4KO4BWA2MJE5BNX5PHBY7QOZTYERX/
Code of Conduct: http://python.org/psf/codeofconduct/
