[Python-Dev] Re: Typing syntax and ecosystem

[Hugh Fisher]

> 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 if it may be time to in a sense separate the typing 
> syntax from Python’s regular syntax.  TypeGuards are a case where if typing 
> had more flexibility to adopt syntax that wasn’t strictly legal “normal” 
> Python, maybe something more intuitive could have been proposed.  I wonder if 
> the typing-sig has discussed this possibility (in the future, of course)?

[ munch ]

>
> Agreed.  It’s interesting that PEP 593 proposes a different approach to 
> enriching the typing system.  Typing itself is becoming a little ecosystem of 
> its own, and given that many Python users are still not fully embracing 
> typing, maybe continuing to tie the typing syntax to Python syntax is 
> starting to strain.

I would really like to see either "Typed Python" become a different programming
language, or progress to building type checking into the CPython implementation
itself. (Python 4 seems to me the obvious release.) The current halfway approach
is confusing and slightly ridiculous.

The first, a separate programming language, would be like RATFOR and CFront
in the past and TypeScript today. Typed Python can have whatever syntax the
designers want because it doesn't have to be compatible with Python, just as
TypeScript is not constrained by JavaScript. A type checker translates
the original
Typed Python source into "dynamic" or "classic" Python for execution. (Maybe
into .pyc instead of .py?)

This would mean no overhead for type checking in CPython itself. No need to
contort the parser into ignoring bits of code that are, in effect,
syntax checked
comments. And for the typing in Python enthusiasts, you won't have to listen
to people like me complaining.

The second approach is to assume that type checking in Python is useful and
popular. Not with me, but I'm willing to accept that I'm in the minority and can
be ignored - after all, I can still write my Python code without type
annotations.
If so running a type checker as a separate step, as we do at the moment, is
like asking C programmers to run the preprocessor by hand.

In today's world of continuous build and integration, it seems silly
to me to have
a type checker read the source, scan into lexical tokens, build an
abstract syntax
tree, perform semantic analysis with type checking, and then throw it away
before running an interpreter which reads the same source, scans into lexical
tokens, builds an abstract syntax tree, and executes. On the purely pragmatic
level there is an extra chance for mismatches and things to go wrong; and from
an environmental viewpoint it isn't a great use of resources.

-- 

cheers,
Hugh Fisher
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Please review the new Python Build System documentation

[Victor Stinner]

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 the last years, the configure script got more and more options. I
was always disappointed by the lack of documentation. It is also
really hard to understand how Python pass compiler and linker files
when building C code. So I wrote a documentation about configure,
preprocessor, compiler and linker flags, and a very brief description
of the Python Build System.

I chose to not document *all* configure/compiler options. I skipped
generic configure options like --prefix. I copied the documentation
that I could find, but sadly many options are still not documented
yet.

For the first time, I wrote a description of in the infamous "Python
Debug Build", especially ("all") effects of this build:

https://docs.python.org/dev/using/configure.html#debug-build

I also took the opportuniy to add links from configure --with-xxx
options to this documentation, and also add links from "debug mode" or
"debug build" terms to the Debug Build section.

Note: the online documentation is only updated once per day. The job
building the documentation of all Python versions in all supported
languages takes a whole day! If you want to help, visit:
https://github.com/python/docsbuild-scripts/

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G3JJPRWMU2W6ARNVAUALDJOUNZSP343M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

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 example and workaround were mostly for me to confirm I had read it
correctly. 

> It's fine to modify the __annotations__ dict after the creation of
> the class or module.  It's code that modifies "__annotations__" from
> within the class or module that is disallowed here.  Similarly for
> dataclasses; once it creates a class object, it can explicitly set
> and / or modify the annotations dict on that class.

Thanks. I think this clarification should be added to the PEP.

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6OTLAO3XOO2DVAGJOL4Q4LKPLCMLI3FZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Eric V. Smith]

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 believe this issue is 
fixed by PEP 649.


On 4/12/2021 2:34 AM, Larry Hastings wrote:



