[Python-Dev] Re: Switching to Discourse

On 06. 12. 22 11:16, Baptiste Carvello wrote: Hi, Le 05/12/2022 à 14:50, Stephen J. Turnbull a écrit : I'd be sad, but I get the feeling that the only people left reading it are "here for the community", not to develop code, … I think this is indeed true, but that's nothing to be sad

[Python-Dev] Re: Switching to Discourse

On 01. 12. 22 17:28, Victor Stinner wrote: What happened to this SC decision (move to Discourse)? People started again to write on python-dev. So what's going on? PEPs must be announced on Discourse. For discussions you can use any medium. A list, Discord, IRC, in-person chat... Should I

[Python-Dev] Re: Moving to Discourse

On 21. 09. 22 10:17, Baptiste Carvello wrote: Hello, good to see that someone in the Steering Council still reads here, as some of the actions necessary to make either mailing-list mode or RSS a viable alternative [1] need an official "hat": * mailing-list mode: there needs to be a

[Python-Dev] Moving to Discourse

As mentioned previously [0], the Steering Council decided to switch from python-dev to Discourse (discuss.python.org). We're aware that Discourse is not perfect. The previous mail thread [0] lists various shortcomings, as well as some workarounds. However, we don't see anything that would block

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

On 20. 09. 22 10:59, Petr Viktorin wrote: On 19. 09. 22 17:58, Guido van Rossum wrote: Personally I think returning None is a fine API design, and IMO the concerns about this pattern are overblown. Note that X|None is no different than the "Maybe X" pattern that functional programme

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

On 19. 09. 22 17:58, Guido van Rossum wrote: Personally I think returning None is a fine API design, and IMO the concerns about this pattern are overblown. Note that X|None is no different than the "Maybe X" pattern that functional programmers are so fond of. I must disagree here. With

[Python-Dev] Re: Switching to Discourse

On 21. 07. 22 9:01, Cameron Simpson wrote: On 21Jul2022 13:25, Stephen J. Turnbull wrote: Cameron Simpson writes: Discourse does not do `In-Reply-To:` very well at all. Here's some headers from the _second_ post in the "Core dev sprint this year" thread: Message-ID: In-Reply-To:

[Python-Dev] Re: Switching to Discourse

t category on Discourse is more active than this mailing list (python-dev). On Fri., Jul. 15, 2022, 2:22 p.m. Petr Viktorin, <mailto:encu...@gmail.com>> wrote: Hello, Currently development discussions are split between multiple communication channels, for exampl

[Python-Dev] Re: Switching to Discourse

On 15. 07. 22 20:59, Ethan Furman wrote: On 7/15/22 08:37, Petr Viktorin wrote: > And that's exactly why I consume Discourse in mailing list mode, with client-side > filtering in Thunderbird. How do you handle threading?  I follow each (sub)thread through to it's end, as it

[Python-Dev] Re: Switching to Discourse

On 16. 07. 22 8:48, Miro Hrončok wrote: On 15. 07. 22 13:18, Petr Viktorin wrote: - You can use discuss.python.org's “mailing list mode” (which subscribes you to all new posts), possibly with filtering and/or categorizing messages locally. Hello Petr, I suppose this might be the preferred

[Python-Dev] Re: [SPAM] Re: Switching to Discourse

On 15. 07. 22 17:34, Phil Thompson via Python-Dev wrote: On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote: 100% agree – dealing with 5 or more platforms for discussion groups is a nightmare, and I tend not to follow any of them as closely for that reason. I agree. I don't mind having to

[Python-Dev] Re: Switching to Discourse

On 15. 07. 22 16:24, Skip Montanaro wrote: The discuss.python.org experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev.

[Python-Dev] New `python` Organization Repository Policy

