On Mon, 2021-04-12 at 19:52 -0700, Guido van Rossum wrote:
> Why not submit a PR that adds caching to get_type_hints(), rather
> than promote a paradigm shift?
A couple of reasons:
1. In reviewing the code, I didn't find an obvious way to store cached
values. Anything but a non-trivial change w
On Mon, Apr 12, 2021 at 7:47 PM Paul Bryan wrote:
> In 3.9 this cost is paid once when a type is defined. However, in 3.10, it
> gets expensive, because when the string is evaluated by get_type_hints, its
> result is not stored/cached anywhere (repeated calls to get_type_hints
> results in repeat
On Tue, 2021-04-13 at 11:33 +0900, Inada Naoki wrote:
> On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote:
> >
> > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
> >
> > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings
> > wrote:
> >
> >
> > This is really the heart of the debate over PE
On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote:
>
> On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
>
> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> This is really the heart of the debate over PEP 649 vs PEP 563. If you
> examine an annotation, and it references an undef
I've been thinking about this a bit, and I think that the way forward is
for Python to ignore the text of annotations ("relaxed annotation syntax"),
not to try and make it available as an expression.
To be honest, the most pressing issue with annotations is the clumsy way
that type variables have
On Tue, 2021-04-13 at 09:43 +1000, Hugh Fisher wrote:
> In any Python 3.6 or later, type
>
> >>> x : float = 1
> >>> isinstance(x, float)
>
> or replace the second line with
>
> >>> type(x)
>
> As someone who has programmed in FORTRAN, Pascal, C/C++,
> Java, and Go this is not at al
On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings
> wrote:
> > This is really the heart of the debate over PEP 649 vs PEP 563. If
> > you examine an annotation, and it references an undefined symbol,
> > should that throw an error? There is
On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> PEP 563 solves all problems relating to types not accessible in runtime.
> There are many reasons users can not get types used in annotations at runtime:
>
> * To avoid circular import
> * Types
On 4/12/21 4:50 PM, Inada Naoki wrote:
PEP 563 solves all problems relating to types not accessible in runtime.
There are many reasons users can not get types used in annotations at runtime:
* To avoid circular import
* Types defined only in pyi files
* Optional dependency that is slow to impor
On Tue, Apr 13, 2021 at 8:58 AM Larry Hastings wrote:
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> As PEP 597 says, eval() is slow. But it can avoidable in many cases
> with PEP 563 semantics.
>
> PEP 597 is "Add optional EncodingWarning". You said PEP 597 in one other
> place too. Did you me
On 4/12/21 4:50 PM, Inada Naoki wrote:
As PEP 597 says, eval() is slow. But it can avoidable in many cases
with PEP 563 semantics.
PEP 597 is "Add optional EncodingWarning". You said PEP 597 in one
other place too. Did you mean PEP 649 in both places?
Cheers,
//arry/
__
> You could say [...] or "I deeply think that this was one of the
> worst decisions" [...]
Not to get too far off topic, but that's not a good choice of words, either.
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
I still prefer PEP 563.
I will describe what we lost if PEP 597 is accepted and PEP 563 is rejected.
### Types not accessible in runtime
First of all, PEP 563 solves not only forward references.
Note that PEP 563 says: "we'll call any name imported or defined
within a `if TYPE_CHECKING: block` a
On 4/12/2021 6:34 PM, Brett Cannon wrote:
> Had the sentences ended at "confusing" or said something like "I don't think
> it's as optimal as it could be" or "I think it could be better" are all fine.
> But saying that the current approach is "arousing or deserving ridicule :
> extremely silly o
As part of our PyCon US talk (which will be pre-recorded), the SC would
like to have a Q&A session. Since it's pre-recorded, we figured we'd
collect questions through Slido, which also lets people vote on the
questions: https://app.sli.do/event/qdtzzpmd. The Slido will be open for
questions and vot
In any Python 3.6 or later, type
>>> x : float = 1
>>> isinstance(x, float)
or replace the second line with
>>> type(x)
As someone who has programmed in FORTRAN, Pascal, C/C++,
Java, and Go this is not at all what I consider reasonable. I do not
believe other programmers with experi
> Message: 4
> Date: Mon, 12 Apr 2021 13:59:50 -0700
> From: Brett Cannon
>
> Please don't denigrate the hard work people have put in to even bring
> forward the idea of typing in Python by saying it's "slightly ridiculous".
In the interest of moving the discussion forward about separate syntax
>> Aren't people allowed to have their own opinions?
Absolutely
> If criticism of any current implementation of any construct becomes
> off-limits is automatically classed as "denigrating"
Without judging the particular instance or the discussion itself, here is the
definition of the w
On Mon, Apr 12, 2021 at 2:19 PM wrote:
> April 12, 2021 4:59 PM, "Brett Cannon" wrote:
>
> > On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher
> wrote:
> >
> >>> Message: 1
> >>> Date: Sun, 11 Apr 2021 13:31:12 -0700
> >>> From: Barry Warsaw
> >>> Subject: [Python-Dev] Re: PEP 647 Accepted
> >>
> >>
April 12, 2021 4:59 PM, "Brett Cannon" wrote:
> On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher wrote:
>
>>> Message: 1
>>> Date: Sun, 11 Apr 2021 13:31:12 -0700
>>> From: Barry Warsaw
>>> Subject: [Python-Dev] Re: PEP 647 Accepted
>>
>>>
>>> This is something the SC has been musing about, but a
On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher wrote:
> > Message: 1
> > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > From: Barry Warsaw
> > Subject: [Python-Dev] Re: PEP 647 Accepted
>
> >
> > This is something the SC has been musing about, but as it’s not a fully
> formed idea, I’m a little hesitant
On 4/12/2021 11:29 AM, Andreas R Maier wrote:
I have written ...
My question is, should ...
The pydev list is for development of future Python versions and CPython
releases. Questions about the use of, or development with, current
versions and releases should be directed elsewhere, such as
On Sun, Apr 11, 2021 at 9:41 PM Paul Bryan wrote:
> I'm in favour of the approach proposed in PEP 649.
>
> Movie trailer: "In a world where annotations are arbitrary non-Python
> syntax..."
>
> It seems to me we could always have annotations evaluate to Python
> expressions **and* *support any ar
Hi,
I have written some classes that represent immutable views on collections (see
"immutable-views" package on Pypi).
Currently, these view classes inherit from the abstract collection classes such
as Mapping, Sequence, Set. However, they implement the read-only methods of
dict, list and set,
I'm a big fan of this PEP, for many reasons. But the fact that it
addresses some of the issues with get_type_hints() is very important.
dataclasses avoids calling get_type_hints() for performance reasons and
because it doesn't always succeed, see
https://github.com/python/typing/issues/508. I b
On Sun, 2021-04-11 at 23:34 -0700, Larry Hastings wrote:
> Your example was valid, and I think your workaround should be fine.
> Do you have a use case for this, or is this question motivated purely
> by curiosity?
It took a few readings for me to understand the limitations in the PEP.
My exampl
Hi,
Please review this documentation:
https://docs.python.org/dev/using/configure.html
If you have comment, you can directly write a PR (please notify me by
mentioning @vstinner in a comment). Or if you prefer, you can reply
directly by email and I will try to address your remarks.
--
Over
> Message: 1
> Date: Sun, 11 Apr 2021 13:31:12 -0700
> From: Barry Warsaw
> Subject: [Python-Dev] Re: PEP 647 Accepted
>
> This is something the SC has been musing about, but as it’s not a fully
> formed idea, I’m a little hesitant to bring it up. That said, it’s somewhat
> relevant: We wonder
28 matches
Mail list logo
