On Apr 7, 2021, at 12:59, Guido van Rossum wrote:
>
> Note that in TypeScript this also doesn't look like a boolean -- it uses a
> unique syntax that has to be learned:
>
> function isCustomer(partner: any): partner is Customer {
> . . .
> }
>
> Arguably the TS syntax is more easily intuit
Attached is my second draft of PEP 649. The PEP and the prototype have
both seen a marked improvement since round 1 in January; PEP 649 now
allows annotations to refer to any variable they could see under stock
semantics:
* Local variables in the current function scope or in enclosing
f
I like! I really appreciate the work you've put into this to get it
this far.
Questions and comments:
> PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()``
> to examine annotations. Code updated to work with PEP 563 that calls
> ``eval()`` directly would have to be updated simp
On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw wrote:
[snip]
> 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 if it may be time to in a sense separate the
> typing syntax fr
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 arbitrary syntax (e.g. through
Annotated[...] or similar mechanism).
On 4/11/21 7:55 PM, Paul Bryan wrote:
PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()``
to examine annotations. Code updated to work with PEP 563 that calls
``eval()`` directly would have to be updated simply to remove the
``eval()`` call. Code using ``typing.get_type_hints(