On 4/11/21 7:55 PM, Paul Bryan wrote:
I recognize the point you make later about its impact on static type 
checkers. Setting that aside, I'm wondering about caes where 
annotations can be dynamically generated, such as 
dataclasses.make_dataclass(...). And, I could see reasons for 
overwriting values in __annotations__, especially in the case where 
it may be stored as a string and one wants to later affix its 
evaluated value. These are considerations specific to runtime 
(dynamic) type checking.
It's fine to modify the __annotations__ dict after the creation of the 
class or module.  It's code that modifies "__annotations__" from 
within the class or module that is disallowed here. Similarly for 
dataclasses; once it creates a class object, it can explicitly set and 
/ or modify the annotations dict on that class.


There won't be any direct impact to make_dataclass(). It doesn't do 
anything tricky here: it just builds up the annotations dictionary and 
passes it as __annotations__ to the class namespace in 
types.new_class(). After creating the class, it just applies the normal 
dataclass() decorator.


Eric

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T4KPZKA57SPV2JQPEVZLYMPF45F2TFSG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Immutable view classes - inherit from dict or from Mapping?

[Andreas R Maier]

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, which provides some more methods compared to the abstract 
collection classes. For example, class "dict" provides copy() or __reversed__() 
and the newer OR-operator methods all of which are not defined on the abstract 
class "Mapping".

Note that the view classes do not provide any of the modifying methods of 
"dict" and "list", because after all the views are supposed to be immutable.

My question is, should the dict view class inherit from Mapping or from dict, 
and likewise, should the list view class inherit from Sequence or from list?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N2FUPQE2J353EES4Y6NX6AVGLKIUY4EN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Relaxing the annotation syntax

[Guido van Rossum]

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 arbitrary syntax (e.g. through
> Annotated[...] or similar mechanism). What would a relaxed inline syntax
> provide that a well-placed Annotated[type, ArbitraryNonPythonSyntax("...")]
> annotation wouldn't? .
>

I'm not a fan of Annotated -- it's an escape hook of last resort, not the
way to add new syntax in the future. New syntax should enhance usability
and readability, and Annotated does neither.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M4AMAFV6SRQGOYC5JUO55VGEELNJTJFU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Immutable view classes - inherit from dict or from Mapping?

[Terry Reedy]

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 python-list 
or stackoverflow.



--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P36Q3LSDGDUCAXUVET5OQ53X42OD22F4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Brett Cannon]

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 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 from Python’s regular syntax.  TypeGuards are a case where if
> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe something more intuitive could have been proposed.
> I wonder if the typing-sig has discussed this possibility (in the future,
> of course)?
>
> [ munch ]
>
> >
> > Agreed.  It’s interesting that PEP 593 proposes a different approach to
> enriching the typing system.  Typing itself is becoming a little ecosystem
> of its own, and given that many Python users are still not fully embracing
> typing, maybe continuing to tie the typing syntax to Python syntax is
> starting to strain.
>
> I would really like to see either "Typed Python" become a different
> programming
> language, or progress to building type checking into the CPython
> implementation
> itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> is confusing and slightly ridiculous.
>

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".

-Brett


>
> The first, a separate programming language, would be like RATFOR and CFront
> in the past and TypeScript today. Typed Python can have whatever syntax the
> designers want because it doesn't have to be compatible with Python, just
> as
> TypeScript is not constrained by JavaScript. A type checker translates
> the original
> Typed Python source into "dynamic" or "classic" Python for execution.
> (Maybe
> into .pyc instead of .py?)
>
> This would mean no overhead for type checking in CPython itself. No need to
> contort the parser into ignoring bits of code that are, in effect,
> syntax checked
> comments. And for the typing in Python enthusiasts, you won't have to
> listen
> to people like me complaining.
>
> The second approach is to assume that type checking in Python is useful and
> popular. Not with me, but I'm willing to accept that I'm in the minority
> and can
> be ignored - after all, I can still write my Python code without type
> annotations.
> If so running a type checker as a separate step, as we do at the moment, is
> like asking C programmers to run the preprocessor by hand.
>
> In today's world of continuous build and integration, it seems silly
> to me to have
> a type checker read the source, scan into lexical tokens, build an
> abstract syntax
> tree, perform semantic analysis with type checking, and then throw it away
> before running an interpreter which reads the same source, scans into
> lexical
> tokens, builds an abstract syntax tree, and executes. On the purely
> pragmatic
> level there is an extra chance for mismatches and things to go wrong; and
> from
> an environmental viewpoint it isn't a great use of resources.
>
> --
>
> cheers,
> Hugh Fisher
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZTXS5JWP5LQ3CRFTXJUREXBB3I5GQTJS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[edwin]

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 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 from Python’s regular syntax. TypeGuards 
>> are a case where if
>> typing had more flexibility to adopt syntax that wasn’t strictly legal 
>> “normal” Python, maybe
>> something more intuitive could have been proposed. I wonder if the 
>> typing-sig has discussed this
>> possibility (in the future, of course)?
>> 
>> [ munch ]
>> 
>>> 
>>> Agreed. It’s interesting that PEP 593 proposes a different approach to 
>>> enriching the typing
>> system. Typing itself is becoming a little ecosystem of its own, and given 
>> that many Python users
>> are still not fully embracing typing, maybe continuing to tie the typing 
>> syntax to Python syntax is
>> starting to strain.
>> 
>> I would really like to see either "Typed Python" become a different 
>> programming
>> language, or progress to building type checking into the CPython 
>> implementation
>> itself. (Python 4 seems to me the obvious release.) The current halfway 
>> approach
>> is confusing and slightly ridiculous.
> 
> 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".
> 
> -Brett

