12.10.21 00:03, Guido van Rossum пише:
> 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
On Fri, Oct 15, 2021 at 12:22 PM Pradeep Kumar Srinivasan <
gohan...@gmail.com> wrote:
> Thanks for the responses, everyone. Overall, it seems like there were no
> strong objections to the proposal.
>
> I didn't hear much about Question 2, though: Should we propose features
> beyond present-day
Thanks for the responses, everyone. Overall, it seems like there were no strong
objections to the proposal.
I didn't hear much about Question 2, though: Should we propose features beyond
present-day `Callable` in the same PEP or defer it to a future PEP?
In case that question got lost in the
> On 12 Oct 2021, at 00:09, Erik Demaine wrote:
>
> Another possibility would be that functions can't be used as their types
> directly, but need a casting operator like so:
>
> ```
> def add_converter(self, converter: typeof(data_to_table)) -> None:
> self.converter = converter
>
My apologies! Must be an issue with my email client rendering.
Erik
On Mon, 11 Oct 2021, Guido van Rossum wrote:
On Mon, Oct 11, 2021 at 3:22 PM Erik Demaine wrote:
On Mon, 11 Oct 2021, Guido van Rossum wrote:
No, I didn't write that, Lukasz did.
> I always found the
On Mon, Oct 11, 2021 at 3:22 PM Erik Demaine wrote:
> On Mon, 11 Oct 2021, Guido van Rossum wrote:
>
No, I didn't write that, Lukasz did.
> I always found the following more obvious:
> >
> > def data_to_table(d: Iterable[Mapping[str, float]], *, sort: bool =
> False, reversed: bool = False) ->
On Mon, 11 Oct 2021, Guido van Rossum wrote:
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
1. Barry Warsaw
> This means that any PEP which proposes syntactic changes to support typing
> features must also address the implications of those syntax changes for the
> general Python language. PEP 646 (Variadic Generics) is a good example of
> this. Early on we recognized that the
On Mon, Oct 11, 2021 at 1:52 AM Łukasz Langa wrote:
>
> On 7 Oct 2021, at 18:41, S Pradeep Kumar wrote:
>
> Note that we considered and rejected using a full def-signature syntax
> like
>
> (record: PurchaseRecord, permissions: List[AuthPermission], /) ->
> FormattedItem
>
> because
It isn't clear to me that reusing the inspect.Signature object was even
considered. If it was rejected as too complicated for most signatures, please
put that in the PEP. My own opinion, admittedly not as a typing fan, is that
if you need enough details to want more than Callable, then you
If I can make a wild suggestion: why not create a little language for type
specifications?
If you look at other programming languages you’ll see that the “type definition
sub-language” is often completely different from the “execution sub-language”,
with only some symbols in common and used in
On 11/10/2021 16:45, Steven Troxler wrote:
> https://docs.google.com/document/d/1oCRBAAPs3efTYoIRSUwWLtOr1AUVqc8OCEYn4vKYjGI/edit?usp=sharing
I think ParamSpecs should not have any special syntax. `**P` looks way too much
like kwargs, and any other syntax would be totally new precedent. I'd
On 11/10/2021 17:03, Steven Troxler wrote:
> Personally, I think we should both adopt function-as-a-type and shorthand
> syntax, and reject both the XOR and hybrid syntax because function-as-a-type
> is convenient for expressing the same things (named, default-value, and
> variadic args).
+1
> Is this also why re-using an actual callable at a type was rejected?
The idea to use a function as a type (which Łukasz proposed at the PyCon typing
summit) is still under consideration. Our thought was that it would probably be
a separate PEP from a syntax change.
Personally, I think we
We drew up a draft syntax to clarify the three styles that have been discussed
in typing-sig:
- shorthand syntax, which supports exactly what Callable currently supports
- XOR syntax, which would allow a def-like style in addition to shorthand
- hybrid syntax, which extends shorthand to support
> On 7 Oct 2021, at 18:41, S Pradeep Kumar 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
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
Thanks for summarizing the PSC position, Barry!
I agree that type annotation syntax should be consistent with the rest of
the language, but I'm curious why it has to be "standard Python syntax"?
Could you elaborate a bit more on the reasoning behind that constraint?
Cheers,
Sergei
On Fri, Oct
On Fri, Oct 8, 2021 at 3:36 PM Barry Warsaw wrote:
> On Oct 8, 2021, at 13:02, Sergei Lebedev
> wrote:
> >
> > I agree that type annotation syntax should be consistent with the rest
> of the language, but I'm curious why it has to be "standard Python syntax"?
> Could you elaborate a bit more on
On Oct 8, 2021, at 13:02, Sergei Lebedev wrote:
>
> I agree that type annotation syntax should be consistent with the rest of the
> language, but I'm curious why it has to be "standard Python syntax"? Could
> you elaborate a bit more on the reasoning behind that constraint?
Hi Sergei. I
Thanks for thinking more deeply about how we can make type annotations for
callables more user friendly.
The intersection between the syntax for general Python code and type
annotations has been a topic of discussion within the Steering Council (on and
off) for quite some time. We intend to
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 wrote:
> Thanks for the responses!
>
> 1.
On Fri, 8 Oct 2021 at 16:29, Jelle Zijlstra wrote:
> 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
On Fri, Oct 8, 2021 at 8:31 AM Jelle Zijlstra
wrote:
> El vie, 8 oct 2021 a las 0:54, Paul Moore ()
> 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
El vie, 8 oct 2021 a las 0:54, Paul Moore () escribió:
> On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote:
>
> > Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level
How would this work for a function that returns a function? Would you just put
it on the def line like this?
def foo() -> (int) -> str:
return some_function_from_int_to_str
Or would it have to be:
def foo() -> ((int) -> str): ...
The former is a little confusing to read - at first
07.10.21 19:41, S Pradeep Kumar пише:
> 1. Syntax to replace Callable
>
> After a lot of discussion, there is strong consensus in typing-sig about
> adding syntax to replace Callable. So, the above example would be
> written as:
> ```python
> def print_purchases(
> user: User,
>
On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote:
> Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level feedback from you before putting up a detailed
> PEP.
pt., 8 paź 2021 o 04:48 S Pradeep Kumar napisał(a):
> ...
> 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
On Fri, Oct 8, 2021 at 1:45 PM S Pradeep Kumar wrote:
> The Callable type is also usable as an expression, like in type aliases
> `IntOperator = (int, int) -> int` and `cast((int) -> int, f)` calls.
>
> **Question 1**: Are there concerns we should keep in mind about such a syntax
> proposal?
>
30 matches
Mail list logo
