Thanks for the responses!
1. Chris Angelico:
> it looks like the parentheses are mandatory, and they are what define it?
Yes, we always expect parens. Like you said, this keeps things consistent,
resembles the function signature, and avoids ambiguities. It also won't
look like Haskell function types `int -> str -> bool` (which can be
confusing for non-functional programmers).
This was pretty explicitly rejected when we polled people at the Typing
Summit.
> Which of these will be valid?
(int) -> int
(int, int) -> int
(int,) -> int should also be fine, but I don't have strong opinions here.
e.g., what about (,) -> int? We'll make sure to address this edge case
explicitly, thanks.
> There are parallel proposals to support a lambda syntax like "x =>
x.spam" as equivalent to "lambda x: x.spam", so I'm curious what the rules
would be for the two types of arrows, and whether they'd be consistent with
each other.
Yeah, this had come up in our discussions. Like in other languages (such as
Hack), we believe that lambdas should have a different arrow type to
disambiguate the two. So, lambdas could be (x, y) => x + y.
2. Piotr Duda
> Did you considered full def-signature with optional argument names, so
the common cases would look like
>
> ````
> (:PurchaseRecord, :List[AuthPermission]) -> FormattedItem
> ````
> Bare name signatures like '(record) -> FormattedItem' could be disallowed
to prevent bugs.
The additional-features proposal in (2) actually does have optional
parameter names. There are two variants:
(a) the "hybrid" proposal, which will let you write (int, str) -> bool, but
also hybrids like (int, y: str) -> bool; (x: int, y: str) -> bool; (int,
str=...) -> bool.
(b) the "xor" proposal, which will let you use the shorthand syntax (int,
str) -> bool for the most frequently-used cases and the full def-signature
for all other advanced cases using familiar syntax: (x: int, y: str=...) ->
bool.
We haven't reached a strong consensus on the above two yet (flexibility vs
familiarity). We decided to get some thoughts here about whether we need to
propose additional-features at all (2) in our initial PEP.
3. Patrick Reader
> How would this work for a function that returns a function? Would you
just put it on the def line like this?
We will allow using the callable syntax in the return type without parens:
def foo() -> (int) -> str:
return int_to_str
The reason for not making that a syntax error is that it would be pretty
bad UX. Users would see the callable syntax being used without parens
everywhere: f: (int) -> str, but when they try to use that as the return
type, they would get a confusing syntax error. So, given how frequently
functions return functions, we decided to not require parens.
People can specify parens in their coding guidelines (and auto-formatters)
if they find parens more readable.
4. Paul Moore
+1 to what Jelle said.
> That's one of the differences between the proposals discussed here. The
basic proposal Pradeep pointed out would not support named arguments, the
more complete syntax favored by Guido (and also by me; 2(a) in Pradeep's
email) would support it.
>
> Pradeep has done some empirical analysis that shows that in practice it
is not very common to use such types, though.
Yeah, that's basically Question 2 - whether to just replace Callable in the
initial PEP (option 1) or to specify a more complete syntax from the
beginning (option 2).
5. Serhiy Storchaka
> How could you replace Callable[..., int] and Callable[Concatenate[str,
P], int] ?
To represent a Callable that accepts arbitrary arguments:
(...) -> int
To represent a Callable that accepts ParamSpec (for decorators, etc.),
we're leaning towards the below:
(**P) -> int
To represent your Concatenate example:
(str, **P) -> int
We would no longer need the Concatenate operator. We can naturally just add
types up front.
--
S Pradeep Kumar
On Fri, Oct 8, 2021 at 8:48 AM Guido van Rossum <gu...@python.org> wrote:
> On Fri, Oct 8, 2021 at 8:31 AM Jelle Zijlstra <jelle.zijls...@gmail.com>
> wrote:
>
>> El vie, 8 oct 2021 a las 0:54, Paul Moore (<p.f.mo...@gmail.com>)
>> escribió:
>>
>>> Also, note that I automatically used a type of int->int up there. As
>>> someone else asked, is that form allowed, or is it required to be
>>> (int)->int? In my view, if we require the latter, I expect there will
>>> be a *lot* of people making that mistake and having to correct it.
>>>
>>
>> That's not something we discussed before. I'd be OK with allowing this
>> unless it makes the grammar too ambiguous.
>>
>
> Even if it didn't make the grammar ambiguous (and I think it doesn't, as
> long as the argument type isn't a union or another callable type), I'd be
> against this.
>
> An argument list is not a tuple, and we don't allow omitting the
> parentheses in other call-related situations: you can't write "def f x:
> return x+1" and you can't write "f 42". Allowing the omission of the
> parentheses here would be inconsistent (even if some other languages allow
> it).
>
> --
> --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/>
>
--
S Pradeep Kumar
_______________________________________________
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/C7PTQ5A3CXKWRKCTQLIXFTDG2K2MMBN5/
Code of Conduct: http://python.org/psf/codeofconduct/