Aren't people allowed to have their own opinions?  Please, I hate to see this 
list descend further and further into such knee-jerk reactions.  If criticism 
of any current implementation of any construct becomes off-limits is 
automatically classed as "denigrating", there is no reason for this list to 
exist.  You might not agreed with the criticism, but you should at least be 
open to discussion.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WE2YCV5COQ64VEDJATVGZCMXMJQGZMQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Brett Cannon]

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
> >>
> >>>
> >>> 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 from Python’s regular syntax.
> TypeGuards are a case where if
> >> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe
> >> something more intuitive could have been proposed. I wonder if the
> typing-sig has discussed this
> >> possibility (in the future, of course)?
> >>
> >> [ munch ]
> >>
> >>>
> >>> Agreed. It’s interesting that PEP 593 proposes a different approach to
> enriching the typing
> >> system. Typing itself is becoming a little ecosystem of its own, and
> given that many Python users
> >> are still not fully embracing typing, maybe continuing to tie the
> typing syntax to Python syntax is
> >> starting to strain.
> >>
> >> I would really like to see either "Typed Python" become a different
> programming
> >> language, or progress to building type checking into the CPython
> implementation
> >> itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> >> is confusing and slightly ridiculous.
> >
> > 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".
> >
> > -Brett
>
> Aren't people allowed to have their own opinions?


Yes, of course.


>   Please, I hate to see this list descend further and further into such
> knee-jerk reactions.


It wasn't a knee-jerk reaction. I did take the time to think about replying.


>   If criticism of any current implementation of any construct becomes
> off-limits is automatically classed as "denigrating", there is no reason
> for this list to exist.  You might not agreed with the criticism, but you
> should at least be open to discussion.
>

And I didn't try to shut down the discussion. My point was not about the
intent of the message, but how that message was delivered. Being
considerate and acknowledging people's time and effort is important and I
don't think saying something is "ridiculous" does that.

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 or unreasonable : absurd, preposterous" as defined
by Merriam-Webster 
is not necessary to make the point; it could have been phrased in such a
way as to be a bit more respectful to those who have put in the time and
effort to get things to where they are.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OGASYCZ7P4YXW2WHGAYOOEBFWMRCJFGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[jossuazugasti via Python-Dev]

>> 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 world "ridiculous":

Ridiculous: adjective. Deserving or inviting derision or mockery; absurd.

I am quite sure that there a better ways to make a technical argument without 
describing the target of your objections as "deserving derision or mockery".

You could say "I think the current state of X is quite painful" or "I think 
this is not acceptable" or "I think this is a really bad idea" or "I think that 
this is going to make a lot of things really bad" or "I really don't like this" 
or "I deeply think that this was one of the worst decisions". None of those 
statements are denigrating. Calling something "ridiculous", is, by design, 
denigrating. Not the worst way to denigrate but a way to denigrate, 
nevertheless.

Rgds,
Jossua___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UTMMKFSU4OXNYVQJWBQPPKF3ND4S7MAP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Hugh Fisher]

