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

On 4/15/21 9:24 PM, Inada Naoki wrote: Unlike simple function case, PEP 649 creates function object instead of code object for __co_annotation__ of methods. It cause this overhead. Can we avoid creating functions for each annotation? As the implementation of PEP 649 currently stands, there

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

> > I will read PEP 649 implementation to find missing optimizations other > than GH-25419 and GH-23056. > I found each "__co_annotation__" has own name like "func0.__co_annotation__". It increased pyc size a little. I created a draft pull request for cherry-picking GH-25419 and GH-23056 and

[Python-Dev] Re: In support of PEP 649

On 4/15/21 6:09 PM, Barry Warsaw wrote: On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11.

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 18:20 Barry Warsaw wrote: > On Apr 15, 2021, at 17:47, Oscar Benjamin > wrote: > > > > Would it be problematic to postpone making __future__.annotations the > default? > > This is a good question, and I think the SC would really like to know if > anybody has objections

[Python-Dev] Re: In support of PEP 649

On Fri, Apr 16, 2021 at 9:49 AM Oscar Benjamin wrote: > > > > That said, I agree it is better that this came up before the feature freeze > > than after the release. And I am willing to accept that the hypothetical > > future where annotations are not always syntactically expressions (which >

[Python-Dev] Re: Typing syntax and ecosystem

On Apr 15, 2021, at 17:49, Luciano Ramalho wrote: > Anyone who uses a language with support for static typing expects the > language distribution to include a type checker. Since that may be > beyond our means, then the least we could do is have some official > guidance on the matter, maybe in

[Python-Dev] Re: In support of PEP 649

On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: > > Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11. We haven’t discussed it yet (this

[Python-Dev] Re: Typing syntax and ecosystem

Today I stumbled upon another false positive on Mypy: https://github.com/python/mypy/issues/4660 . The issue is more than 3 years old, but it refers to a language feature (__init_subclass__) which was added in Python 3.6, released in late 2016. I understand that maintaining a type checker is a

[Python-Dev] Re: In support of PEP 649

On Fri, 16 Apr 2021 at 01:13, Guido van Rossum wrote: > > On Thu, Apr 15, 2021 at 16:48 Christopher Barker wrote: >> >> And as I noted in my last post — many folks have not been paying attention >> to the typing discussions because they didn’t realize it concerned them. > > It seems a little

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 16:48 Christopher Barker wrote: > And as I noted in my last post — many folks have not been paying attention > to the typing discussions because they didn’t realize it concerned them. > It seems a little disingenuous to claim discussions about annotations don’t concern

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

Thomas and the rest of the SC, Thank you for updating us and for your kind words about the PEP. We agree that it is safer to include this in 3.11 and not rush it into 3.10. As you say, having time to develop the integration with asyncio before finalizing the API will give us more confidence in

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 4:20 PM Brett Cannon wrote: > > Making this an "us versus them" discussion just makes the whole situation > feel confrontational when instead everyone is trying to figure out the best > thing for everybody when there's no perfect answer. > I agree that that was strong

[Python-Dev] Re: In support of PEP 649

It seems evident that the problems with PEP 563 have been well-known at least to pydantic for several years, as you can see in the issue Samuel Colvin linked: https://github.com/samuelcolvin/pydantic/issues/2678 That said, while I do think that "please contact upstream when you see a problem

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 12:01 PM Samuel Colvin wrote: > I've read the recent discussions > > regarding PEP 649 and PEP 563 with interest, Larry Hastings

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou wrote: > On Thu, 15 Apr 2021 10:28:53 -0700 > Brett Cannon wrote: > > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker > > wrote: > > > > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > > > wrote: > > > > > >> Paul Bryan: > > >> > Seems

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 3:29 PM Bernat Gabor wrote: > I'm a bit surprised that this topic is brought up just days before the feature freeze of Python 3.10. I have not idea about the technical details, but I think there is a bit of a discomment in the community: Annotations have been around for

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

On 4/15/21 2:02 PM, Sebastián Ramírez wrote: ## Questions I'm not very familiar with the internals of Python, and I'm not sure how the new syntax for `Union`s using the vertical bar character ("pipe", "|") work. But would PEP 649 still support things like this?: def run(arg: int | str = 0):

[Python-Dev] Re: In support of PEP 649

Hello, I'm a bit surprised that this topic is brought up just days before the feature freeze of Python 3.10. How did tools work until now with from future import annotations? This feature has been in the language for years (since 3.7), and I haven't heard until today anyone complaining about

[Python-Dev] Re: In support of PEP 649

On 4/15/21 2:49 PM, Paul Ganssle wrote: I haven't followed this closely enough — if PEP 649 were accepted today, would it even be ready for use before the 3.10 code freeze (which is in a few weeks)? Perhaps I'm a poor judge of the quality of my own code.   But I'd say I have a working

[Python-Dev] Re: In support of PEP 649

I've been working on a similar framework, Fondat [1], that shares similar objectives as Pydantic and FastAPI, albeit implementing in a different manner.  I believe other frameworks will have to "run a gauntlet" (as I already have)  to deal with the affects of PEP 563. If anyone on these teams are

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

Replying to myself to update my own thoughts: I think __version__ and packaging tools answer separate questions. __version__ answers the question of "this module I imported, what version is it". The packaging tools answer the question "what dependency does this distribution satisfy". This

[Python-Dev] Re: In support of PEP 649

I should point out that "accept PEP 649" and "break pydantic" are not the only options here. The thing that will break pydantic is the end of PEP 563's deprecation period, not a failure to implement PEP 649. Other viable options include: - Leave PEP 563 opt-in until we can agree on a solution to

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 at 21:03, Christopher Barker wrote: > I am leaning toward at least SOME PEP about this -- having __version__ > around as a semi-convention with no official recommendation as to if or how > it should be used is kind of a mess. On the other hand, having a PEP that says you

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:54 PM Christopher Barker wrote: > Or rather, the below is what I would find really nice to be able to do. > >> ver = robust_version(module) >> if ver >= (5, 2, 1): >> doit_modern_style() >> elif ver < (5, 2, 1): >> doit_old_style >> else: >>

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

Thanks Brett Cannon for suggesting to get Samuel Colvin (Pydantic) and me, Sebastián Ramírez (FastAPI and Typer) involved in this. TL;DR: it seems to me PEP 649 would be incredibly important/useful for Pydantic, FastAPI, Typer, and similar tools, and their communities. ## About FastAPI,

[Python-Dev] Re: In support of PEP 649

Please accept PEP 649! Python's type hinting has become so much more useful than originally thought, and without this change much of that will be hindered. For example (you already know about Pydantic and FastAPI) [discord.py](https://github.com/Rapptz/discord.py)'s commands system allows you

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote: > I was so hopeful about this, but in the end... not really. I have not > used this capability before. Here are a few different situations I know of: > ... ... re PackageNotFoundError('re') statistics PackageNotFoundError('statistics')

[Python-Dev] Re: How about using modern C++ in development of CPython ?

@Christian Heimes RAII is more than cleaning resource at the end of function, it is that while you are using class - resource will be available ... You can move resource using modern C++ `std::move` ant lots of other features that could improve readability and maintainability of the code

[Python-Dev] Re: In support of PEP 649

I haven't commented on these, as I don't use type annotations in the "usual" way., but: On Thu, Apr 15, 2021 at 12:06 PM Samuel Colvin wrote: > I maintain pydantic which uses > type annotations to provide runtime data validation. > I maintain in in-house

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 12:27 PM Terry Reedy wrote: > At least some in the stdlib have not been. For re.__version__, not > since Nov 2001. > >From Serhiy over on python-ideas, he's started an effort to clean that up.

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:38 AM Barry Warsaw wrote: > From a library maintainers point of view, I personally want to get away > from using __version__ strings at all. They’re kind of a pain to remember > to bump on every new release. That’s a tooling issue, and I don’t think that Python

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On 4/15/2021 12:35 PM, David Mertz wrote: re 2.2.1 re.__version__ was last modified 2001-10-07 by F. Lundh in bec95b9d8825b39cff46a8c645fa0eeb8409854e. What does '2.2.1' mean? Only Fredrik knows. The commit message says that he rewrote the pattern.sub and pattern.subn methods in C.

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On 4/15/2021 12:38 PM, Barry Warsaw wrote: On Apr 14, 2021, at 23:11, Christopher Barker wrote: You wrote the original PEP, so of course you can withdraw it (or reject it), but... Are you sure? See this discussion, I don't think it's as simple as all that. From a library maintainers

[Python-Dev] In support of PEP 649

I've read the recent discussions regarding PEP 649 and PEP 563 with interest, Larry Hastings recently contacted me when prompted

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

Replying to the original email because my comment is more a thought after reading the whole thread rather than a response to any particular message. What I love about __version__ is that it is simple. It doesn't come with the complexity of solutions like `importlib.metadata.version`. The

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Apr 15, 2021, at 09:54, Antoine Pitrou wrote: > > On Thu, 15 Apr 2021 09:38:41 -0700 > Barry Warsaw wrote: >> On Apr 14, 2021, at 23:11, Christopher Barker wrote: >>> >>> You wrote the original PEP, so of course you can withdraw it (or reject >>> it), but... >>> >>> Are you sure? See

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 10:28:53 -0700 Brett Cannon wrote: > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker > wrote: > > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > > wrote: > > > >> Paul Bryan: > >> > Seems like this is something that should make its way into stdlib? > >> > >> In

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

Irit, Yury and Guido, Thanks for submitting PEP 654 (Exception Groups and except *). The Steering Council isn’t done debating this PEP, but we wanted to give an update so everyone knows what to expect. We are mostly in favour of the PEP, but we’re worried about the timing -- not just because

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker wrote: > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > wrote: > >> Paul Bryan: >> > Seems like this is something that should make its way into stdlib? >> >> In the last 10 years, the trend is more to remove anything related to >> packaging

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote: > On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker > wrote: > >> Presumably that's why importlib.metadata exists in the stdlib. >> > > I was so hopeful about this, but in the end... not really. I have not > used this capability before. Here

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 09:38:41 -0700 Barry Warsaw wrote: > On Apr 14, 2021, at 23:11, Christopher Barker wrote: > > > > You wrote the original PEP, so of course you can withdraw it (or reject > > it), but... > > > > Are you sure? See this discussion, I don't think it's as simple as all > >

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Apr 14, 2021, at 23:11, Christopher Barker wrote: > > You wrote the original PEP, so of course you can withdraw it (or reject it), > but... > > Are you sure? See this discussion, I don't think it's as simple as all that. From a library maintainers point of view, I personally want to get

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker wrote: > Presumably that's why importlib.metadata exists in the stdlib. > I was so hopeful about this, but in the end... not really. I have not used this capability before. Here are a few different situations I know of: >>> import re,

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner wrote: > Paul Bryan: > > Seems like this is something that should make its way into stdlib? > > In the last 10 years, the trend is more to remove anything related to > packaging *outside* the stdlib :-) Well, maybe all of us don't think that's a

[Python-Dev] Re: Boundaries between numbers and identifiers

This isn't a "professional" or probably even "valid" use case for Python but one area this behavior is heavily used is code golf. For those not familiar with code golf is a type of puzzle where the objective is to complete a set of requirements in the least number of source code characters as

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

> On 15 Apr 2021, at 14:48, Antoine Pitrou wrote: > > On Thu, 15 Apr 2021 14:32:05 +0200 > Victor Stinner wrote: >> SOURCE_DATE_EPOCH is not a random variable, but is a *standardised* >> environment variable: >> https://reproducible-builds.org/docs/source-date-epoch/ > > Standardized by

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Thu, 15 Apr 2021 14:32:05 +0200 Victor Stinner wrote: > SOURCE_DATE_EPOCH is not a random variable, but is a *standardised* > environment variable: > https://reproducible-builds.org/docs/source-date-epoch/ Standardized by whom? This is not a POSIX nor Windows standard at least. Just because a

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

SOURCE_DATE_EPOCH is not a random variable, but is a *standardised* environment variable: https://reproducible-builds.org/docs/source-date-epoch/ This page explains the rationale. See the “Lying about the time” / “violates language spec” section ;-) More and more projects adopted it. As I wrote,

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Thu, 15 Apr 2021 11:28:03 +0200 Victor Stinner wrote: > If gzip is modified to use SOURCE_DATE_EPOCH timestamp, you get a > reproducible binary and you don't need to add a new constant ;-) > SOURCE_DATE_EPOCH is a timestamp: number of seconds since Unix Epoch > (January 1, 1970 at 00:00).

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 11:37:28 +0200 Victor Stinner wrote: > Paul Bryan: > > Seems like this is something that should make its way into stdlib? > > In the last 10 years, the trend is more to remove anything related to > packaging *outside* the stdlib :-) Since it's evolving way faster What is

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

