[Python-Dev] Re: Relaxing the annotation syntax

Hm, I was specifically thinking of things that introduce new keywords. For example, TypeScript adds unary operators 'infer' and 'keyof'. It would be rather difficult to have to define those as soft keywords throughout the language. (We couldn't just make them unary keywords, since 'infer (x)'

[Python-Dev] PEP 563 and 649: The Great Compromise

The heart of the debate between PEPs 563 and 649 is the question: what should an annotation be?  Should it be a string or a Python value?  It seems people who are pro-PEP 563 want it to be a string, and people who are pro-PEP 649 want it to be a value. Actually, let me amend that slightly. 

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

On 4/17/2021 6:44 PM, Christopher Barker wrote: On Sat, Apr 17, 2021 at 6:12 AM Eric V. Smith > wrote: I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I have! Thanks Eric. In retrospect, that field probably should have

[Python-Dev] Re: Relaxing the annotation syntax

On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, wrote: > > At the very least I recommend that the SC take this into account when they > consider PEP 649. Accepting it has some nice benefits when it comes to the > scoping rules for annotations -- but it would forever close the door for > the

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

On Sun, 18 Apr 2021, 2:47 am Antoine Pitrou, wrote: > On Sun, 18 Apr 2021 02:13:57 +1000 > Nick Coghlan wrote: > > > > If > > they want automatic resource management, then we want them working out > how > > to lift the affected code out of C and into Python (for example, the > import > > system

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

On Sat, Apr 17, 2021 at 6:12 AM Eric V. Smith wrote: > I wonder if anyone has considered the impact of PEP 563 on dataclasses ? > > I have! > Thanks Eric. > In retrospect, that field probably should have been named "annotation". > Regardless, the intent was always "store what's in >

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

Related, `inspect.Parameter.annotation` is affected too, but at least this attribute is called `annotation` instead of `type`. I noticed this today with `multipledispatch` (though [reported](https://github.com/mrocklin/multipledispatch/issues/104) in 2019) and some other internal code, both

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

On Sun, 18 Apr 2021 02:13:57 +1000 Nick Coghlan wrote: > > If > they want automatic resource management, then we want them working out how > to lift the affected code out of C and into Python (for example, the import > system rewrite). There's a significant amount of wishful thinking here.

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

On Sun, 18 Apr 2021, 1:59 am Jelle Zijlstra, wrote: > El sáb, 17 abr 2021 a las 8:30, Nick Coghlan () > escribió:. > >> >> Metaclass __prepare__ methods can inject names into the class namespace >> that the compiler doesn't know about, so yeah, it unfortunately has to be >> conservative and use

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

On Sat, 17 Apr 2021, 3:51 am , wrote: > Guys, the issue is that I most of the time see that somebody used C++ for > one or two times, did not understand it and left with bad taste ... > I've got more than a decade and a half of experience with both C++ (dating back to the relatively low quality

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

El sáb, 17 abr 2021 a las 8:30, Nick Coghlan () escribió: > > > On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote: > >> >> Anyway I assume it wasn't "fixable". The compiler would presumably >> already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL >> would be cheaper every

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

On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote: > > Anyway I assume it wasn't "fixable". The compiler would presumably > already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL > would be cheaper every time for a global or builtin. The fact that it > already doesn't do so

[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences

Thanks for picking this back up! The deferral section can go away now that you're actively working on it again, and +1 from me on the resolution of the previously open questions (although I wouldn't be particularly upset if the SC considered bchr redundant, given that "bchr = bytes.fromord" is a

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

El vie, 16 abr 2021 a las 21:32, Christopher Barker () escribió: > ... > dataclasses may be the only part of the stdlib that uses annotations. > > > There's another one, actually: functools.singledispatch, at https://github.com/python/cpython/blob/3.9/Lib/functools.py#L860. It uses the

[Python-Dev] Re: PEP 563 in light of PEP 649

Obviously that's a bug.  Can you send me this test case?  Anything works--Github, private email, whatever is most convenient for you.  Thank you! //arry/ On 4/16/21 11:22 PM, Inada Naoki wrote: ## memory error on co_annotations I modifled py_compile to add `from __future__ import

[Python-Dev] f_lasti not correct with PREDICT (is it fixable?)

Hi all, I currently have a use-case where I need to rely on `f_lasti`, but it seems that it's not really possible to rely on it as it doesn't accurately point to the actual bytecode last executed when PREDICT is used. So, I'd like to know: is it possible to change that so that the `f_lasti` is

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

On 4/17/2021 12:28 AM, Christopher Barker wrote: I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I have! I did find this SO post: https://stackoverflow.com/questions/52171982/new-annotations-break-inspection-of-dataclasses

[Python-Dev] Memory use of PEP 563 vs PEP 649

Hi, There has been some discussion on this mailing list about the memory use of PEP 563 vs PEP 649. It doesn't matter. The memory use of either is small, and any measurements are merely measuring artifacts of the current implementations, and the current on-disk representation of code

[Python-Dev] Re: Question regarding the value of PyThreadState.thread_id

Hi Victor Thanks for your reply. Indeed, upon further investigation, I have realised changing the value of thread_id is not wise as there are other methods that expect this field to be a pthread_t. I have opened issue https://bugs.python.org/issue43879https://bugs.python.org/issue43879 to have

[Python-Dev] Re: PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer

On 30/03/2021 13.46, Pablo Galindo Salgado wrote: > Hi Christian, > > Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating > the situation and discussing the PEP, the Steering Council is happy with > the PEP, > and hereby accepts it. The SC is of the opinion that this change

[Python-Dev] Re: Question regarding the value of PyThreadState.thread_id

Hi, There are two reasons: * PyThread_get_thread_native_id() was only added recently (Python 3.8) * PyThread_get_thread_native_id() is not portable and not available on all platforms: the function is only declared if the PY_HAVE_THREAD_NATIVE_ID macro is defined. Maybe PyThreadState.thread_id

[Python-Dev] Re: PEP 563 in light of PEP 649

On Sat, Apr 17, 2021 at 1:38 PM Guido van Rossum wrote: > > I'm not going to report results, but we could use mypy itself as an example > real-world code base. Mypy is almost 100% annotated. It does not include > `from __future__ import annotations` lines but those could easily be added >

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

Denis, There's a standard way of interesting the Python community in new syntax (and C++, while not Python, is new syntax in spades to this community ;-). You take a hunk of the standard library (in this case it would have to be an accelerator written in C since you want to compare C++ vs. C) or