> 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
or type checking integration, I apologize to anyone who feels personally
insulted by my response. That was not my intention.

-- 

cheers,
Hugh Fisher
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HL2HHS4VFQYLCSQQB5Z22M3P5IE4PM36/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Typing syntax and ecosystem, take 2

[Hugh Fisher]

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 experience in typed languages
would expect this behaviour either.

Having a type checker run before the Python interpreter in our
current day continuous build/integration environment adds a
second step and therefore the chance for it to be forgotten, for
version mismatches, for warning/error reports to be misdirected.
>From an environmental point of view we're also doing the read
source, lexical scan, syntax parse twice rather than once.

If typing is the future of Python, and the number of PEPs being
worked on suggests that it is, then type checking should be
integrated into CPython itself.

An alternative is the TypeScript/JavaScript model, where typed
Python becomes a distinct programming language that cannot
be executed directly by the Python interpreter.

-- 

cheers,
Hugh Fisher
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/273J3AZ7VY7HRPDMGDHDCDELE3JV7WPT/
Code of Conduct: http://python.org/psf/codeofconduct/

python-dev@python.org

[Thomas Wouters]

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 voting for a week, after which we'll do our best to answer
them all.

If you're unhappy using Slido I'd also be happy to take questions directly,
but we would like to gauge the popularity of the questions to help us
prioritise them. In any event, if there are questions we don't get to we'll
try to answer them some other way, like a blog post.

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SWV6QFJ427BGAF2EFQ2ZSANII6KE44DZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Edwin Zimmerman]

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 or unreasonable : absurd, preposterous" as defined by 
> Merriam-Webster  is 
> not necessary to make the point; it could have been phrased in such a way as 
> to be a bit more respectful to those who have put in the time and effort to 
> get things to where they are.
My plea is very simple: that everyone would be a bit more gracious.  Email by 
its very nature does not convey meaning as well as in-person conversation.  As 
Hugh just remarked, the meaning you took from his comments was not the meaning 
he intended to convey.  These misunderstandings seem to be happening more and 
more frequently.  I read this list to understand the direction that Python will 
take in the future, but I have thought numerous times of unsubscribing due to 
all the curt "you said it wrong" responses like the one that triggered my first 
email.

Any way, in the interest of not starting a flame war, I will have nothing more 
to say.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ETJCGR4ULRYY5WNOLRPULVWMBW4LCY3E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

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 forward reference, too."
https://www.python.org/dev/peps/pep-0563/#forward-references

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 import or hard to install

This is the most clear point where PEP 563 is better for some users.
See this example:

```
from dataclasses import dataclass

if 0:
from fakemod import FakeType

@dataclass
class C:
a : FakeType = 0
```

This works on PEP 563 semantics (Python 3.10a7). User can get
stringified annotation.

With stock semantics, it cause NameError when importing so author can
notice they need to quote "FakeType".

With PEP 649 semantics, author may not notice this annotation cause
error. User can not get any type hints at runtime.


### Type alias

Another PEP 563 benefit is user can see simple type alias.
Consider this example.

```
from typing import *

AliasType = Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]]

def f() -> AliasType:
pass

help(f)
```

Currently, help() calls `typing.get_type_hints()`. So it shows:

```
f() -> Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]]
```

But with PEP 563 semantics, we can stop evaluating annotations and
user can see more readable alias type.

```
f() -> AliasType
```

As PEP 597 says, eval() is slow. But it can avoidable in many cases
with PEP 563 semantics.
I am not sure but I expect dataclass can avoid eval() too in PEP 563 semantics.

Sphinx uses this feature already.
See 
https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_type_aliases


### Relaxing annotation syntax

As discussed in PEP 647 thread, we can consider having different
syntax for annotation with PEP 597 semantics.


Regards,

On Mon, Apr 12, 2021 at 10:58 AM Larry Hastings  wrote:
>
>
> 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 function scopes 
> become closures and use LOAD_DEFER.
> Class variables in the current class scope are made available using a new 
> mechanism, in which the class dict is attached to the bound annotation 
> function, then loaded into f_locals when the annotation function is run.  
> Thus permitting LOAD_NAME opcodes to function normally.
>
>
> I look forward to your comments,
>
>
> /arry
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KK5QG75RWSDBU4E36XAVSDPY5OUERA73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] word choices when criticizing [was: Typing syntax and ecosystem]