Paul Bryan: > Seems like this is something that should make its way into stdlib? In the last 10 years, the trend is more to remove anything related to packaging *outside* the stdlib :-) Since it's evolving way faster than Python releases and the stdlib cannot be updated once installed, I don't

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

If gzip is modified to use SOURCE_DATE_EPOCH timestamp, you get a reproducible binary and you don't need to add a new constant ;-) SOURCE_DATE_EPOCH is a timestamp: number of seconds since Unix Epoch (January 1, 1970 at 00:00). Victor On Wed, Apr 14, 2021 at 8:15 PM wrote: > > The gzip

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

I updated the benchmark little: * Added no annotation mode for baseline performance. * Better stats output. https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d ``` # No annotation (master + GH-25419) $ ./python ~/ann_test.py 0 code size: 102967 bytes memory: 181288 bytes unmarshal:

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, Apr 14, 2021 at 2:23 PM Paul Moore wrote: > >> because PEP 440 versions are fundamental to packaging. > > > > Are you suggesting that users should have to install an external module > to tell what version of packages they are using?! > > No. To tell what version of a package they are

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, Apr 14, 2021 at 12:10 PM Barry Warsaw wrote: I’d forgotten that this PEP was in Deferred state. I think it should be > rejected and I plan on making that change. importlib.metadata is a much > better approach to programmatically determining package versions. > > >