Mailing List Archive

On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings <larry@hastings.org> wrote:
>
>
> On 4/13/21 1:52 PM, Guido van Rossum wrote:
>
>
> Because typing is, to many folks, a Really Important Concept, and it's confusing to use the same syntax ("x: blah blah") for different purposes, in a way that makes it hard to tell whether a particular "blah blah" is meant as a type or as something else -- because you have to know what's introspecting the annotations before you can tell. And that introspection could be signalled by a magical decorator, but it could also be implicit: maybe you have a driver that calls a function based on a CLI entry point name, and introspects that function even if it's not decorated.
>
>
> I'm not sure I understand your point. Are you saying that we need to take away the general-purpose functionality of annotations, that's been in the language since 3.0, and restrict annotations to just type hints... because otherwise an annotation might not be used for a type hint, and then the programmer would have to figure out what it means? We need to take away the functionality from all other use cases in order to lend clarity to one use case?
>

I don't think we need to take away "general purpose functionality".
But if we define type hinting is 1st class use case of annotations,
annotations should be optimized for type hinting. General purpose use
case should accept some limitation and overhead.

On the other hand, if we decide general purpose functionality is 1st
class too, we shouldn't annotation syntax different from Python
syntax.

But annotations should be optimized for type hinting anyway. General
purpose use case used only is a limited part of application. On the
other hand, type hint can be used almost everywhere in application
code base. It must cheap enough.

Regards,

--
Inada Naoki <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/UGFWTZUGH6QZRHF3FKTQHZLYG2ZNX5EG/
Code of Conduct: http://python.org/psf/codeofconduct/

For the record, Cython allows using annotations for typing:
https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations

I don't know if they are fully compatible with the type hints we're
talking about here.

Regards

Antoine.


On Wed, 14 Apr 2021 10:58:07 +0900
Inada Naoki <songofacandy@gmail.com> wrote:
> On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings <larry@hastings.org> wrote:
> >
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> >
> > Because typing is, to many folks, a Really Important Concept, and it's confusing to use the same syntax ("x: blah blah") for different purposes, in a way that makes it hard to tell whether a particular "blah blah" is meant as a type or as something else -- because you have to know what's introspecting the annotations before you can tell. And that introspection could be signalled by a magical decorator, but it could also be implicit: maybe you have a driver that calls a function based on a CLI entry point name, and introspects that function even if it's not decorated.
> >
> >
> > I'm not sure I understand your point. Are you saying that we need to take away the general-purpose functionality of annotations, that's been in the language since 3.0, and restrict annotations to just type hints... because otherwise an annotation might not be used for a type hint, and then the programmer would have to figure out what it means? We need to take away the functionality from all other use cases in order to lend clarity to one use case?
> >
>
> I don't think we need to take away "general purpose functionality".
> But if we define type hinting is 1st class use case of annotations,
> annotations should be optimized for type hinting. General purpose use
> case should accept some limitation and overhead.
>
> On the other hand, if we decide general purpose functionality is 1st
> class too, we shouldn't annotation syntax different from Python
> syntax.
>
> But annotations should be optimized for type hinting anyway. General
> purpose use case used only is a limited part of application. On the
> other hand, type hint can be used almost everywhere in application
> code base. It must cheap enough.
>
> Regards,
>



_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/VJWVKMQFAOMYNORX3F4557KWINO4Z7GG/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi,

tl;dr: imho the like or dislike of PEP 563 is related to whether people
intend to learn a second syntax for typing, or would rather ignore it;
both groups should be taken into account.

Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
> <devel2021@baptiste-carvello.net
> <mailto:devel2021@baptiste-carvello.net>> wrote:
>
> Then, what's wrong with quoting? It's just 2 characters, and prevent the
> user (or their IDE) from trying to parse them as Python syntax.
>
>
> Informal user research has shown high resistance to quoting.

OK, but why? I'd bet it's due to an "aesthetic" concern: for typing
users, type hints are code, not textual data. So it irks them to see
them quoted and syntax-highlighted as text strings.

> As a comparison: docstrings do get quoting, even though they also have
> special semantics in the language.
>
>
> Not the same thing. Docstrings use English, which has no formal (enough)
> syntax. The idea for annotations is that they *do* have a formal syntax,
> it just evolves separately from that of Python itself.

If I may say it in my words: to both the parser and (more importantly)
typing-savvy developers, type hints are code. I now see the point.

But what about developers who won't learn this (future) incompatible
typing syntax, and only encounter it in the wild? To them, those
annotations are akin to docstrings: pieces of textual data that Python
manages specially because of their role in the greater ecosystem, but
that they can ignore because the program behavior is not modified.

So it will irk them if annotations in this new syntax are not quoted or
otherwise made distinguishable from code written in the normal Python
syntax they understand. Again the "aesthetic" concern, and imho it
explains in large part why some people dislike PEP 563.

Can the needs of both groups of developers be addressed? Could code in
the new typing syntax be marked with a specific syntactic marker,
distinguishing it from both normal Python syntax and text strings? Then
this new marker could also be used outside of annotations, to mark
analysis-time-only imports or statements?

Or is this all not worth the expense, and typing syntax can manage to
stay compatible with normal Python syntax, in which case PEP 649 is the
way to go?

Cheers,
Baptiste
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/YI3DPTJXKTKZRVVWBJ6UYTUH3PPAJM6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