[Ethan Furman]

> 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 an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TSJK3GITB2BHPX62CCP345V2UOR6OUUQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

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/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IPRE2ZGP7VXN6XBWATWLEWUUQN6NFDLJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

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 mean PEP 649 in both places?
>

You're right. I meant PEP 649 vs PEP 563. I'm sorry.

>
> Cheers,
>
>
> /arry



-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CLTMVQS7PMLEM237IAY4WCXC7M5DL7T6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

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 import or hard to install


It only "solves" these problems if you leave the annotation as a 
string.  If PEP 563 is active, but you then use typing.get_type_hints() 
to examine the actual Python value of the annotation, all of these 
examples will fail with a NameError.  So, in this case, "solves the 
problem" is a positive way of saying "hides a runtime error".


I don't know what the use cases are for examining type hints at runtime, 
so I can't speak as to how convenient or inconvenient it is to deal with 
them strictly as strings.  But it seems to me that examining annotations 
as their actual Python values would be preferable.




This is the most clear point where PEP 563 is better for some users.
See this example:

```
from dataclasses import dataclass

if 0:
 from fakemod import FakeType

@dataclass
class C:
 a : FakeType = 0
```

This works on PEP 563 semantics (Python 3.10a7). User can get
stringified annotation.

With stock semantics, it cause NameError when importing so author can
notice they need to quote "FakeType".

With PEP 649 semantics, author may not notice this annotation cause
error. User can not get any type hints at runtime.


Again, by "works on PEP 563 semantics", you mean "doesn't raise an 
error".  But the code /has/ an error.  It's just that it has been hidden 
by PEP 563 semantics.


I don't agree that changing Python to automatically hide errors is an 
improvement.  As the Zen says: "Errors should never pass silently."


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 definitely a contingent of people who say 
"no, that's inconvenient for us".  I think it should raise an error.  
Again from the Zen: "Special cases aren't special enough to break the 
rules."  Annotations are expressions, and if evaluating an expression 
fails because of an undefined name, it should raise a NameError.




### Type alias

Another PEP 563 benefit is user can see simple type alias.
Consider this example.

```
from typing import *

AliasType = Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]]

def f() -> AliasType:
 pass

help(f)
```

Currently, help() calls `typing.get_type_hints()`. So it shows:

```
f() -> Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]]
```

But with PEP 563 semantics, we can stop evaluating annotations and
user can see more readable alias type.

```
f() -> AliasType
```


It's a matter of personal opinion whether "AliasType" or the full 
definition is better here.  And it could lead to ambiguity, if the 
programmer assigns to "AliasType" more than once.


Iif the programmer has a strong opinion that "AliasType" is better, they 
could use an annotation of 'AliasType'--in quotes. Although I haven't 
seen the topic discussed specifically, I assume that the static typing 
analysis tools will continue to support manually stringized annotations 
even if PEP 649 is accepted.


Either way, this hypothetical feature might be "nice-to-have", but I 
don't think it's very important.  I would certainly forego this behavior 
in favor of accepting PEP 649.



Cheers,


//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OOS3VTHDIL2MVBQQ5BG2XNCHSURSZO6X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

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 defined only in pyi files
> * Optional dependency that is slow to import or hard to install
>
> It only "solves" these problems if you leave the annotation as a string.  If 
> PEP 563 is active, but you then use typing.get_type_hints() to examine the 
> actual Python value of the annotation, all of these examples will fail with a 
> NameError.  So, in this case, "solves the problem" is a positive way of 
> saying "hides a runtime error".
>

Of course, "get type which is unavailable in runtime" is unsolvable
problem. PEP 597 doesn't solve it too. Author needs to quote the hint
manually, and `typing.get_type_hints()` raises NameError too.
And if author forget to quote, user can not get any type hints.


> I don't know what the use cases are for examining type hints at runtime, so I 
> can't speak as to how convenient or inconvenient it is to deal with them 
> strictly as strings.  But it seems to me that examining annotations as their 
> actual Python values would be preferable.
>

This is use cases for examining type hints at runtime and stringified
hints are OK.

* Sphinx autodoc
* help()
* IPython and other REPLS showing type hint in popup.


