[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 > mecha

[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

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

On 4/16/21 5:00 PM, Guido van Rossum wrote: (3) Ditto run with Larry's branch (PEP 649, assuming it's on by default there -- otherwise, modify the source by inserting the needed future import at the top) The co_annotations stuff in my branch is gated with "from __future__ import co_annotati

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

I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I did find this SO post: https://stackoverflow.com/questions/52171982/new-annotations-break-inspection-of-dataclasses which is related, but not quite the same -- THAT issue was fixed. My issue does show up in this BPO: ht

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

On Fri, Apr 16, 2021 at 12:32 PM Larry Hastings wrote: > > > Please don't confuse Inada Naoki's benchmark results with the effect PEP > 649 would have on a real-world codebase. His artifical benchmark > constructs a thousand empty functions that take three parameters with > randomly-chosen annot

[Python-Dev] Re: Typing syntax and ecosystem

Hi Carl, > I think the first question to answer is, are the current mypy docs > (https://mypy.readthedocs.io/en/stable/) insufficient for this purpose, and > why? There’s certainly lots of great documentation in the mypy docs; it’s often my first go-to. > They do include both tutorial-style "

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

Hi all. My apologies if this is a topic that's been discussed already, but I wasn't able to locate anything in the archive on the subject. I was wondering if there's a fundamental reason for using PyThread_get_thread_ident instead of PyThread_get_thread_native_id for the value of the thread_id fie

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

Please don't confuse Inada Naoki's benchmark results with the effect PEP 649 would have on a real-world codebase.  His artifical benchmark constructs a thousand empty functions that take three parameters with randomly-chosen annotations--the results provides some insights but are not directl

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

Christian Heimes wrote: > On 16/04/2021 19.14, redrad...@gmail.com wrote: > > My personal stop of contributing in CPython is that it is written in pure C > > !! > > I wrote code in both: pure C and C++, but I like writing code in C++, > > because it simplifies things without losing perfomance > >

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

Antoine Pitrou wrote: > On Fri, 16 Apr 2021 18:08:58 - > "Denis Kotov" redrad...@gmail.com wrote: > > Okay lets try to discuss one by one: > > > > Readability - less code, most code is hidden by abstraction without losing > > performance > > > > In CPython code lots of stuff like Py_INCREF,

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

On Fri, 16 Apr 2021 18:08:58 - "Denis Kotov" wrote: > > Okay lets try to discuss one by one: > 1) Readability - less code, most code is hidden by abstraction without losing > performance > In CPython code lots of stuff like Py_INCREF, Py_DECREF .. it could be fixed > with C++ std::shared_pt

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

April 16, 2021 2:08 PM, "Denis Kotov" wrote: > edwin＠211mainstreet.net wrote: > >> Anyone who has done a language change on a project knows that it is a huge >> disruption. You need >> solid justification to make such a change. All I have seen in this thread is >> personal opinion. >> Since th

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

On Fri, Apr 16, 2021 at 5:28 PM Łukasz Langa wrote: > [snip] I say "compromise" because as Inada Naoki measured, there's still a > non-zero performance cost of PEP 649 versus PEP 563: > > - code size: +63% > - memory: +62% > - import time: +60% > > > Will this hurt some current users of typing? Y

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2021-04-09 - 2021-04-16) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7522 ( -2) closed 48086 (+78) total 55608 (+76) Open issues wi

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

Ethan Furman wrote: > On 4/16/21 10:43 AM, redrad...@gmail.com wrote: > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU > > or read some articles ... otherwise I will need to spend too many time > > providing evidences to you and after all you will probably will reject > >

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

edwin＠211mainstreet.net wrote: > Anyone who has done a language change on a project knows that it is a huge > disruption. You need solid justification to make such a change. All I have > seen in this thread is personal opinion. Since this is a personal opinion > exchange, I am of the humble o

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

On 16/04/2021 19.14, redrad...@gmail.com wrote: > My personal stop of contributing in CPython is that it is written in pure C !! > I wrote code in both: pure C and C++, but I like writing code in C++, because > it simplifies things without losing perfomance There are plenty of Open Source project

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