(Cross-posted from https://discuss.python.org/t/new-python-organization-repository-policy/17376 – please perfer commenting there.) Hello, When asked about adding the typing_extensions repository to the Python organization (https://github.com/python/steering-council/issues/126), the Steering

[Python-Dev] Switching to Discourse

Hello, Currently development discussions are split between multiple communication channels, for example: - python-dev and discuss.python.org for design discussions, - GitHub Issues and Pull Requests for specific changes, - IRC, Discord and private chats for real-time discussions, -

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

On 12. 07. 22 6:30, Guido van Rossum wrote: After several rounds of debate on typing-sig, I'd like to request feedback on PEP 695: https://peps.python.org/pep-0695/ I am sponsoring this PEP, which was written by Eric Traut. The PEP attempts to solve the

[Python-Dev] Re: [Release] Python 3.11.0b4 is still blocked

On 04. 07. 22 19:03, Miro Hrončok wrote: On 04. 07. 22 18:53, Pablo Galindo Salgado wrote: Hi Miro,  >> Are all release blockers automatically blocking the next beta? Yes.  >> Or does it mean this should not be released in final (and hence neither rc) versions? Release blockers block also

[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms

On 06. 06. 22 20:05, Steve Dower wrote: +1. Glad it's not just me On 6/6/2022 2:36 PM, Victor Stinner wrote: First, I understood that "Arbitrary Literal String Type" was adding a new built-in types for "literal strings" :-) Nope. It's just about type annotations ;-) I was also excited

[Python-Dev] Accepting PEP 681 – Data Class Transforms

Hello, With the latest wording changes, PEP 681 – Data Class Transforms is now fully accepted. Feel free to mark it as such at your convenience. Happy typing, — Petr, on behalf of the Steering Council On 23. 04. 22 13:26, Petr Viktorin wrote: Hello, As an initial implementation

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

very helpful. On Thu, May 5, 2022 at 1:55 PM Petr Viktorin wrote: > > On Thu, May 5, 2022 at 5:35 AM Thomas Wouters wrote: > [...] > > > > > > I've already brought this up to Petr directly, but I would greatly prefer > > new unstable API functions have leadi

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

On Thu, May 5, 2022 at 5:35 AM Thomas Wouters wrote: [...] > > > I've already brought this up to Petr directly, but I would greatly prefer new > unstable API functions have leading underscores, and that existing functions > being moved to the unstable API are _not_ renamed. > > Renaming

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

On 29. 04. 22 19:02, Guido van Rossum wrote: On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 29. 04. 22 16:32, Victor Stinner wrote: > Ok, let me start with the serious business: API name. > > I'm not comfortable

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

On 29. 04. 22 16:32, Victor Stinner wrote: Ok, let me start with the serious business: API name. I'm not comfortable with "semi-stable". Python already has a "limited API" and a "stable ABI". Just by its name, it's unclear what "semi-stable" means. Honestly, I would be more comfortable with

[Python-Dev] PEP 689 – Semi-stable C API tier

/#MA4FQ7G6F35NG3TUN6RQPXRGXTYMFMDY Implementation notes: https://github.com/python/cpython/issues/91744 Here's the current version for easy quoting: -- PEP: 689 Title: Semi-stable C API tier Author: Petr Viktorin Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 523 Created: 22

[Python-Dev] Re: Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

On 23. 04. 22 3:15, Larry Hastings wrote: Here's one alternate idea for how to implement the "forward class" syntax. The entire point of the "forward class" statement is that it creates the real actual class object.  But what if it wasn't actually the "real" class object?  What if it was only

[Python-Dev] Almost accepting PEP 681 – Data Class Transforms

Hello, As an initial implementation that will be improved in the future, the specification in PEP 681 is fine. Feel free to add the decorator to Python 3.11 at your convenience. However, the PEP includes several worrying recommendations like: - we recommend that the maintainers of attrs move

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 22. 04. 22 14:47, Fabio Zadrozny wrote: Em sex., 22 de abr. de 2022 às 09:02, Petr Viktorin <mailto:encu...@gmail.com>> escreveu: Hello Fabio, Let's talk a bit about which API should, exactly, be guaranteed to not change across minor releases. So far it l

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

Hello Fabio, Let's talk a bit about which API should, exactly, be guaranteed to not change across minor releases. So far it looks like: - PyEval_RequestCodeExtraIndex - PyCode_GetExtra - PyCode_SetExtra - PyFrameEvalFunction - PyInterpreterState_GetEvalFrameFunc -

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

Here's the issue with the plan (including Nick's suggestions): https://github.com/python/cpython/issues/91744 On Sun, Apr 10, 2022 at 5:43 AM Nick Coghlan wrote: > > On Thu, 7 Apr 2022, 8:02 pm Petr Viktorin, wrote: >> >> So here's my proposal: >> >> - This API sta