>
> ```
> from dataclasses import dataclass
>
> if 0:
> from fakemod import FakeType
>
> @dataclass
> class C:
> a : FakeType = 0
> ```
>
> This works on PEP 563 semantics (Python 3.10a7). User can get
> stringified annotation.
>
> With stock semantics, it cause NameError when importing so author can
> notice they need to quote "FakeType".
>
> With PEP 649 semantics, author may not notice this annotation cause
> error. User can not get any type hints at runtime.
>
> Again, by "works on PEP 563 semantics", you mean "doesn't raise an error".  
> But the code has an error.  It's just that it has been hidden by PEP 563 
> semantics.
>
> I don't agree that changing Python to automatically hide errors is an 
> improvement.  As the Zen says: "Errors should never pass silently."
>
> 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 definitely a contingent of people who say "no, 
> that's inconvenient for us".  I think it should raise an error.  Again from 
> the Zen: "Special cases aren't special enough to break the rules."  
> Annotations are expressions, and if evaluating an expression fails because of 
> an undefined name, it should raise a NameError.
>

I agree that this is the heart of the debate. I think "annotations are
for type hitns". They are for:

* Static type checkers
* document.

So I don't think `if TYPE_CHECKING` idiom is violating Python Zen.


Regards,

-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DAMYYG5CY6MGRCAKIWRA4IKXW75DYXW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

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 definitely a contingent of
> > people who say "no, that's inconvenient for us".  I think it should
> > raise an error.  Again from the Zen: "Special cases aren't special
> > enough to break the rules."  Annotations are expressions, and if
> > evaluating an expression fails because of an undefined name, it
> > should raise a NameError.

> I agree that this is the heart of the debate. I think "annotations
> are
> for type hitns". They are for:
> 
> * Static type checkers
> * document.

+ dynamic type validation, encoding and decoding (Pydantic, FastAPI,
Fondat, et al.)

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/57GR7AN7L647CGMMHDWTK3PVL27HFKEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Filipe Laíns]

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 all what I consider reasonable. I do not
> believe other programmers with experience in typed languages
> would expect this behaviour either.

Python is not a typed language, it is a language with optional typing.

> Having a type checker run before the Python interpreter in our
> current day continuous build/integration environment adds a
> second step and therefore the chance for it to be forgotten, for
> version mismatches, for warning/error reports to be misdirected.
> From an environmental point of view we're also doing the read
> source, lexical scan, syntax parse twice rather than once.

This is simply not a good point in itself, and on top of that it seems to
completely ignore that Python could be untyped, which is something I am almost
certain won't likely change ever. At the very least you would have to pass a
flag to the interpreter to run the type checker, which completely invalidates
your "people will forget it if they have to explicitly run it" point.

> If typing is the future of Python, and the number of PEPs being
> worked on suggests that it is, then type checking should be
> integrated into CPython itself.

Why? There is a type checker living under the same umbrella organization. What
is the reasoning for the type checker to be included with the interpreter,
especially given that it is entirely optional?
All I can think of are reasons *not to* include it with the interpreter, mainly
that it would be bound to the same super slow release cycle.
Please also consider that a type checker is something that no user will have to
run, only developers.

> An alternative is the TypeScript/JavaScript model, where typed
> Python becomes a distinct programming language that cannot
> be executed directly by the Python interpreter.

Why?? This reads like "let's break stuff that is absolutely working" for no real
discerning reason. Why would you do this? -- Why would we break workflows that
work? Why would we add a code generating step to typed Python code?
I am really struggling here to understand what would be the benefit here, it
seems you want to make it slightly harder for people to forget to run it, by
either making it always run or forcing a new code generation step.

Overall, I find that you are trying to apply concepts from other languages and
environments to Python, without really taking into account what they would mean
for the Python ecosystem.
While it is a great idea to look at other languages and try to align ourselves
with some of their designs, as a way to make the user experience easier for
some, it is also okay to not design things in the same way. We need to take into
account the requirements and current state of our own environment, and try to
understand what is the best option for us. Benefits and drawbacks will vary, so
it is absolutely valid to come up with different answers.