It looks like a small subset of PEP 484, syntactically. So it should be
fine. Possibly cython might be interested in using a relaxed notation if it
is ever introduced, e.g. ‘long long’ or ‘static int’ (for a return type)?

On Wed, Apr 14, 2021 at 02:27 Antoine Pitrou <antoine@python.org> wrote:

>
> For the record, Cython allows using annotations for typing:
>
> https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations
>
> I don't know if they are fully compatible with the type hints we're
> talking about here.
>
> Regards
>
> Antoine.
>
>
> On Wed, 14 Apr 2021 10:58:07 +0900
> Inada Naoki <songofacandy@gmail.com> wrote:
> > On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings <larry@hastings.org>
> wrote:
> > >
> > >
> > > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> > >
> > >
> > > Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
> > >
> > >
> > > I'm not sure I understand your point. Are you saying that we need to
> take away the general-purpose functionality of annotations, that's been in
> the language since 3.0, and restrict annotations to just type hints...
> because otherwise an annotation might not be used for a type hint, and then
> the programmer would have to figure out what it means? We need to take
> away the functionality from all other use cases in order to lend clarity to
> one use case?
> > >
> >
> > I don't think we need to take away "general purpose functionality".
> > But if we define type hinting is 1st class use case of annotations,
> > annotations should be optimized for type hinting. General purpose use
> > case should accept some limitation and overhead.
> >
> > On the other hand, if we decide general purpose functionality is 1st
> > class too, we shouldn't annotation syntax different from Python
> > syntax.
> >
> > But annotations should be optimized for type hinting anyway. General
> > purpose use case used only is a limited part of application. On the
> > other hand, type hint can be used almost everywhere in application
> > code base. It must cheap enough.
> >
> > Regards,
> >
>
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/VJWVKMQFAOMYNORX3F4557KWINO4Z7GG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)

On 4/12/21 7:24 PM, Guido van Rossum wrote:
> 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).


This repeat-the-name behavior has been in Python for a long time, e.g.

Point = namedtuple('Point', ['x', 'y'])

namedtuple() shipped with Python 2.6 in 2008.  So if that's the most
pressing issue with annotations, annotations must be going quite well,
because we've known about this for at least 13 years without attempting
to solve it.

I've always assumed that this repetition was worth the minor
inconvenience.  You only have to retype the name once, and the resulting
code is clear and readable, with predictable behavior. A small price to
pay to preserve Python's famous readability.


For what it's worth--and forgive me for straying slightly into
python-ideas territory--/if/ we wanted to eliminate the need to repeat
the name, I'd prefer a general-purpose solution rather than something
tailored specifically for type hints.  In a recent private email
conversation on a different topic, I proposed this syntax:

bind <id> <expression>

This statement would be equivalent to

id = expression('id')


Cheers,


//arry/

On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings <larry@hastings.org> wrote:

>
> On 4/13/21 1:52 PM, Guido van Rossum wrote:
>
> On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings <larry@hastings.org>
> wrote:
>
>>
>> On 4/12/21 7:24 PM, Guido van Rossum wrote:
>>
>> 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.
>>
>>
>> I don't follow your reasoning. I'm glad that type hints have found
>> success, but I don't see why that implies "and therefore we should restrict
>> the use of annotations solely for type hints". Annotations are a useful,
>> general-purpose feature of Python, with legitimate uses besides type
>> hints. Why would it make Python better to restrict their use now?
>>
>
> Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
>
>
> I'm not sure I understand your point. Are you saying that we need to take
> away the general-purpose functionality of annotations, that's been in the
> language since 3.0, and restrict annotations to just type hints... because
> otherwise an annotation might not be used for a type hint, and then the
> programmer would have to figure out what it means? We need to take away
> the functionality from all other use cases in order to lend *clarity* to
> one use case?
>

Yes, that's how I see it.

And before you get too dramatic about it, the stringification of
annotations has been in the making a long time, with the community's and
the SC's support. You came up with a last-minute attempt to change it,
using the PEP process to propose to *revert* the decision already codified
in PEP 563 and implemented in the master branch. But you've waited until
the last minute (feature freeze is in three weeks) and IMO you're making
things awkward for the SC (who can and will speak for themselves).


> Also, if you're stating that programmers get confused reading source code
> because annotations get used for different things at different
> places--surely that confirms that annotations are *useful* for more than
> just type hints, in real-world code, today.
>

No, it doesn't, it's just a hypothetical that they *would* be confused if
there *were* other uses. Personally I haven't used any libraries that use
non-type-hint annotations, but I've been told they exist.

I genuinely have no sense of how important static type analysis is in
> Python--personally I have no need for it--but I find it hard to believe
> that type hints are so overwhelmingly important that they should become the
> sole use case for annotations, and we need to take away this long-standing
> functionality, that you suggest is being successfully used side-by-side
> with type hints today, merely to make type hints clearer.
>

For projects and teams that use type hints, they are *very* important. For
example, they are so important to the Instagram team at Facebook that they
wrote their own static type checker when they found mypy wasn't fast enough
for their million-line codebase. And of course they were so important to
Dropbox that they sponsored a multi-year, multi-person effort to create
mypy in the first place. The amount of feedback we've received for mypy
indicates that it's not just those two companies that are using type hints.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki <songofacandy@gmail.com> wrote:

