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
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,
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
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
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
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
Hi there
I hope you would indulge me in asking for some details about the new
CFrame structure, even in the form of existing literature (e.g. PEP)
where the idea behind it is explained.
Also, I'd like to a quick question, if I may. There now appear to be
two ways of unwinding the frame stack:
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:
...
```
On Dec 20, 2021, at 12:22, Guido van Rossum wrote:
> What do you think about -hh (and maybe —help-full) printing full help?
>
> Is there enough of a use case for this to bother?
Maybe not. I’d say if it was easy to implement, why not, but if it’s a pain,
don't bother.
-Barry
signature.asc
Hi Gabriele!
> I hope you would indulge me in asking for some details about the new CFrame
> structure, even in the form of existing literature (e.g. PEP) where the idea
> behind it is explained.
There isn't too much documentation on this, unfortunately (since these are all
very unstable,
On Sat, Dec 18, 2021 at 4:00 PM Guido van Rossum wrote:
> On Sat, Dec 18, 2021 at 2:16 PM Serhiy Storchaka
> wrote:
>
>> The output of "python -h" is 104 lines long now. It was only 51 lines in
>> 3.6. 35% of it is about the -X option, and 30% about environment
>> variables. Also some lines in
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
Hi Gabriele,
I think the code is currently the only documentation, since this is
considered a CPython internal issue. I'm CC'ing Mark Shannon, since he
designed this for 3.11.
For a bit of background, see this issue in the Faster CPython tracker:
https://github.com/faster-cpython/ideas/issues/31
Hi Gabriele,
In addition to what Guido and Brandt have already said, I can help to you
adapting Austin to 3.11 as I reviewed or authored some of these changes and
I have already been helping some projects do the relevant changes as well
as in my own tools.
What you want to do si the following
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
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 Mon, Dec 20, 2021 at 11:15 AM Brett Cannon wrote:
>
>
> On Sat, Dec 18, 2021 at 4:00 PM Guido van Rossum wrote:
>
>> On Sat, Dec 18, 2021 at 2:16 PM Serhiy Storchaka
>> wrote:
>>
>>> The output of "python -h" is 104 lines long now. It was only 51 lines in
>>> 3.6. 35% of it is about the -X
Just to clear up a quick point I made:
> - PyFrameObject.f_back just gives you a dummy wrapper around the previous
> frame object.
> - It's not really useful for unwinding anything.
That should read "previous InterpreterFrame", rather than "previous frame
object".
Also, everything I 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 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 Dec 20, 2021, at 11:34, Guido van Rossum wrote:
>
> Fair enough. Quick design proposal:
>
> -h and --help print info about flags (existing flags)
> --help-env (or --env-help?) prints info about env vars (new flag)
> -X help prints info about -X options (new -X option)
>
> Two lines
On Mon, Dec 20, 2021 at 12:16 PM Barry Warsaw wrote:
> On Dec 20, 2021, at 11:34, Guido van Rossum wrote:
> >
> > Fair enough. Quick design proposal:
> >
> > -h and --help print info about flags (existing flags)
> > --help-env (or --env-help?) prints info about env vars (new flag)
> > -X
20.12.21 21:34, Guido van Rossum пише:
> Fair enough. Quick design proposal:
>
> -h and --help print info about flags (existing flags)
> --help-env (or --env-help?) prints info about env vars (new flag)
> -X help prints info about -X options (new -X option)
>
> Two lines printed at the end
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
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
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
Brandt, Guido, Pablo
Many thanks for your helpful answers. Indeed I'm asking because I just
finished working on some improvements to Austin and got back to looking
into what was coming in order to add support for 3.11 (plus make use of
some of the changes that I recently contributed, like
Hi Gabriele,
>> So this makes me wonder if it would make sense for CPython to ensure
frame objects are created in a contiguous block of memory (perhaps there
could be benefits from the locality of reference, although it's not obvious
to me why this would be the case at the moment).
That's
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
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
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
> That's already the case for 3.11
Ah, that's awesome news! Like with the rest, I'll wait and see what shape this
ends up taking :).
Cheers,
Gab
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
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
33 matches
Mail list logo