[Python-Dev] Re: [External] : Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 06. 04. 22 9:23, Tim Felgentreff wrote: Hi, (I briefly commented also on the doc regarding this) I’m probably misinterpreting the exact goals. I read “stable ABI for everyone” and I’m thinking “what needs to happen to stay binary compatible and working for a couple of decades at least”.

[Python-Dev] Re: Updating inspect APIs

On 17. 04. 22 19:20, Pablo Galindo Salgado wrote: Hi, We are currently debating in gh-88116 (https://github.com/python/cpython/issues/88116 ) what's the best way forward to update the APIs in the inspect module to include the new position

[Python-Dev] Accepting PEP 670 – Convert macros to functions in the Python C API

Hello, The Steering Council is **Accepting** the latest iteration of PEP 670: Convert macros to functions in the Python C API. Congratulations! - Petr, on behalf of the Steering Council ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] PEP 687 – Isolating modules in the standard library

Hello, Please provide any feedback you might have on PEP 687 – Isolating modules in the standard library: https://peps.python.org/pep-0687/ From recent discussions around “what should have a PEP”, it’s clear that this should have been a PEP long ago. Better late than never, I guess! We

[Python-Dev] Heads-up: Converting Misc/stable_abi.txt to TOML

Hello, Now that tomllib is in the stdlib, I'd like to convert the stable ABI manifest (Misc/stable_abi.txt) to TOML to make it easier to work with. To get proper highlighting in editors, I'd like to rename it from .txt to .toml. So, when the command that uses it stops working for you, change

[Python-Dev] Re: About PEPs being discussed on Discourse

On 08. 04. 22 13:40, Greg Ewing wrote: On 8/04/22 12:13 pm, Gregory P. Smith wrote: And for lurkers and subscribers here to enable email notifications for categories of interest over there. Is it possible to participate in a Discourse discussion entirely by email, without having to visit the

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 07. 04. 22 17:10, Victor Stinner wrote: On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin wrote: - This API stays with the regular public API (Include/cpython/), but to use it you'll need to #define Py_USING_UNSTABLE_API (name up for bikeshedding). Since there is already something similar

[Python-Dev] Re: About PEPs being discussed on Discourse

On 08. 04. 22 1:26, Ethan Furman wrote: On 4/7/22 07:31, Petr Viktorin wrote: On 07. 04. 22 15:59, Victor Stinner wrote: Would it be possible to announce new PEPs on python-dev please? Currently, all PEPs should be announced on python-dev, but not necessarily right after they're published

[Python-Dev] Re: About PEPs being discussed on Discourse

On 07. 04. 22 15:59, Victor Stinner wrote: Hi, Would it be possible to announce new PEPs on python-dev please? Currently, all PEPs should be announced on python-dev, but not necessarily right after they're published. They should be announced before submitting them to SC, though. I don't

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

So here's my proposal: - This API stays with the regular public API (Include/cpython/), but to use it you'll need to #define Py_USING_UNSTABLE_API (name up for bikeshedding). - Since we're nearing Beta and there's no rush to break things, in 3.11 you only get a warning if you try to use it

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 03. 02. 22 1:40, Guido van Rossum wrote: [...] I understand the CPython is stuck supporting the de-facto standard C API for a long time. But unless we pick a "north star" (as people call it nowadays) of what we want to support in say 5-10 years, the situation will never improve. My

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 01. 04. 22 11:01, Victor Stinner wrote: Hi, Update on this issue: I merged my 2 PRs. https://bugs.python.org/issue46850 The following APIs have been moved to the internal C API: - _PyFrameEvalFunction type - _PyInterpreterState_GetEvalFrameFunc() - _PyInterpreterState_SetEvalFrameFunc()

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 30. 03. 22 17:42, Guido van Rossum wrote: In the not so distant past I have proposed to introduce a new category, "Unstable APIs". These are public but are not guaranteed to be backwards compatible in feature releases (though I feel they should remain so in bugfix releases). I'm not sure

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 28. 03. 22 17:34, Skip Montanaro wrote: Barry writes (in part): We could still distribute “sumo” releases which include all the batteries, but develop and maintain them outside the cpython repo, and even release them separately on PyPI. It’s *possible* but I don’t know if it’s *practical*.

[Python-Dev] Re: import * and __future__ imports