> On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings <larry@hastings.org>
> wrote:
> >
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> >
> > Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
> >
> >
> > I'm not sure I understand your point. Are you saying that we need to
> take away the general-purpose functionality of annotations, that's been in
> the language since 3.0, and restrict annotations to just type hints...
> because otherwise an annotation might not be used for a type hint, and then
> the programmer would have to figure out what it means? We need to take
> away the functionality from all other use cases in order to lend clarity to
> one use case?
> >
>
> I don't think we need to take away "general purpose functionality".
> But if we define type hinting is 1st class use case of annotations,
> annotations should be optimized for type hinting. General purpose use
> case should accept some limitation and overhead.
>
> On the other hand, if we decide general purpose functionality is 1st
> class too, we shouldn't annotation syntax different from Python
> syntax.
>

Has anyone reached out to people like Pydantic, FastAPI, typer, etc. to see
what they think of this PEP? For instance, are they having issues with the
way things are today enough that this is a very clear win for them?

-Brett


>
> But annotations should be optimized for type hinting anyway. General
> purpose use case used only is a limited part of application. On the
> other hand, type hint can be used almost everywhere in application
> code base. It must cheap enough.
>
> Regards,
>
> --
> Inada Naoki <songofacandy@gmail.com>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/UGFWTZUGH6QZRHF3FKTQHZLYG2ZNX5EG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On Wed, Apr 14, 2021 at 9:42 AM Baptiste Carvello <
devel2021@baptiste-carvello.net> wrote:

> Hi,
>
> tl;dr: imho the like or dislike of PEP 563 is related to whether people
> intend to learn a second syntax for typing, or would rather ignore it;
> both groups should be taken into account.
>
> Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> > On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
> > <devel2021@baptiste-carvello.net
> > <mailto:devel2021@baptiste-carvello.net>> wrote:
> >
> > Then, what's wrong with quoting? It's just 2 characters, and prevent
> the
> > user (or their IDE) from trying to parse them as Python syntax.
> >
> >
> > Informal user research has shown high resistance to quoting.
>
> OK, but why? I'd bet it's due to an "aesthetic" concern: for typing
> users, type hints are code, not textual data. So it irks them to see
> them quoted and syntax-highlighted as text strings.
>

No, what I heard is that, since in *most* cases the string quotes are not
needed, people are surprised and annoyed when they encounter cases where
they are needed. And if you have a large code base it takes an expensive
run of the static type checker to find out that you've forgotten the quotes.


> > As a comparison: docstrings do get quoting, even though they also
> have
> > special semantics in the language.
> >
> >
> > Not the same thing. Docstrings use English, which has no formal (enough)
> > syntax. The idea for annotations is that they *do* have a formal syntax,
> > it just evolves separately from that of Python itself.
>
> If I may say it in my words: to both the parser and (more importantly)
> typing-savvy developers, type hints are code. I now see the point.
>
> But what about developers who won't learn this (future) incompatible
> typing syntax, and only encounter it in the wild? To them, those
> annotations are akin to docstrings: pieces of textual data that Python
> manages specially because of their role in the greater ecosystem, but
> that they can ignore because the program behavior is not modified.
>
> So it will irk them if annotations in this new syntax are not quoted or
> otherwise made distinguishable from code written in the normal Python
> syntax they understand. Again the "aesthetic" concern, and imho it
> explains in large part why some people dislike PEP 563.
>

They will treat it as anything else they don't quite understand -- they
will ignore it unless it bites them. And the rule for finding the end of an
annotation would be very simple -- just skip words until the next comma,
close paren or colon, skipping matching brackets etc.

Certainly I use this strategy all the time for quickly skimming code (in
any language) that I don't need to completely understand -- "oh, this is
where the parameters are processed, this is where the defaults are sorted
out, and this is where the work is being done; and since I'm investigating
why the default is weird, let me look at that part of the code in more
detail."


> Can the needs of both groups of developers be addressed? Could code in
> the new typing syntax be marked with a specific syntactic marker,
> distinguishing it from both normal Python syntax and text strings? Then
> this new marker could also be used outside of annotations, to mark
> analysis-time-only imports or statements?
>

There already is a special marker for annotations in function definitions
-- for arguments, it's the colon following the parameter name, and for
return types, it's the arrow after the parameter list. And for variable
declarations ("x: int") the same colon also suffices.

The idea to use the same marker for other analysis-time code is
interesting, but the syntactic requirements are somewhat different --
annotations live at the "expression" level (informally speaking) and are
already in a clearly indicated syntactic position -- analysis-time code
looks just like other code and can occur in any position where statements
can appear. So an appropriate marker would probably be an if-statement with
a special condition, like "if TYPE_CHECKING" (I am all for making that a
built-in constant, BTW).

If you were thinking of backticks, sorry, I'm not biting. (There are folks
who have other plans for those -- presumably because it's one of the few
ASCII characters that currently has no meaning.)


> Or is this all not worth the expense, and typing syntax can manage to
> stay compatible with normal Python syntax, in which case PEP 649 is the
> way to go?
>

I don't see much expense in the proposal to relax the syntax, and I see
benefits for new kinds of type annotations (e.g. PEP 647 would have
benefited).

And certainly PEP 649 has considerable cost as well -- besides the cost of
closing the door to relaxed annotation syntax, there's the engineering work
of undoing the work that was done to make `from __future__ import
annotations` the default (doing this was a significant effort spread over
many commits, and undoing will be just as hard). And we would still have to
support stringification when that import is explicitly given for several
more releases.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

I favour annotations for type hints; the writing's been on the wall for
some time. I think the necessary escape hatch for those using it for
other purposes should be Annotated[Any, ...] (or a similar, nicer
alternative).