Please do not take these comments personally, in a verbal setting I would try to
use social cues to try to pass the feedback more lightly. This sort of
communication medium can make things easily pass as harsh, but that is not my
goal. I just want to make sure we are on the same page, if you have answers for
any of my questions, please let me know, but try to make sure you are taking
into account you what real impact your proposals would have on the Python
ecosystem.

Cheers,
Filipe Laíns


signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ENAUW2P3FDJOMJXQKLTLT4G7APLEQCJI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

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 to be introduced. The current convention, `T =
TypeVar('T')`, is both verbose (why do I have to repeat the name?) and
widely misunderstood (many help request for mypy and pyright follow from
users making a mistaken association between two type variables that are
unrelated but share the same TypeVar definition). And relaxed annotation
syntax alone doesn't solve this.

Nevertheless I think that it's time to accept that annotations are for
types -- the intention of PEP 3107 was to experiment with different syntax
and semantics for types, and that experiment has resulted in the successful
adoption of a specific syntax for types that is wildly successful.





On Sun, Apr 11, 2021 at 7:02 PM Larry Hastings  wrote:

>
> 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
>function scopes become closures and use LOAD_DEFER.
>- Class variables in the current class scope are made available using
>a new mechanism, in which the class dict is attached to the bound
>annotation function, then loaded into f_locals when the annotation function
>is run.  Thus permitting LOAD_NAME opcodes to function normally.
>
>
> I look forward to your comments,
>
>
> */arry*
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CG222DH3DABWPW6C3N6IFRDVQEEMMAT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

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 undefined symbol, should that 
> throw an error?  There is definitely a contingent of people who say "no, 
> that's inconvenient for us".  I think it should raise an error.  Again from 
> the Zen: "Special cases aren't special enough to break the rules."  
> Annotations are expressions, and if evaluating an expression fails because of 
> an undefined name, it should raise a NameError.
>
>
> I agree that this is the heart of the debate. I think "annotations are
> for type hitns". They are for:
>
> * Static type checkers
> * document.
>
>
> + dynamic type validation, encoding and decoding (Pydantic, FastAPI, Fondat, 
> et al.)
>
> Paul
>

OK. It is important use case too.

Such use cases doesn't justify raising NameError instead of getting
stringified type hints for documents for document use cases.

On the other hand, if "dynamic type" is used heavily, eval()
performance can be a problem.

-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ICKGBL674MUOYBOGNGKKJDPHYD3TYGER/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

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 PEP 649 vs PEP 563.  If
> > you examine an annotation, and it references an undefined symbol,
> > should that throw an error?  There is definitely a contingent of
> > people who say "no, that's inconvenient for us".  I think it should
> > raise an error.  Again from the Zen: "Special cases aren't special
> > enough to break the rules."  Annotations are expressions, and if
> > evaluating an expression fails because of an undefined name, it
> > should raise a NameError.
> > 
> > 
> > I agree that this is the heart of the debate. I think "annotations
> > are
> > for type hitns". They are for:
> > 
> > * Static type checkers
> > * document.
> > 
> > 
> > + dynamic type validation, encoding and decoding (Pydantic,
> > FastAPI, Fondat, et al.)
> > 
> > Paul
> > 
> 
> OK. It is important use case too.
> 
> Such use cases doesn't justify raising NameError instead of getting
> stringified type hints for documents for document use cases.
> 
> On the other hand, if "dynamic type" is used heavily, eval()
> performance can be a problem.


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 repeated evaluation). As a
workaround, I have code to "affix" the evaluated expression in
__annotations__ value. PEP 649 would resolve this and eliminate the
need for such a hack.

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HJNS3JHQNZ3WFG44PXTNLFLJTQRYJWCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

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 repeated evaluation). As a workaround, I have code to "affix"
> the evaluated expression in __annotations__ value. PEP 649 would resolve
> this and eliminate the need for such a hack.
>

Why not submit a PR that adds caching to get_type_hints(), rather than
promote a paradigm shift?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZFZYGX6WHC5FYWGLNYVDFDS3MQ7BOQ4T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

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 would suggest the need for a
PEP of its own to document new behavior.

2. I've been hoping that PEP 649 would be adopted, making such a hack
or any plan to cache type hints moot.

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WP4OWWONK7Q72MRGTDGDJNTRYMCHQKZ2/
Code of Conduct: http://python.org/psf/codeofconduct/