On 28. 03. 22 15:25, Irit Katriel via Python-Dev wrote: If you have a __future__ import in a script, and you import * from it in another script, the object for this future appears in the dir() of the other script, even though the __future__ import has no effect there. % cat x.py from

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 24. 03. 22 20:06, Fabio Zadrozny wrote: Em qui., 24 de mar. de 2022 às 15:39, Fabio Zadrozny > escreveu: PEP 523 API added more private functions for code objects: * _PyEval_RequestCodeExtraIndex() * _PyCode_GetExtra() *

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 22. 03. 22 19:07, Victor Stinner wrote: Hi, I proposed two PRs to move the private C API (Include/cpython/) of PEP 523 "Adding a frame evaluation API to CPython" to the internal C API (Include/internals/): * https://github.com/python/cpython/pull/32052 *

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 3)

On 12. 03. 22 2:45, Eric Snow wrote: responses inline I'll snip some discussion for a reason I'll get to later, and get right to the third alternative: [...] "Special-casing immortal objects in tp_dealloc() for the relevant types (but not int, due to frequency?)" sounds promising. The

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 3)

On 10. 03. 22 3:35, Jim J. Jewett wrote: "periodically reset the refcount for immortal objects (only enable this if a stable ABI extension is imported?)" -- that sounds quite expensive, both at runtime and maintenance-wise. As I understand it, the plan is to represent an immortal object by

[Python-Dev] Re: PEP 684: A Per-Interpreter GIL

On 09. 03. 22 4:38, Eric Snow wrote: I'd really appreciate feedback on this new PEP about making the GIL per-interpreter. Yay! Thank you! This PEP definitely makes per-interpreter GIL sound possible :) The PEP targets 3.11, but we'll see if that is too close. I don't mind waiting one more

[Python-Dev] Re: PEP 684: A Per-Interpreter GIL

Oops, I hit Send by mistake! Please disregard the previous message (I often draft questions I later find answered, so I delete them.) On Wed, Mar 9, 2022 at 5:53 PM Petr Viktorin wrote: > > On 09. 03. 22 4:38, Eric Snow wrote: > > I'd really appreciate feedback on this new PEP

[Python-Dev] Re: PEP 684: A Per-Interpreter GIL

On 09. 03. 22 4:38, Eric Snow wrote: I'd really appreciate feedback on this new PEP about making the GIL per-interpreter. Yay! Thank you! The PEP targets 3.11, but we'll see if that is too close. I don't mind waiting one more release, though I'd prefer 3.11 (obviously). Regardless, I

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 3)

On 09. 03. 22 4:58, Eric Snow wrote: On Mon, Feb 28, 2022 at 6:01 PM Eric Snow wrote: The updated PEP text is included below. The largest changes involve either the focus of the PEP (internal mechanism to mark objects immortal) or the possible ways that things can break on older 32-bit stable

[Python-Dev] Re: Defining tiered platform support

On 08. 03. 22 0:30, Brett Cannon wrote: On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes <mailto:christ...@python.org>> wrote: On 07/03/2022 18.02, Petr Viktorin wrote: >> Why the devguide? I view the list of platforms as important for public

[Python-Dev] Re: Defining tiered platform support

On 04. 03. 22 21:48, Brett Cannon wrote: On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 04. 03. 22 0:30, Brett Cannon wrote: > Do we officially support NetBSD? Do you know how to find out if we do? > You migh

[Python-Dev] Re: RFC on PEP 655: Required[] and NotRequired[] for TypedDict

Hello, I'm sorry for my late reply -- keeping up with all the PEPs is somewhat challenging. The one nitpick I have is that the PEP should make a few things more clear to people outside the typing-sig: - if this PEP really only affects typing.py and external projects/tools, it should say so

[Python-Dev] Re: Defining tiered platform support

On 04. 03. 22 0:30, Brett Cannon wrote: Do we officially support NetBSD? Do you know how to find out if we do? You might think to look at https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that just loosely

[Python-Dev] Re: Version 2 of PEP 670 – Convert macros to functions in the Python C API

On 23. 02. 22 20:15, Victor Stinner wrote: On Wed, Feb 23, 2022 at 7:11 PM Petr Viktorin wrote: I did realize there's one more issue when converting macros or static inline functions to regular functions. Regular functions' bodies aren't guarded by limited API #ifdefs, so if they are part

[Python-Dev] Re: Version 2 of PEP 670 – Convert macros to functions in the Python C API

On 22. 02. 22 13:41, Victor Stinner wrote: Hi, Since Erlend and me posted PEP 670 on python-dev last October, we took all feedback (python-dev and Steering Council) in account to clarify the intent of the PEP and to reduce its scope (remove *any* risk of backward compatibility). PEP 670:

[Python-Dev] Re: SC reply to PEP 674 -- Disallow using macros as l-values

On 22. 02. 22 15:10, Victor Stinner wrote: Hi, Thanks for looking into my PEP 674! I don't understand well why Py_SIZE() cannot be changed until Py_SET_SIZE() is available on all supported Python versions (so affected projects don't have to add a compatibility code), whereas it's ok to require

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

rom the other thread: On 17. 02. 22 18:23, Eric Snow wrote: > On Thu, Feb 17, 2022 at 3:42 AM Petr Viktorin wrote: >>>> Weren't you planning a PEP on subinterpreter GIL as well? Do you want to >>>> submit them together? >>> >>> I'd have to think

[Python-Dev] SC reply to PEP 674 -- Disallow using macros as l-values

Hello, Thank you for submitting PEP 674 -- Disallow using macros as l-values! For Py_TYPE, we respect the previous steering council's decision: https://github.com/python/steering-council/issues/79 The Py_TYPE macro can be changed as proposed in 3.11. However, the old SC explicitly noted that

[Python-Dev] SC Acceptance: PEP 680 -- tomllib

Hello, The Steering Council discussed PEP 680 -- tomllib: Support for Parsing TOML in the Standard Library, and unanimously decided to accept it. Congratulations! I'll change the PEP status to Accepted. Please open a PR for Python 3.11 at your convenience. - Petr (on behalf of the Python

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

bjects. Out of curiosity: How does this extra work affect in the performance? Is it part of the 4% slowdown? And from the other thread: On 17. 02. 22 18:23, Eric Snow wrote: > On Thu, Feb 17, 2022 at 3:42 AM Petr Viktorin wrote: >>>> Weren't you planning a PEP on subinterpr

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On 17. 02. 22 2:13, Eric Snow wrote: Thanks for the feedback. My responses are inline below. -eric On Wed, Feb 16, 2022 at 6:36 AM Petr Viktorin wrote: Thank you very much for writing this down! It's very helpful to see a concrete proposal, and the current state of this idea. I like

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On 16. 02. 22 1:10, Eric Snow wrote: Eddie and I would appreciate your feedback on this proposal to support treating some objects as "immortal". The fundamental characteristic of the approach is that we would provide stronger guarantees about immutability for some objects. A few things to

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 14. 02. 22 17:26, Ronald Oussoren wrote: On 14 Feb 2022, at 14:07, Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 14. 02. 22 13:37, Antoine Pitrou wrote: On Mon, 14 Feb 2022 13:19:00 +0100 Petr Viktorin mailto:encu...@gmail.com>> wrote: If we don't hav

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 14. 02. 22 13:37, Antoine Pitrou wrote: On Mon, 14 Feb 2022 13:19:00 +0100 Petr Viktorin wrote: If we don't have much sympathy for projects that use private API where does that leave pythoncapi_compat? If you look at pythoncapi_compat.h, it provides backports for recently-introduced

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 11. 02. 22 19:25, Neil Schemenauer wrote: On 2022-02-11 06:14, Petr Viktorin wrote: Sounds reasonable, but... The implication of endorsing code like this is that *we cannot change private API even in patch releases*, which I don't think is documented anywhere, and might be a bit

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 11. 02. 22 13:52, Victor Stinner wrote: On Fri, Feb 11, 2022 at 12:06 PM Petr Viktorin wrote: Or will this send a message that core devs should co-maintain the project? I personally wouldn't want to maintain it, but it it looks like there are at least 3 maintainers who do. I think

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 10. 02. 22 23:58, Victor Stinner wrote: Hi, Would it make sense to move the pythoncapi_compat project under the GitHub Python or PSF organization to make it more "official" and a little bit more sustainable? "The pythoncapi_compat project can be used to write a C extension supporting a wide

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

On 09. 02. 22 20:04, Stefan Behnel wrote: Guido van Rossum schrieb am 09.02.22 um 19:36: On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado wrote: On Wed, 9 Feb 2022 at 17:38, Stefan Behnel wrote: Pablo Galindo Salgado schrieb am 09.02.22 um 17:40: Should there be a getter/setter for

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