Guido, one of the difficulties I'm having is understanding the
direction you're going with "relaxed syntax". PEP 649 is concrete; it's
hard to weigh its merits against the usability—even feasibility—of
incorporating an as yet undefined relaxed syntax.

At the end of the day, such syntax is going to have to be represented
in some structure. If one were to accept that annotations are for type
hints only, is the debate then the difference between a Python type
(which PEP 649 would yield) and some other as yet undefined structure?
 

Paul


On Wed, 2021-04-14 at 10:24 -0700, Guido van Rossum wrote:
> On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings <larry@hastings.org>
> wrote:
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> > > On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings
> > > <larry@hastings.org> wrote:
> > >
> > > >
> > > > On 4/12/21 7:24 PM, Guido van Rossum wrote:
> > > >
> > > > > 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.
> > > >
> > > > I don't follow your reasoning.  I'm glad that type hints have
> > > > found success, but I don't see why that implies "and therefore
> > > > we should restrict the use of annotations solely for type
> > > > hints".  Annotations are a useful, general-purpose feature of
> > > > Python, with legitimate uses besides type hints.  Why would it
> > > > make Python better to restrict their use now?
> > > >
> > >
> > > Because typing is, to many folks, a Really Important Concept, and
> > > it's confusing to use the same syntax ("x: blah blah") for
> > > different purposes, in a way that makes it hard to tell whether a
> > > particular "blah blah" is meant as a type or as something else --
> > > because you have to know what's introspecting the annotations
> > > before you can tell. And that introspection could be signalled by
> > > a magical decorator, but it could also be implicit: maybe you
> > > have a driver that calls a function based on a CLI entry point
> > > name, and introspects that function even if it's not decorated.
> >
> > I'm not sure I understand your point.  Are you saying that we need
> > to take away the general-purpose functionality of annotations,
> > that's been in the language since 3.0, and restrict annotations to
> > just type hints... because otherwise an annotation might not be
> > used for a type hint, and then the programmer would have to figure
> > out what it means?  We need to take away the functionality from all
> > other use cases in order to lend clarity to one use case?
> >
>
>
> Yes, that's how I see it.
>
> And before you get too dramatic about it, the stringification of
> annotations has been in the making a long time, with the community's
> and the SC's support. You came up with a last-minute attempt to
> change it, using the PEP process to propose to *revert* the decision
> already codified in PEP 563 and implemented in the master branch. But
> you've waited until the last minute (feature freeze is in three
> weeks) and IMO you're making things awkward for the SC (who can and
> will speak for themselves).
>  
> > Also, if you're stating that programmers get confused reading
> > source code because annotations get used for different things at
> > different places--surely that confirms that annotations are useful
> > for more than just type hints, in real-world code, today.
> >
>
> No, it doesn't, it's just a hypothetical that they *would* be
> confused if there *were* other uses. Personally I haven't used any
> libraries that use non-type-hint annotations, but I've been told they
> exist.
>
> > I genuinely have no sense of how important static type analysis is
> > in Python--personally I have no need for it--but I find it hard to
> > believe that type hints are so overwhelmingly important that they
> > should become the sole use case for annotations, and we need to
> > take away this long-standing functionality, that you suggest is
> > being successfully used side-by-side with type hints today, merely
> > to make type hints clearer.
> >
>
>
> For projects and teams that use type hints, they are *very*
> important. For example, they are so important to the Instagram team
> at Facebook that they wrote their own static type checker when they
> found mypy wasn't fast enough for their million-line codebase. And of
> course they were so important to Dropbox that they sponsored a multi-
> year, multi-person effort to create mypy in the first place. The
> amount of feedback we've received for mypy indicates that it's not
> just those two companies that are using type hints.
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/UONAPCPQQLMI755NULYS3F67A6MGZKJY/
> Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan <pbryan@anode.ca> wrote:

> I favour annotations for type hints; the writing's been on the wall for
> some time. I think the necessary escape hatch for those using it for other
> purposes should be Annotated[Any, ...] (or a similar, nicer alternative).
>
> Guido, one of the difficulties I'm having is understanding the direction
> you're going with "relaxed syntax". PEP 649 is concrete; it's hard to weigh
> its merits against the usability—even feasibility—of incorporating an as
> yet undefined relaxed syntax.
>
> At the end of the day, such syntax is going to have to be represented in
> some structure. If one were to accept that annotations are for type hints
> only, is the debate then the difference between a Python type (which PEP
> 649 would yield) and some other as yet undefined structure?
>

In `__annotations__` it would be a string, as currently implemented in the
3.10 alpha code. The string just might not be parsable as an expression.

In the AST, it will have to be a new node that just collects tokens and
bracketed things; that could be an array of low-level tokens.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

What would you expect get_type_hints(...) to return with relaxed
syntax? Today, for type hint annotations, it returns a type, which I'd
argue is an important feature to preserve (in it or some successor).

On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote:
> On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan <pbryan@anode.ca> wrote:
> > I favour annotations for type hints; the writing's been on the wall
> > for some time. I think the necessary escape hatch for those using
> > it for other purposes should be Annotated[Any, ...] (or a similar,
> > nicer alternative).
> >
> > Guido, one of the difficulties I'm having is understanding the
> > direction you're going with "relaxed syntax". PEP 649 is concrete;
> > it's hard to weigh its merits against the usability—even
> > feasibility—of incorporating an as yet undefined relaxed syntax.
> >
> > At the end of the day, such syntax is going to have to be
> > represented in some structure. If one were to accept that
> > annotations are for type hints only, is the debate then the
> > difference between a Python type (which PEP 649 would yield) and
> > some other as yet undefined structure? 
> >
>
>
> In `__annotations__` it would be a string, as currently implemented
> in the 3.10 alpha code. The string just might not be parsable as an
> expression.
>
> In the AST, it will have to be a new node that just collects tokens
> and bracketed things; that could be an array of low-level tokens.
>