On 4/16/21 10:43 AM, redrad...@gmail.com wrote: Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU or read some articles ... otherwise I will need to spend too many time providing evidences to you and after all you will probably will reject anyway (because lots of people is

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

On 4/16/21 10:27 AM, redrad...@gmail.com wrote: Chris Angelico wrote: On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote: The benefits: You will link with high quality libstdc++ with lots of reusable containers without writing your own "buggy" one. C++ is much much more maintainable th

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

Anyone who has done a language change on a project knows that it is a huge disruption. You need solid justification to make such a change. All I have seen in this thread is personal opinion. Since this is a personal opinion exchange, I am of the humble opinion that the personal opinions of co

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

On 16/04/2021 19.39, Victor Stinner wrote: > A *fresh* build (after make clean) of CPython on my laptop (8 threads, > 4 CPU cores) takes 13 seconds using make -j10 and gcc -O0. A fresh > build in release mode (make -j10 and gcc -O3) takes 44 seconds on the > same laptop. $ make clean $ time make -

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

Thank you everyone for your responses. I entirely accept that I should have brought this up earlier, perhaps much earlier. In my defence, when PEP 563 first came on my radar I assumed that get_type_hint() would be improved before it became the default behaviour, AFAIK it hasn't really changed.

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

Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU or read some articles ... otherwise I will need to spend too many time providing evidences to you and after all you will probably will reject anyway (because lots of people is biased and they even do not understand that, it is

[Python-Dev] Re: Relaxing the annotation syntax

El vie, 16 abr 2021 a las 10:01, Walter Dörwald () escribió: > On 16 Apr 2021, at 16:59, Guido van Rossum wrote: > > If you look deeper, the real complaints are all about the backwards > incompatibility when it comes to locally-scoped types in annotations. I.e. > > def test(): > class C: ... > def

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

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 ... Please, answer me question, if you will go in gym two times, will you get stop training and say that it does not fit in your life ? __

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

Hi, I used C++ in the past to write a small game. My experience was that the compilation was quite slow and many compiler errors were hard to understand. I love the fact the CPython is written in C because its build time is under one minute for a fresh build, and way faster for an incremental bui

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

On Sat, Apr 17, 2021 at 3:32 AM wrote: > > Chris Angelico wrote: > > On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote: > > > The benefits: > > > > > > You will link with high quality libstdc++ with lots of reusable > > > containers without writing your own "buggy" one. > > > C++ is much

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

Thanks so much for this, I think it makes a lot of sense. You've saved me by explaining why PEP 563 semantics are problematic for pydantic far more articulately than I could have done. I can entirely see why PEP 563 made sense at the time, myself (and others in the "runtime use of annotations" com

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

Chris Angelico wrote: > On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote: > > The benefits: > > > > You will link with high quality libstdc++ with lots of reusable containers > > without writing your own "buggy" one. > > C++ is much much more maintainable than pure C. It drastically incr

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

On Sat, Apr 17, 2021 at 3:20 AM wrote: > > The benefits: > > 1. You will link with high quality libstdc++ with lots of reusable containers > without writing your own "buggy" one. > 2. C++ is much much more maintainable than pure C. It drastically increase > number of contributors that what like

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

The benefits: 1. You will link with high quality libstdc++ with lots of reusable containers without writing your own "buggy" one. 2. C++ is much much more maintainable than pure C. It drastically increase number of contributors that what like writing high quality and maintainable code without r

[Python-Dev] Re: Relaxing the annotation syntax

On 16 Apr 2021, at 16:59, Guido van Rossum wrote: If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotations. I.e. def test(): class C: ... def func(arg: C): ... return func typing.get_type_hints(test()) # r

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

> Are you sure about PEP 563 break it and discord.py can not fix it? PEP 563 has been supported by discord.py since the PEP was introduced -- the change was not particularly hard to support on my end. Newer versions of the library are even more supportive of things like `ForwardRef` and the like

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

Hi all, I got pinged to voice my opinion on PEP 649 as the instigator of PEP 563. I'm sorry, this is long, and a separate thread, because it deals with three things: - Goals set for PEP 563 and how it did in practice; - PEP 649 and how it addresses those same goals; - can we cleanly adopt PEP 649?

[Python-Dev] Re: Relaxing the annotation syntax

On Fri, Apr 16, 2021 at 1:51 AM Sebastian Rittau wrote: > I am strongly in favor of diverging type annotation syntax from Python > syntax. Currently, type annotations are a very useful tool, but often > clunky to use. Enhancements have been made, but design space is limited > when working within

[Python-Dev] Re: Relaxing the annotation syntax

If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotations. I.e. def test(): class C: ... def func(arg: C): ... return func typing.get_type_hints(test()) # raises NameError: name 'C' is not defined And that is a

[Python-Dev] Re: Typing syntax and ecosystem

Hi Barry & Luciano, Barry Warsaw wrote: > Actually, I think it’s time for a comprehensive guide to type annotations. > Just anecdotally, I was trying to annotate a library of mine and was having > an impossible time of it, until a chat with Guido lead me to > @typing.overload. That solved my

[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

The warnings.filterwarnings() function uses a regular expression for message and module arguments. My request is only about the Python command line interface. By the way, an user requested to use a regex for the module field of -W option and PYTHONWARNINGS env var: https://bugs.python.org/issue346

[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

16.04.21 16:07, Victor Stinner пише: > I propose to change the -W command line option and the PYTHONWARNINGS > environment variable to use the message as a regular expression in > Python 3.10. Or does anyone have a reason to keep the current behavior > as it is? > > I created https://bugs.python.o

[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

It'll probably be easier to change the warnings filter semantic (https://docs.python.org/3/library/warnings.html#the-warnings-filter) to which those values are directly passed. On 16.04.2021 16:07, Victor Stinner wrote: Hi, I propose to change the -W command line option and the PYTHONWARNINGS

[Python-Dev] Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

Hi, I propose to change the -W command line option and the PYTHONWARNINGS environment variable to use the message as a regular expression in Python 3.10. Or does anyone have a reason to keep the current behavior as it is? I created https://bugs.python.org/issue43862 for this change. -- Python p

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

On Fri, Apr 16, 2021 at 8:27 AM Inada Naoki wrote: > After PEP 563, only `'List[int]'` is practical so we can stop > supporting `List["int"]` and others at some point. > There's a lot of code written before PEP 563 was available (and code that needs to support earlier Python versions) that use

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

Guido: > It seems a little disingenuous to claim discussions about annotations don’t > concern you when you’re actively using them (for typing, no less, in the > case of pydantic). And I am sure a project as popular (by their own > description) as pydantic will find a way forward if PEP 649 is reje

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

24.03.21 11:54, redrad...@gmail.com пише: > What about of using modern C++ in developing CPython ? > > With C++ we can get the following benefits: > 1) Readability - less code, most code is hidden by abstraction without losing > performance > 2) Maintainability - no code duplication in favor of u

[Python-Dev] Re: Relaxing the annotation syntax

On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw > wrote: [snip] This is something the SC has been musing about, but as it’s not a fully formed idea, I’m a little hesitant to bring it up.  That said, it’s somewhat relevant: We wonder if it may be time to in a

[Python-Dev] Re: Typing syntax and ecosystem

Am 16.04.21 um 03:21 schrieb Barry Warsaw: Actually, I think it’s time for a comprehensive guide to type annotations. Just anecdotally, I was trying to annotate a library of mine and was having an impossible time of it, until a chat with Guido lead me to @typing.overload. That solved my problem

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

On Fri, 16 Apr 2021 10:35:19 +0900 Inada Naoki wrote: > > And personally, I love static typing but I don't use type hint for > performance/memory usage reason. > I spend much effort to optimize PEP 563 to minimize type hinting overhead. > So it's very sad that if I can not use type hinting when I

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

On Thu, 15 Apr 2021 16:12:57 -0700 Brett Cannon wrote: > > So I don't think version comparison occurs often enough to be in the > stdlib, and the fact that an external project exists which isn't interested > in being put in the stdlib suggests to me it isn't worth doing. > > But that's a separat

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

On Fri, Apr 16, 2021 at 6:03 AM Bluenix wrote: > > 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:/