On 09. 02. 22 21:41, Gregory P. Smith wrote: On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner [...] Two differing examples from that PR 31221: Hold off as unsafe for now: Macros that do things like (PyWhateverObject*)(op) such as PyUnicode_CHECK_INTERNED(op) should not have the casting part

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On 10. 02. 22 0:30, Inada Naoki wrote: On Thu, Feb 10, 2022 at 3:49 AM Brett Cannon wrote: On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote: On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: That's an interesting idea -- what's keeping us from C11? No one asking before, probably because

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 04. 02. 22 15:23, Stefan Behnel wrote: Petr Viktorin schrieb am 03.02.22 um 13:47: On 02. 02. 22 11:50, Stefan Behnel wrote: Maybe we should advertise the two modes more. And make sure that both work. There are certainly issues with the current state of the "limited API" impl

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

On 08. 02. 22 12:07, Erlend Aasland wrote: Petr, SC, thanks for your time and response! Just a quick comment: On 8 Feb 2022, at 11:32, Petr Viktorin wrote: In effect, the SC accepts the first part of the PEP, except cases where: What status does that put the PEP in? Still draft. It's

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? This could be formulated in a more neutral way by saying "C99 without the things that became optional in C11", or perhaps

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

On 08. 02. 22 17:27, Victor Stinner wrote: Hi Petr, Thanks for the SC review, it's very helpful! I know that it's a big PEP :-) On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote: *All other things being equal, static inline functions are better than macros.* Specifically, inline static

[Python-Dev] Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

Thank you for submitting PEP 670 (Convert macros to functions in the Python C API)! The steering council is still discussing it. We're not ready to accept the PEP as a whole, but there are parts on which we agree unanimously. To unblock the work, we're making the following pronouncements: *All

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