On 4/14/21 10:44 AM, Guido van Rossum wrote:
> besides the cost of closing the door to relaxed annotation syntax,
> there's the engineering work of undoing the work that was done to make
> `from __future__ import annotations` the default (doing this was a
> significant effort spread over many commits, and undoing will be just
> as hard).


I'm not sure either of those statements is true.

Accepting PEP 649 as written would deprecate stringized annotations,
it's true.  But the SC can make any decision it wants here, including
only accepting the new semantics of 649 without deprecating stringized
annotations.  They could remain in the language for another release (or
two? or three?) while we "kick the can down the road".  This is not
without its costs too but it might be the best approach for now.

As for undoing the effort to make stringized annotations the default,
git should do most of the heavy lifting here.  There's a technique where
you check out the revision that made the change, generate a reverse
patch, apply it, and check that in.  This creates a new head which you
then merge.  That's what I did when I created my co_annotations branch,
and at the time it was literally the work of ten minutes.  I gather the
list of changes is more substantial now, so this would have to be done
multiple times, and it may be more involved.  Still, if PEP 649 is
accepted, I would happily volunteer to undertake this part of the workload.


Cheers,


//arry/

On Wed, Apr 14, 2021 at 11:03 AM Paul Bryan <pbryan@anode.ca> wrote:

> What would you expect get_type_hints(...) to return with relaxed syntax?
> Today, for type hint annotations, it returns a type, which I'd argue is an
> important feature to preserve (in it or some successor).
>

It would have to return some other representation. Presumably the (purely
hypothetical) new syntax would be syntactic sugar for something that can be
expressed as an object, just like (as of PEP 604) X | Y is syntactic sugar
for Union[X, Y].

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

Let's just wait for the SC to join the discussion. I'm sure they will,
eventually.

On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings <larry@hastings.org> wrote:

> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>
> besides the cost of closing the door to relaxed annotation syntax, there's
> the engineering work of undoing the work that was done to make `from
> __future__ import annotations` the default (doing this was a significant
> effort spread over many commits, and undoing will be just as hard).
>
>
> I'm not sure either of those statements is true.
>
> Accepting PEP 649 as written would deprecate stringized annotations, it's
> true. But the SC can make any decision it wants here, including only
> accepting the new semantics of 649 without deprecating stringized
> annotations. They could remain in the language for another release (or
> two? or three?) while we "kick the can down the road". This is not without
> its costs too but it might be the best approach for now.
>
> As for undoing the effort to make stringized annotations the default, git
> should do most of the heavy lifting here. There's a technique where you
> check out the revision that made the change, generate a reverse patch,
> apply it, and check that in. This creates a new head which you then
> merge. That's what I did when I created my co_annotations branch, and at
> the time it was literally the work of ten minutes. I gather the list of
> changes is more substantial now, so this would have to be done multiple
> times, and it may be more involved. Still, if PEP 649 is accepted, I would
> happily volunteer to undertake this part of the workload.
>
>
> Cheers,
>
>
> */arry*
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum <guido@python.org> wrote:

> Let's just wait for the SC to join the discussion. I'm sure they will,
> eventually.
>

FYI the PEP has not been sent to us via
https://github.com/python/steering-council/issues as ready for
pronouncement, so we have not started officially discussing this PEP yet.

-Brett


>
> On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings <larry@hastings.org>
> wrote:
>
>> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>>
>> besides the cost of closing the door to relaxed annotation syntax,
>> there's the engineering work of undoing the work that was done to make
>> `from __future__ import annotations` the default (doing this was a
>> significant effort spread over many commits, and undoing will be just as
>> hard).
>>
>>
>> I'm not sure either of those statements is true.
>>
>> Accepting PEP 649 as written would deprecate stringized annotations, it's
>> true. But the SC can make any decision it wants here, including only
>> accepting the new semantics of 649 without deprecating stringized
>> annotations. They could remain in the language for another release (or
>> two? or three?) while we "kick the can down the road". This is not without
>> its costs too but it might be the best approach for now.
>>
>> As for undoing the effort to make stringized annotations the default, git
>> should do most of the heavy lifting here. There's a technique where you
>> check out the revision that made the change, generate a reverse patch,
>> apply it, and check that in. This creates a new head which you then
>> merge. That's what I did when I created my co_annotations branch, and at
>> the time it was literally the work of ten minutes. I gather the list of
>> changes is more substantial now, so this would have to be done multiple
>> times, and it may be more involved. Still, if PEP 649 is accepted, I would
>> happily volunteer to undertake this part of the workload.
>>
>>
>> Cheers,
>>
>>
>> */arry*
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

My plan was to post it here and see what the response was first. Back in
January, when I posted the first draft, I got some very useful feedback
that resulted in some dramatic changes.  This time around, so far,
nobody has suggested even minor changes.  Folks have just expressed
their opinions about it (which is fine).

Still left to do: ping the project leads of some other static type
analysis projects and see if they have any feedback to contribute.  Once
the dust completely settles around the conversation here, I expect to
formally submit the PEP, hopefully later this week.

