Pradeep, Thanks for all the clarifications. I think it's time that you put together a formal grammar. That should also make clear that "(,) -> int" is disallowed while "(int,) -> int" is allowed.
--Guido On Fri, Oct 8, 2021 at 8:50 AM S Pradeep Kumar <gohan...@gmail.com> wrote: > 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 > -- --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/MG7XKB5AZ556UGWPW2QNAUEO67OQPKUB/ Code of Conduct: http://python.org/psf/codeofconduct/