on.org/dev/peps/pep-0007/ I modified Python 3.11 to require more C99 features of the header: * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round() * bpo-46640: NAN After my NAN change (bpo-46640), Petr Viktorin asked me to update the PEP 7. I proposed a change to simply say th

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 07. 02. 22 15:29, Victor Stinner wrote: On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote: CPython is also affected by these issues, but the benefits of PEP 674 (alone) are too indirect, so I chose to avoid mentioning CPython issues directly, to avoid confusion. A concrete example of

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 07. 02. 22 14:26, Victor Stinner wrote: On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote: Basically, instead of "We'll remove this API now because it prevents moving to a hypothetical moving garbage collector", it should be "Here is a moving garbage collector that speeds

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 31. 01. 22 16:14, Victor Stinner wrote: On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote: If we change the stable ABI, I would prefer to fix multiple issues at once. Examples: * No longer return borrowed references (ex: PyDict_GetItem is part of the stable ABI) and no longer steal

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 02. 02. 22 11:50, Stefan Behnel wrote: Petr Viktorin schrieb am 02.02.22 um 10:22: Moving off the internal (unstable) API would be great, but I don't think Cython needs to move all the way to the limited API. There are three "levels" in the C API: - limited API, with lon

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 01. 02. 22 16:42, Christian Heimes wrote: On 01/02/2022 16.08, Victor Stinner wrote: -- I would prefer to introduce C API incompatible changes differently: first fix Cython, and *then* introduce the change. - (1) Propose a Cython PR and get it merged - (2) Wait until a new Cython version

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 31. 01. 22 15:40, Victor Stinner wrote: On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote: (* we could also break the stable ABI, and we could even do it reasonably safely over a long period of time, but that's a whole different discussion.) IMO the stable ABI must be change

[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)

On 31. 01. 22 15:30, Victor Stinner wrote: On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote: PEP: 674 Title: Disallow using macros as l-value The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros as l-values", which is misleading: it proposes to change 65 macro

[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)

On 18. 01. 22 9:30, Victor Stinner wrote: Hi, I made the following changes to the PEP since the version 1 (November 30): * Elaborate the HPy section and add a new "Relationship with the HPy project" section * Elaborate which projects are impacted and which changes are needed * Remove the PyPy

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 28. 01. 22 16:04, Victor Stinner wrote: Hi, There is a reason why I'm bothering C extensions maintainers and Python core developers with my incompatible C API changes since Python 3.8. Let me share my plan with you :-) In 2009 (Python 3.2), Martin v. Löwis did an amazing job with the PEP

[Python-Dev] SC Acceptance: PEP 673 -- Self Type

Hello Pradeep, James and Jelle, The Steering Council discussed PEP 673 -- Self Type, and unanimously decided to accept it. Congratulations! Please change the PEP status to Accepted, and merge the change to Python 3.11, at your convenience. Happy typing! - Petr (on behalf of the Python

[Python-Dev] Re: RFC on PEP 673: Self Type

On 19. 01. 22 21:40, S Pradeep Kumar wrote: On Mon, Jan 17, 2022 at 7:02 AM Jelle Zijlstra <mailto:jelle.zijls...@gmail.com>> wrote: El lun, 17 ene 2022 a las 6:25, Petr Viktorin (mailto:encu...@gmail.com>>) escribió: On Wed, Nov 17, 2021 at 8:31 AM Pradeep K

[Python-Dev] SC Acceptance: PEP 646 -- Variadic Generics

On 17. 11. 21 23:47, Barry Warsaw wrote: Hello Mark, Matthew, Pradeep, Vincent, and Guido, The Python Steering Council discussed the latest version of PEP 646 (Variadic Generics) at our last meeting, and have unanimously decided to accept the PEP. Congratulations! We want to specifically

[Python-Dev] Re: RFC on PEP 673: Self Type

On Wed, Nov 17, 2021 at 8:31 AM Pradeep Kumar Srinivasan wrote: > > This PEP [1] introduces a simple and intuitive way to annotate methods and > classmethods that return an instance of their class. Such methods and > classmethods occur quite frequently, but the existing way to annotate them >

[Python-Dev] Re: Fwd: PEP 646 (Variadic Generics): final call for comments

On 13. 01. 22 16:23, Matthew Rahtz wrote: Thanks for this feedback, Petr! *First point (indexing assignment)* Great catch; we hadn't thought about this. I agree it would be better to keep these in sync. I just tested this in our current CPython implementation, and can confirm it looks like

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

On 12. 01. 22 17:58, Guido van Rossum wrote: On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin <mailto:pvikt...@redhat.com>> wrote: Matthew Rahtz wrote: > Hi everyone, > > We've got to the stage now with PEP 646 that we're feeling pretty happy > w

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

Matthew Rahtz wrote: Hi everyone, We've got to the stage now with PEP 646 that we're feeling pretty happy with it. So far though we've mainly been workshopping it in typing-sig, so as PEP 1 requires we're asking for some feedback here too before submitting it to the steering council. If you

[Python-Dev] Re: About vulnerabilities in Cpython native code

On 06. 01. 22 14:22, lxr1210--- via Python-Dev wrote: Hi all, I am currently doing some research on the security of CPython. I used the open source vulnerability analysis engine, Infer(https://fbinfer.com/), to scan the native code of CPython 3.10.0. The scan results show that there are

[Python-Dev] Re: RFC on Callable Syntax PEP

On Thu, Dec 16, 2021 at 6:57 PM Steven Troxler wrote: > > Hello all, > > Thanks everyone for comments on our earlier thread [1] about callable type > syntax. We now have a draft PEP [2] proposing an arrow-based syntax for > callable types, for example: > > ``` > (int, str) -> bool #

[Python-Dev] Re: Static types and subinterpreters running in parallel

On 16. 12. 21 20:24, Eric Snow wrote: On Thu, Dec 16, 2021 at 10:54 AM Guido van Rossum wrote: Eric has been looking into this. It's probably the only solution if we can't get immutable objects. Yep. I've investigated the following approach (for the objects exposed in the public and

[Python-Dev] Re: subinterpreters and their possible impact on large extension projects

On 17. 12. 21 4:02, Jim J. Jewett wrote: Petr Viktorin wrote: In Python 3.11, Python still implements around 100 types as "static types" which are not compatible with subinterpreters, ... seems like changing it may break the C API *and* the stable ABI If sub-interpreters

[Python-Dev] Re: subinterpreters and their possible impact on large extension projects

On 16. 12. 21 12:33, Antoine Pitrou wrote: On Tue, 14 Dec 2021 10:38:25 -0700 Eric Snow wrote: So we (the core devs) would effectively be requiring those extensions to support subinterpreters, regardless of letting them opt out. This situation has been weighing heavily on my mind since

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On 16. 12. 21 11:52, Victor Stinner wrote: On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith wrote: On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote: I wrote https://bugs.python.org/issue39511 and https://github.com/python/cpython/pull/18301 to have per-interpreter None, True and False

  1   2   3   4   >