Cheers,


//arry/

On 4/14/21 12:22 PM, Brett Cannon wrote:
>
>
> On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum <guido@python.org
> <mailto:guido@python.org>> wrote:
>
> Let's just wait for the SC to join the discussion. I'm sure they
> will, eventually.
>
>
> FYI the PEP has not been sent to us via
> https://github.com/python/steering-council/issues
> <https://github.com/python/steering-council/issues> as ready for
> pronouncement, so we have not started officially discussing this PEP yet.
>
> -Brett
>
>
> On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings
> <larry@hastings.org <mailto:larry@hastings.org>> wrote:
>
> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>> besides the cost of closing the door to relaxed annotation
>> syntax, there's the engineering work of undoing the work that
>> was done to make `from __future__ import annotations` the
>> default (doing this was a significant effort spread over many
>> commits, and undoing will be just as hard).
>
>
> I'm not sure either of those statements is true.
>
> Accepting PEP 649 as written would deprecate stringized
> annotations, it's true.  But the SC can make any decision it
> wants here, including only accepting the new semantics of 649
> without deprecating stringized annotations.  They could remain
> in the language for another release (or two? or three?) while
> we "kick the can down the road". This is not without its costs
> too but it might be the best approach for now.
>
> As for undoing the effort to make stringized annotations the
> default, git should do most of the heavy lifting here. 
> There's a technique where you check out the revision that made
> the change, generate a reverse patch, apply it, and check that
> in.  This creates a new head which you then merge. That's what
> I did when I created my co_annotations branch, and at the time
> it was literally the work of ten minutes.  I gather the list
> of changes is more substantial now, so this would have to be
> done multiple times, and it may be more involved.  Still, if
> PEP 649 is accepted, I would happily volunteer to undertake
> this part of the workload.
>
>
> Cheers,
>
>
> //arry/
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@python.org>
> https://mail.python.org/mailman3/lists/python-dev.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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
> <https://mail.python.org/archives/list/python-dev@python.org/message/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/>
> Code of Conduct: http://python.org/psf/codeofconduct/
> <http://python.org/psf/codeofconduct/>
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@python.org>
> https://mail.python.org/mailman3/lists/python-dev.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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/
> <https://mail.python.org/archives/list/python-dev@python.org/message/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/>
> Code of Conduct: http://python.org/psf/codeofconduct/
> <http://python.org/psf/codeofconduct/>
>

Hi Larry,

?On 4/14/21, 1:56 PM, "Larry Hastings" <larry@midwinter.com on behalf of larry@hastings.org> wrote:

> My plan was to post it here and see what the response was first. Back in January, when I posted the first draft, I got some very useful feedback that resulted in some dramatic changes. This time around, so far, nobody has suggested even minor changes. Folks have just expressed their opinions about it (which is fine).

This is not true. I suggested yesterday (in https://mail.python.org/archives/list/python-dev@python.org/message/DSZFE7XTRK2ESRJDPQPZIDP2I67E76WH/ ) that PEP 649 could avoid making life worse for users of type annotations (relative to PEP 563) if it replaced runtime-undefined names with forward reference markers, as implemented in https://github.com/larryhastings/co_annotations/pull/3

Perhaps you've chosen to ignore the suggestion, but that's not the same as nobody suggesting any changes ;)

Carl

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/4LXOED3ABKDSNUDJ3JTNEGTXD3R7TEWT/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi,

Le 14/04/2021 à 19:44, Guido van Rossum a écrit :
>
> No, what I heard is that, since in *most* cases the string quotes are
> not needed, people are surprised and annoyed when they encounter cases
> where they are needed. And if you have a large code base it takes an
> expensive run of the static type checker to find out that you've
> forgotten the quotes.

Well, I had assumed quotes would be used in all cases for consistency.
Indeed, using them only if needed leads to surprises. Are there specific
annoyances associated with quoting always, apart from the 2 more characters?

>  
> [...]
>
> They will treat it as anything else they don't quite understand -- they
> will ignore it unless it bites them. And the rule for finding the end of
> an annotation would be very simple -- just skip words until the next
> comma, close paren or colon, skipping matching brackets etc.

That's assuming the syntax in the annotations doesn't diverge too much
from the Python syntax as far as brackets etc are concerned. I must say
I'm not too worried about typing. But the hypothetic "def foo(prec:
--precision int):" is already less readable. Will finding the closing
comma or colon always be obvious to the human reader?

Cheers,
Baptiste
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/E654LKI36TFURBOSBMFUPEMLJQ32CZNN/
Code of Conduct: http://python.org/psf/codeofconduct/

On 4/14/21 1:42 PM, Baptiste Carvello wrote:
> Are there specific annoyances associated with quoting always, apart
> from the 2 more characters?


Yes.  Since the quoted strings aren't parsed by Python, syntax errors in
these strings go undetected until somebody does parse them (e.g. your
static type analyzer).  Having the Python compiler de-compile them back
into strings means they got successfully parsed.  Though this doesn't
rule out other errors, e.g. NameError.

I thought this was discussed in PEP 563, but now I can't find it, so
unfortunately I can't steer you towards any more info on the subject.


Cheers,


//arry/

On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote:

> That's assuming the syntax in the annotations doesn't diverge too
> much
> from the Python syntax as far as brackets etc are concerned. I must
> say
> I'm not too worried about typing. But the hypothetic "def foo(prec:
> --precision int):" is already less readable. Will finding the closing
> comma or colon always be obvious to the human reader?

