On Thu, Dec 16, 2021 at 6:57 PM Steven Troxler wrote:
>
> Hello all,
>
> Thanks everyone for comments on our earlier thread [1] about callable type
> syntax. We now have a draft PEP [2] proposing an arrow-based syntax for
> callable types, for example:
>
> ```
> (int, str) -> bool #
To me, these are mostly convincing examples that people need to name
parts of a complex type like this :-)
I don't actually find any of the syntaxes better than any other. They
are all a bit bad, but I view that as the fault of the complex nested
types, not the syntax (hence my preference for
In the example I was aiming for something easy to understand that produced a
type illustrating potential problems of PEP 677, which is at its worst when
there are callables in both argument and return position. I don't have a great
real-world example of this worst-case, most of what I've seen
Ahah, that makes sense. But then I think I buy into your reasoning that this
isn't really a replacement for callable syntax (although functions as types
opens up other interesting possibilities). For this and other reasons I'd hate
to see callable syntax rejected in favor of it, so definite +1
I agree with what Batuhan said. Adding on, I'm very concerned about the
potential maintenance burden for Python implementations.
Just for typing in CPython, some combination of the following knowledge is
required to contribute code:
1. Metaclasses
2. Descriptors and CPython dunders
3. C
On Tue, 21 Dec 2021 at 18:35, Steven Troxler wrote:
>
> I've been thinking about readability hard because I share many of your
> concerns about readability.
Before I comment on syntax, I'd like to question the example:
> An example
> =
>
> The function
>
>
> To get at
I've been thinking about readability hard because I share many of your concerns
about readability.
I'm starting to think parenthesizing the outside might work much better in
practice:
```
(int, str -> bool)
```
instead of
```
(int, str) -> bool
```
This looks a bit less familiar, but it
-
In most of our discussions of this idea, we've assumed that we'd adopt the same
semantics that callback protocols use.
If we do that, then only `lambda a: 3` will type check. In order to type check
both you'd have to make `a` positional-only:
```
def IntToIntFunc(a: int, /) -> int:
...
```
I don’t see how this helps much in situations with nested callables which are
very common for decorators. I’m also unsure how this will work with situations
where input and output are both callables and the signature is modified using
paramspec. An example would be a decorator that adds/removes
Does `lambda b: 3` type check with `IntToIntFunc` or only `lambda a: 3`? The
intent seems to be it's more like `Callable` (where the argument name is not
important), but maybe both could be supported? I wonder about making more use
of the `_` soft keyword where calling a function with multiple
On 20/12/2021 22:34, Serhiy Storchaka wrote:
> 20.12.21 21:28, Brett Cannon пише:
>> As someone with use of this, would you find this useful (i.e. +1, +0)?
>> Serhiy already said "no" in another thread.
> In every file we import 5-10 or more names from the typing module. We
> still does not use
Yeah, making the body optional (without looking at decorators) is not
acceptable either. Too easy to do by mistake (I still do this All. The.
Time. :-)
On Mon, Dec 20, 2021 at 2:19 PM wrote:
> My proposal wasn't to make the body optional based on the presence of a
> decorator, but rather to
Thanks for the feedback. I have a few thoughts.
(1) Concerns about complexity of the syntax make sense to me, it's definitely
possible to write confusing types with this syntax. Readability would be a good
reason to reject this idea, but it does cut both ways because `Callable` can be
hard to
20.12.21 21:28, Brett Cannon пише:
> As someone with use of this, would you find this useful (i.e. +1, +0)?
> Serhiy already said "no" in another thread.
In every file we import 5-10 or more names from the typing module. We
still does not use PEP 585 and PEP 604 syntax, but are going to do this
My proposal wasn't to make the body optional based on the presence of a
decorator, but rather to return a "function prototype" iff the body does not
exist (I probably should have made my made my own reply instead of piggybacking
on his proposal). I also mentioned some form of expression to
On Mon, Dec 20, 2021 at 12:44 PM wrote:
> This is such a great idea that I think it deserves its own PEP (to compete
> with this one?) Let me explain. PEP 677 was created for the sole purpose of
> replacing typing.Callable, but there are still some other areas where
> function metadata is
This is such a great idea that I think it deserves its own PEP (to compete with
this one?) Let me explain. PEP 677 was created for the sole purpose of
replacing typing.Callable, but there are still some other areas where function
metadata is required. What if we instead introduced a function
As someone with use of this, would you find this useful (i.e. +1, +0)?
Serhiy already said "no" in another thread.
On Mon, Dec 20, 2021 at 4:38 AM Andrew Svetlov
wrote:
> Perhaps Serhiy did more accurate counting, my estimate is very rough.
>
> On Mon, Dec 20, 2021 at 2:15 PM Serhiy Storchaka
On Mon, Dec 20, 2021 at 3:44 AM Mark Shannon wrote:
> Hi,
>
> Why not make Callable usable as a function decorator?
>
>
>
> The motivating example in the PEP is this:
>
>
> def flat_map(
> l: list[int],
> func: Callable[[int], list[int]]
> ) -> list[int]:
>
>
>
> Since, as
On Sun, Dec 19, 2021 at 8:26 PM Christopher Barker
wrote:
>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>>
>> > tl;dr: I find it very troubling that we are going on a path where need
>> > to increase the language complexity (syntax) only in the cause
>> > 'easier' typing.
>
>
> Which brings
Perhaps Serhiy did more accurate counting, my estimate is very rough.
On Mon, Dec 20, 2021 at 2:15 PM Serhiy Storchaka
wrote:
> 20.12.21 13:42, Mark Shannon пише:
> > OOI, of those 1577 Callable type hints, how many distinct Callable types?
>
> Around 15-20%. Most of them are in tests which
20.12.21 13:42, Mark Shannon пише:
> OOI, of those 1577 Callable type hints, how many distinct Callable types?
Around 15-20%. Most of them are in tests which widely use pytest
fixtures, so functions taking and returning callables are common. There
are around 200 occurrences in non-test code, half
On Mon, Dec 20, 2021 at 1:42 PM Mark Shannon wrote:
> OOI, of those 1577 Callable type hints, how many distinct Callable types?
>
>
Good question. About 30 callables for source code itself and an additional
60 for pytest factory fixtures.
> On 20/12/2021 7:52 am, Andrew Svetlov wrote:
> > At
OOI, of those 1577 Callable type hints, how many distinct Callable types?
On 20/12/2021 7:52 am, Andrew Svetlov wrote:
At my job, we have 1577 Callable type hints scattered in 1063 Python files.
For comparison, this codebase also has 2754 dict annotations and 1835 list ones.
On Mon, Dec 20,
Hi,
Why not make Callable usable as a function decorator?
The motivating example in the PEP is this:
def flat_map(
l: list[int],
func: Callable[[int], list[int]]
) -> list[int]:
Since, as the PEP claims, `Callable[[int], list[int]]` is hard to read, then
give it a name
18.12.21 23:07, Terry Reedy пише:
> Batuhan expresses my concerns better than I could, so I just add my
> agreement.
>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
>> tl;dr: I find it very troubling that we are going on a path where need
>> to increase the language complexity (syntax) only
At my job, we have 1577 Callable type hints scattered in 1063 Python files.
For comparison, this codebase also has 2754 dict annotations and 1835 list
ones.
On Mon, Dec 20, 2021 at 8:11 AM Christopher Barker
wrote:
> note: I wasn't thinking -- typeshed, of course, has a lot more than the
>
note: I wasn't thinking -- typeshed, of course, has a lot more than the
standard lib. But it's still a collection of widely used somewhat general
purpose libraries. So I think my hypothesis is still valid.
-CHB
On Sun, Dec 19, 2021 at 8:54 PM Christopher Barker
wrote:
> A question that came
A question that came up for me is:
How common is it to need to use Callable for type hints? particularly
complex versions, specifying what parameters the Callable takes? A more
compact and easier to read syntax is nice, but not very important if it
isn't used much.
My first thought on this was
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
> > tl;dr: I find it very troubling that we are going on a path where need
> > to increase the language complexity (syntax) only in the cause
> > 'easier' typing.
Which brings up the question is whether it's worth adding syntax for
typing, but
I think I've posted it as a standalone reply (sorry for my bad mailing list
skills), so linking my thread about potential concerns/reservations:
https://mail.python.org/archives/list/python-dev@python.org/thread/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/
___
I agree. The same concerns and reservations apply for me.
On Sat, 18 Dec 2021 at 21:13, Terry Reedy wrote:
>
> Batuhan expresses my concerns better than I could, so I just add my
> agreement.
>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
> > tl;dr: I find it very troubling that we are
Batuhan expresses my concerns better than I could, so I just add my
agreement.
On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
tl;dr: I find it very troubling that we are going on a path where need
to increase the language complexity (syntax) only in the cause
'easier' typing. So I am opposed
First of all, thank you for authoring a really well-written PEP.
tl;dr: I find it very troubling that we are going on a path where need
to increase the language complexity (syntax) only in the cause
'easier' typing. So I am opposed to this change.
Most of the native typing use cases until now
34 matches
Mail list logo