To push the limit, let's add some default value:

def foo(prec: --precision int = 123):
    ...

vs.

def foo(prec: "--precision int" = 123):
    ...

And if a "type parameter" becomes numeric. For example:

def foo(prec: --max bar 3000 = 123):
    ...

vs.

def foo(prec: "--max bar 3000" = 123):
    ...

Now, the quotes seem even more readable as a delimiter.

Paul

Baptiste Carvello wrote:
> Le 14/04/2021 à 19:44, Guido van Rossum a écrit :

> > No, what I heard is that, since in *most* cases the string quotes are
> > not needed, people are surprised and annoyed when they encounter cases
> > where they are needed.

> Well, I had assumed quotes would be used in all cases for consistency.

That does seem like a reasonable solution. Redundant, ugly, and annoying, but safe and consistent. Sort of like using type constraints in the first place. :D

> > ... the rule for finding the end of
> > an annotation would be very simple -- just skip words until the next
> > comma, close paren or colon, skipping matching brackets etc.

> ... But the hypothetic "def foo(prec:
> --precision int):" is already less readable. Will finding the closing
> comma or colon always be obvious to the human reader?

Nope. "--" sometimes means "ignore the rest of the line, including the ")". At the moment, I can't remember where I've seen this outside of SQL, but I can guarantee that if I read it late enough at night, the *best* case would be that I notice the ambiguity, guess correctly and am only annoyed.

-jJ
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/MV3HQASUSAEKC332UFUDWQNONLCXZDRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Larry Hastings wrote:
> On 4/14/21 1:42 PM, Baptiste Carvello wrote:
> > Are there specific annoyances associated with quoting always, apart
> > from the 2 more characters?

> Yes.  Since the quoted strings aren't parsed by Python, syntax errors in
> these strings go undetected until somebody does parse them (e.g. your
> static type analyzer).

This is a real problem. But in theory, your code editor (and python) *could* parse the strings. They generally don't, but I'm not sure asking them to do that is much harder than asking them to deal with new syntax.

-jJ
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/JR2RKEEUI3WSIUBZOJ4J3EVRTVYGLXSU/
Code of Conduct: http://python.org/psf/codeofconduct/

I created simple benchmark:
https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d

This benchmark creates 1000 annotated functions and measure time to
load and exec.
And here is the result. All interpreters are built without --pydebug,
--enable-optimization, and --with-lto.

```
# Python 3.9 w/ stock semantics

$ python3 ~/ann_test.py 1
code size: 121011
unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
exec: avg: 0.395090194279328 +/- 0.001004608380122509

# Python 3.9 w/ PEP 563 semantics

$ python3 ~/ann_test.py 2
code size: 121070
unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
exec: avg: 0.24590165729168803 +/- 0.0003123404336687428

# master branch w/ PEP 563 semantics

$ ./python ~/ann_test.py 2
code size: 149086
unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
exec: avg: 0.11281821667216718 +/- 0.00011939747308270317

# master branch + optimization (*) w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
exec: avg: 0.11042822999879717 +/- 0.00018108884723599264

# co_annotatins reference implementation w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 229679
unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05

# co_annotatins reference implementation + optimization (*) w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 204963
unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
```

(*) I found constant folding creates new tuple every time even though
same tuple is in constant table.
See https://github.com/python/cpython/pull/25419
For co_annotations, I cherry-pick
https://github.com/python/cpython/pull/23056 too.


--
Inada Naoki <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/JEP4MXAHCVGQF7AI5OUUSGOENXAOR43O/
Code of Conduct: http://python.org/psf/codeofconduct/

I added memory usage data by tracemalloc.

```
# Python 3.9 w/ old semantics
$ python3 ann_test.py 1
code size: 121011
memory: (385200, 385200)
unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05
exec: avg: 0.4067857594229281 +/- 0.0006858555167675445

# Python 3.9 w/ PEP 563 semantics
$ python3 ann_test.py 2
code size: 121070
memory: (398675, 398675)
unmarshal: avg: 0.3352349083404988 +/- 7.749102039824168e-05
exec: avg: 0.24610224328935146 +/- 0.0008628035427956459

# master + optimization w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
memory: (193572, 193572)
unmarshal: avg: 0.31316645480692384 +/- 0.00011766086337841035
exec: avg: 0.11456295938696712 +/- 0.0017481202239372398

# co_annotations + optimization w/ PEP 649 semantics
$ ./python ~/ann_test.py 3
code size: 204963
memory: (208273, 208273)
unmarshal: avg: 0.597023528907448 +/- 0.00016614519056599577
exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
```

Summary:

* Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
* Importing time (unmarshal+exec) is about 0.7sec on old semantics and
PEP 649, 0.43sec on PEP 563.

On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki <songofacandy@gmail.com> wrote:
>
> I created simple benchmark:
> https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d
>
> This benchmark creates 1000 annotated functions and measure time to
> load and exec.
> And here is the result. All interpreters are built without --pydebug,
> --enable-optimization, and --with-lto.
>
> ```
> # Python 3.9 w/ stock semantics
>
> $ python3 ~/ann_test.py 1
> code size: 121011
> unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
> exec: avg: 0.395090194279328 +/- 0.001004608380122509
>
> # Python 3.9 w/ PEP 563 semantics
>
> $ python3 ~/ann_test.py 2
> code size: 121070
> unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
> exec: avg: 0.24590165729168803 +/- 0.0003123404336687428
>
> # master branch w/ PEP 563 semantics
>
> $ ./python ~/ann_test.py 2
> code size: 149086
> unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
> exec: avg: 0.11281821667216718 +/- 0.00011939747308270317
>
> # master branch + optimization (*) w/ PEP 563 semantics
> $ ./python ~/ann_test.py 2
> code size: 110488
> unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
> exec: avg: 0.11042822999879717 +/- 0.00018108884723599264
>
> # co_annotatins reference implementation w/ PEP 649 semantics
>
> $ ./python ~/ann_test.py 3
> code size: 229679
> unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
> exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05
>
> # co_annotatins reference implementation + optimization (*) w/ PEP 649 semantics
>
> $ ./python ~/ann_test.py 3
> code size: 204963
> unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
> exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
> ```
>
> (*) I found constant folding creates new tuple every time even though
> same tuple is in constant table.
> See https://github.com/python/cpython/pull/25419
> For co_annotations, I cherry-pick
> https://github.com/python/cpython/pull/23056 too.
>
>
> --
> Inada Naoki <songofacandy@gmail.com>



--
Inada Naoki <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/JIZ6PCV5SSIL7BUKZUCVF45OFNO4H26I/
Code of Conduct: http://python.org/psf/codeofconduct/

Thanks for doing this!  I don't think PEP 649 is going to be accepted or
rejected based on either performance or memory usage, but it's nice to
see you confirmed that its performance and memory impact is acceptable.


If I run "ann_test.py 1", the annotations are already turned into
strings.  Why do you do it that way?  It makes stock semantics look
better, because manually stringized annotations are much faster than
evaluating real expressions.

It seems to me that the test would be more fair if test 1 used real
annotations.  So I added this to "lines":

from types import SimpleNamespace
foo = SimpleNamespace()
foo.bar = SimpleNamespace()
foo.bar.baz = float

I also changed quote(t) so it always returned t unchanged.  When I ran
it that way, stock semantics "exec" time got larger.


Cheers,


//arry/

On 4/14/21 6:44 PM, Inada Naoki wrote:
> I added memory usage data by tracemalloc.
>
> ```
> # Python 3.9 w/ old semantics
> $ python3 ann_test.py 1
> code size: 121011
> memory: (385200, 385200)
> unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05
> exec: avg: 0.4067857594229281 +/- 0.0006858555167675445
>
> # Python 3.9 w/ PEP 563 semantics
> $ python3 ann_test.py 2
> code size: 121070
> memory: (398675, 398675)
> unmarshal: avg: 0.3352349083404988 +/- 7.749102039824168e-05
> exec: avg: 0.24610224328935146 +/- 0.0008628035427956459
>
> # master + optimization w/ PEP 563 semantics
> $ ./python ~/ann_test.py 2
> code size: 110488
> memory: (193572, 193572)
> unmarshal: avg: 0.31316645480692384 +/- 0.00011766086337841035
> exec: avg: 0.11456295938696712 +/- 0.0017481202239372398
>
> # co_annotations + optimization w/ PEP 649 semantics
> $ ./python ~/ann_test.py 3
> code size: 204963
> memory: (208273, 208273)
> unmarshal: avg: 0.597023528907448 +/- 0.00016614519056599577
> exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
> ```
>
> Summary:
>
> * Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
> * Importing time (unmarshal+exec) is about 0.7sec on old semantics and
> PEP 649, 0.43sec on PEP 563.
>
> On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki <songofacandy@gmail.com> wrote:
>> I created simple benchmark:
>> https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d
>>
>> This benchmark creates 1000 annotated functions and measure time to
>> load and exec.
>> And here is the result. All interpreters are built without --pydebug,
>> --enable-optimization, and --with-lto.
>>
>> ```
>> # Python 3.9 w/ stock semantics
>>
>> $ python3 ~/ann_test.py 1
>> code size: 121011
>> unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
>> exec: avg: 0.395090194279328 +/- 0.001004608380122509
>>
>> # Python 3.9 w/ PEP 563 semantics
>>
>> $ python3 ~/ann_test.py 2
>> code size: 121070
>> unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
>> exec: avg: 0.24590165729168803 +/- 0.0003123404336687428
>>
>> # master branch w/ PEP 563 semantics
>>
>> $ ./python ~/ann_test.py 2
>> code size: 149086
>> unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
>> exec: avg: 0.11281821667216718 +/- 0.00011939747308270317
>>
>> # master branch + optimization (*) w/ PEP 563 semantics
>> $ ./python ~/ann_test.py 2
>> code size: 110488
>> unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
>> exec: avg: 0.11042822999879717 +/- 0.00018108884723599264
>>
>> # co_annotatins reference implementation w/ PEP 649 semantics
>>
>> $ ./python ~/ann_test.py 3
>> code size: 229679
>> unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
>> exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05
>>
>> # co_annotatins reference implementation + optimization (*) w/ PEP 649 semantics
>>
>> $ ./python ~/ann_test.py 3
>> code size: 204963
>> unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
>> exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
>> ```
>>
>> (*) I found constant folding creates new tuple every time even though
>> same tuple is in constant table.
>> See https://github.com/python/cpython/pull/25419
>> For co_annotations, I cherry-pick
>> https://github.com/python/cpython/pull/23056 too.
>>
>>
>> --
>> Inada Naoki <songofacandy@gmail.com>
>
>