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

On 16. 12. 21 3:41, Jim J. Jewett wrote: In Python 3.11, Python still implements around 100 types as "static types" which are not compatible with subinterpreters, like _Type and _Type. I opened https://bugs.python.org/issue40601 about these static types, but it seems like changing it may break

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

On 16. 12. 21 2:54, Guido van Rossum wrote: (I just realized that we started discussing details of immortal objects in the wrong thread -- this is Eric's overview thread, there's a separate thread on immortal objects. But alla, I'll respond here below.) On Wed, Dec 15, 2021 at 5:05 PM Neil

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

On 15. 12. 21 23:57, Guido van Rossum wrote: On Wed, Dec 15, 2021 at 6:04 AM Antoine Pitrou > wrote: On Wed, 15 Dec 2021 14:13:03 +0100 Antoine Pitrou mailto:anto...@python.org>> wrote: > Did you try to take into account the envisioned project for adding

[Python-Dev] Re: Explicit markers for special C-API situations

On 10. 12. 21 11:55, Christian Heimes wrote: On 10/12/2021 03.08, Jim J. Jewett wrote: Christian Heimes wrote: On 09/12/2021 19.26, Petr Viktorin wrote: If the code is the authoritative source of truth, we need a proper parser to extract the information.  ... unfortunately I don't trust

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

I'll not get back to CPython until Tuesday, but I'll add a quick note for now. It's a bit blunt for lack of time; please don't be offended. If the code is the authoritative source of truth, we need a proper parser to extract the information. But we can't really use an existing parser (e.g. we

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 08. 12. 21 18:06, Eric Snow wrote: On Wed, Dec 8, 2021 at 2:23 AM Petr Viktorin wrote: That really depends on what function we'd want to remove. There are usually alternatives to deleting things, but the options depend on the function. If we run out of other options we can make the function

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 07. 12. 21 19:28, Guido van Rossum wrote: On Tue, Dec 7, 2021 at 12:58 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 06. 12. 21 21:50, Guido van Rossum wrote: [...] > Also, it looks like Mark is proposing to *remove* _PyObject_GC_Malloc > from

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 07. 12. 21 17:54, Joao S. O. Bueno wrote: Sorry for stepping in - but I am seeing too many arguments in favour of the rules because "they are the rules", and just Victor arguing with what is met in the "real world". OTOH, coming up with rules and then blatantly ignoring them is silly at

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 08. 12. 21 1:47, Victor Stinner wrote: For me, HPy is the only valid stable API and stable ABI in the long term which is efficient on any Python implementation. Its design is very different than the C API: HPy avoids all C API design mistakes, it doesn't leak any implementation detail.

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 07. 12. 21 20:58, Guido van Rossum wrote: On Tue, Dec 7, 2021 at 11:02 AM Christian Heimes > wrote: On 07/12/2021 19.28, Guido van Rossum wrote: > I assume it would be insensitive to ask whether we could just get rid of > the stable ABI

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 30. 11. 21 19:52, Victor Stinner wrote: On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote: How about *not* asking for an exception and just following the PEP 387 process? Is that really too burdensome? The Backward Compatibility section gives an explanation: "This change does not

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 06. 12. 21 21:50, Guido van Rossum wrote: On Mon, Dec 6, 2021 at 12:12 PM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 06. 12. 21 20:29, Guido van Rossum wrote: > Hi Petr, > > In PEP 384 it is written that no functions starting with an undersco

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 06. 12. 21 20:29, Guido van Rossum wrote: Hi Petr, In PEP 384 it is written that no functions starting with an underscore are part of the stable ABI: PEP 384 -- Defining a Stable ABI | Python.org > All functions starting

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

On 24. 11. 21 15:32, Victor Stinner wrote: On Wed, Nov 24, 2021 at 2:18 PM Petr Viktorin wrote: The "Backwards Compatibility" section is very small. Can you give a list of macros which lost/will lose "return values"? https://bugs.python.org/issue45476 lists many of t

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

On 24. 11. 21 15:22, Victor Stinner wrote: On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote: Since this is about converting existing macros (and not writing new ones), can you talk about which of the "macro pitfalls" apply to the macros in CPython that were/will be changed?

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

On 24. 11. 21 13:20, Victor Stinner wrote: On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote: Are there more macros that are yet to be converted to macros, I suppose that you mean "to be converted to functions". Yes, there are many, it's the purpose of the PEP. I didn't prov

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

On 23. 11. 21 18:00, Victor Stinner wrote: I completed the PEP: https://python.github.io/peps/pep-0670/ What I don't like about this PEP is that it documents changes that were already pushed, not planned ones. But, what's done is done... Are there more macros that are yet to be converted to

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 19. 11. 21 22:15, Mike Miller wrote: This is the point where the pricey support contract comes in.  Would give options to those who need it and provide some revenue. Not really; for a pricey support contract would need to freeze things for even longer -- *and* make it an actual contract

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Wed, Nov 17, 2021 at 12:49 AM Terry Reedy wrote: > > On 11/16/2021 7:43 AM, Petr Viktorin wrote: > > On 16. 11. 21 1:11, Brett Cannon wrote: > > >> I think the key point with that approach is if you wanted to maximize > >> your support across supported version

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 16. 11. 21 20:13, Brett Cannon wrote: On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 16. 11. 21 1:11, Brett Cannon wrote: > > > On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner mailto:vstin...@python.org>

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 16. 11. 21 1:11, Brett Cannon wrote: On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner > wrote: On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith mailto:e...@trueblade.com>> wrote: > On second thought, I guess the existing policy already does this. Maybe

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On 12. 11. 21 13:09, Victor Stinner wrote: It was decided to start deprecating the asyncore, asynchat and smtpd modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits DeprecationWarning. Wait, only Python 3.10? According to the policy, the warning should be there for *at least*

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 15. 11. 21 9:25, Stephen J. Turnbull wrote: Christopher Barker writes: > Would a proposal to switch the normalization to NFC only have any hope of > being accepted? Hope, yes. Counting you, it's been proposed twice. :-) I don't know whether it would get through. We know this won't

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 12. 11. 21 14:18, Victor Stinner wrote: For me, deprecated functions cause me a lot of thinking when I met them as a Python maintainer and as a Python user. Why is it still there? What is its purpose? Is there a better alternative? It's related to the Chesterton's fence principle. Sometimes,

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 12. 11. 21 13:51, Victor Stinner wrote: The current backwards compatibility policy (PEP 387) sets a *minimum* timeline for deprecations and removals -- "deprecation period must last at least two years." About the PEP 387 process and the 3 examples. On Fri, Nov 12, 2021 at 11:

[Python-Dev] Do we need to remove everything that's deprecated?

We're rebuilding many popular projects with Python 3.11 alpha, and I see many failures like: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'? (bpo-45173) ImportError: cannot import name 'formatargspec' from 'inspect' (bpo-45320)

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On 11. 11. 21 13:31, Victor Stinner wrote: Hi, The asyncore module is a very old module of the Python stdlib for asynchronous programming, usually to handle network sockets concurrently. It's a common event loop, but its design has many flaws. The asyncio module was added to Python 3.4 with a

[Python-Dev] Re: Proposal: Allow non-default after default arguments

On 09. 11. 21 10:50, Chris Angelico wrote: On Tue, Nov 9, 2021 at 8:38 PM Sebastian Rittau wrote: Currently, Python doesn't allow non-default arguments after default arguments: >>> def foo(x=None, y): pass File "", line 1 def foo(x=None, y): pass ^

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

On 03. 11. 21 12:33, Serhiy Storchaka wrote: 03.11.21 12:36, Petr Viktorin пише: On 03. 11. 21 2:58, Kyle Stanley wrote: I'd suggest both: briefer, easier to read write up for average user in docs, more details/semantics in informational PEP. Thanks for working on this, Petr! Well

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

On 03. 11. 21 12:37, Chris Angelico wrote: On Wed, Nov 3, 2021 at 10:22 PM Steven D'Aprano wrote: On Wed, Nov 03, 2021 at 11:21:53AM +1100, Chris Angelico wrote: TBH, I'm not entirely sure how valid it is to talk about *security* considerations when we're dealing with Python source code and

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

We seem to agree that this is work for linters. That's reasonable; I'd generalize it to "tools and policies". But even so, discussing what we'd expect linters to do is on topic here. Perhaps we can even find ways for the language to support linters -- type checking is also for external tools,

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

I think I agree with Marc-André that putting it in the actual Python documentation would give it more visibility than in a PEP. On Tue, Nov 2, 2021, 1:06 PM Marc-Andre Lemburg mailto:m...@egenix.com>> wrote: On 01.11.2021 13:17, Petr Viktorin wrote: >> PEP: 9

[Python-Dev] Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 01. 11. 21 18:32, Serhiy Storchaka wrote: This is excellent! 01.11.21 14:17, Petr Viktorin пише: CPython treats the control character NUL (``\0``) as end of input, but many editors simply skip it, possibly showing code that Python will not run as a regular part of a file

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

On 01. 11. 21 13:17, Petr Viktorin wrote: Hello, Today, an attack called "Trojan source" was revealed, where a malicious contributor can use Unicode features (left-to-right text and homoglyphs) to code that, when shown in an editor, will look different from how a computer langu

[Python-Dev] pre-PEP: Unicode Security Considerations for Python

Python, and I'd like to publish a summary as an informational PEP, pasted below. PEP: Title: Unicode Security Considerations for Python Author: Petr Viktorin Status: Active Type: Informational Content-Type: text/x-rst Created: 01-Nov-2021 Post-History: Abstract This document ex

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

On 20. 10. 21 3:15, Victor Stinner wrote: Extra info that I didn't put in the PEP to keep the PEP short. Since Python 3.8, multiple macros have already been converted, including Py_INCREF() and Py_TYPE() which are very commonly used and so matter for Python performance. Macros converted to

[Python-Dev] Documenting Python versioning and stability expectations

Hello, I heard not everyone is Discourse, so I'm re-posting here as well. Information about is current scattered over the FAQs, active PEPs (387, 602), an active-but-severely-outdated PEP (6) and the Devguide. I would like to consolidate as much of this as possible into user-facing

[Python-Dev] Re: PEP 654 except* formatting

On 06. 10. 21 15:34, Łukasz Langa wrote: On 6 Oct 2021, at 12:06, Larry Hastings > wrote: It seems like, for this to work, "group" would have to become a keyword. No, just like `match` and `case` didn't have to. This would play havoc with a lot of existing

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 05. 10. 21 8:59, Nick Coghlan wrote: On Tue, 28 Sep 2021, 6:55 am Brett Cannon, > wrote: On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev mailto:python-dev@python.org>> wrote: However the stable ABI is still a second class citizen as

[Python-Dev] Re: Making code object APIs unstable

On 01. 09. 21 22:28, Guido van Rossum wrote: I apologize, I keep making the same mistake. The PyCode_New[WithPosArgs] functions are *not* in the stable ABI or in the limited API, so there's no need to petition the SC, nor do I need Petr's approval. We may be bound by backwards

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

On 26. 08. 21 9:54, Marc-Andre Lemburg wrote: On 26.08.2021 06:07, Christopher Barker wrote: I'm working on a PR now. It seems there is little support for keeping the python2 content in the docs, so I'm re-writing it as though it was never there. If someone wants to add a note about Python 2,

[Python-Dev] Stable ABI – PEP 667: Consistent views of namespaces

On 23. 08. 21 5:07, Guido van Rossum wrote: On Sat, Aug 21, 2021 at 8:52 PM Nick Coghlan > wrote: [...] Code that uses PyEval_GetLocals() will NOT continue to operate safely under PEP 667: all such code will raise an exception at runtime, and need to be

[Python-Dev] Re: Deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10?

On 17. 08. 21 12:00, Łukasz Langa wrote: Hi everybody, I'd like to revive this thread as I feel like we have to do something here but some consensus is needed first. To recap, the current state of things is as follows: - *in March 2000* (d724b23420f) Christian Tismer contributed the

[Python-Dev] Re: Making code object APIs unstable

I'm late to the thread, and as I read it I see everything I wanted to say was covered already :) So just a few clarifications. The stable ABI is not defined by PEP 384 or PEP 652 or by the header something is defined in, but by the docs: - https://docs.python.org/dev/c-api/stable.html and

[Python-Dev] Heads up: `make` in Doc now creates a venv

Hi, A recent change "make html" in the Doc directory create a venv if one wasn't there before. If you don't want to download sphinx and other dependencies from PyPI, you'll need to adjust your workflow. If you already have all the dependencies, the following command (in the CPython

[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

On 24. 07. 21 1:58, Nick Coghlan wrote: On Sat, 24 Jul 2021, 9:37 am Larry Hastings, <mailto:la...@hastings.org>> wrote: On 7/23/21 7:38 AM, Petr Viktorin wrote: (In both C & C++, the size of an `enum` is implementation-defined. That's unlikely to be a proble

[Python-Dev] enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

On 22. 07. 21 12:41, Nick Coghlan wrote: On Thu, 22 Jul 2021, 6:01 pm Petr Viktorin, <mailto:encu...@gmail.com>> wrote: On 21. 07. 21 14:18, Nick Coghlan wrote: > On Mon, 19 Jul 2021 at 21:32, Petr Viktorin mailto:encu...@gmail.com>> wrote: >&

[Python-Dev] Re: PEP 558: Defined semantics for locals()

On 22. 07. 21 15:03, Ethan Furman wrote: On 7/22/21 1:01 AM, Petr Viktorin wrote: > On 21. 07. 21 14:18, Nick Coghlan wrote: >> >> typedef enum { >>  PyLocals_UNDEFINED = -1; >>  PyLocals_DIRECT_REFERENCE = 0, >&g

[Python-Dev] Re: PEP 558: Defined semantics for locals()

On 21. 07. 21 14:18, Nick Coghlan wrote: On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote: The proposal assumes that in the future, ``PyLocals_Get``, and thus ``locals()``, will never gain another kind of return value, however unlikely that is. AFAICS, code that uses this will usually

[Python-Dev] Re: PEP 558: Defined semantics for locals()

Thanks, Nick! This looks wonderful. I do have a nitpick, below: On 18. 07. 21 7:59, Nick Coghlan wrote: [...]> Changes to the stable C API/ABI --- Unlike Python code, extension module functions that call in to the Python C API can be called from any kind of Python

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On June 22, 2021 11:18:46 AM GMT+02:00, Henk-Jaap Wagenaar wrote: >On Tue, 22 Jun 2021 at 10:06, Petr Viktorin wrote: > >> On 21. 06. 21 20:20, Guido van Rossum wrote: >> > Okay, I think your evidence can then be discounted. Really, any app >that >> > relies

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On 21. 06. 21 20:20, Guido van Rossum wrote: Okay, I think your evidence can then be discounted. Really, any app that relies on the publicly installed Python runs a serious risk of breaking when that Python gets updated, regardless of whether the ABI changes or not. Unfortunately, this

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On 09. 06. 21 13:09, Paul Moore wrote: On Wed, 9 Jun 2021 at 11:36, Inada Naoki wrote: If I am wrong, can we stop keeping stable ABI at Python 3.12? Python 4.0 won't come in foreseeable future. Stable ABI blocks Python evolution. Conversely, the stable ABI allows projects to build

[Python-Dev] Re: New pythoncapi_compat project adding Python 3.10 support to your C extensions without losing Python 2.7-3.9 support

On 03. 06. 21 1:43, Victor Stinner wrote: Hi, What do you think of promoting the pythoncapi_compat project that I'm introducing below in the "C API: Porting to Python 3.10" section of What's New In Python 3.10? Should this project be moved under the GitHub psf organization to have a more

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On 08. 06. 21 10:05, Serhiy Storchaka wrote: 07.06.21 08:41, Hai Shi пише: There have an another question. There have many C API defined under PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT(). Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory? We should support

[Python-Dev] Re: Proposal: declare "unstable APIs"

On 04. 06. 21 10:25, Serhiy Storchaka wrote: 03.06.21 20:10, Guido van Rossum пише: This is not a complete thought yet, but it occurred to me that while we have deprecated APIs (which will eventually go away), and provisional APIs (which must mature a little before they're declared stable),

[Python-Dev] Re: name for new Enum decorator

On 28. 05. 21 5:24, Ethan Furman wrote: Greetings! The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements into a decorator instead, and I'm having a hard time thinking up a name. What is the behavior?  Well, a name in a flag

[Python-Dev] Re: The repr of a sentinel

On 21. 05. 21 3:23, Eric V. Smith wrote: On 5/20/2021 3:24 PM, Ronald Oussoren via Python-Dev wrote: On 20 May 2021, at 19:10, Luciano Ramalho > wrote: I'd like to learn about use cases where `...` (a.k.a. `Ellipsis`) is not a good sentinel. It's a pickable

[Python-Dev] Re: The repr of a sentinel

On 14. 05. 21 10:55, Victor Stinner wrote: Hi Tal, Would it make sense to have an unique singleton for such sentinel, a built-in singleton like None or Ellipsis? I propose the name "Sentinel". Sentinel would be similar to None, but the main property would be that "Sentinel is None" is false

[Python-Dev] Re: The repr of a sentinel

On 13. 05. 21 11:45, Antoine Pitrou wrote: Le 13/05/2021 à 11:40, Irit Katriel a écrit : On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou > wrote:  I agree that is a reasonable spelling. I initially suggested , but now I'm not sure because it doesn't

[Python-Dev] Re: Using FutureWarning for last version before deletion.

On 11. 05. 21 11:08, Inada Naoki wrote: On Tue, May 11, 2021 at 5:30 PM Petr Viktorin wrote: Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden". *should* is not *do*. For example, noset

[Python-Dev] Re: Using FutureWarning for last version before deletion.

On 10. 05. 21 10:53, Inada Naoki wrote: Hi, folks. Now Python 3.11 development is open and I am removing some deprecated stuffs carefully. I am considering `configparser.ParseError.filename` property that is deprecated since Python 3.2.

[Python-Dev] PEP 652: Python 3.10 will have explicit Limited C API & Stable ABI

Hello, I've merged the main part of PEP-652 implementation. The Limited C API (introduced in PEP 384 and used for extension modules that work across Python versions without recompilation) is now explicitly defined and better tested. When changing/extending the limited API: - Stop and think!

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for

[Python-Dev] Re: PEP 652 Accepted -- Maintaining the Stable ABI

On 05. 04. 21 21:46, Pablo Galindo Salgado wrote: Hi Petr, Thank you for submitting PEP 652 (Maintaining the Stable ABI). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP and hereby accepts it. The Steering council thinks that this is a great

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 2/23/21 1:24 AM, Irit Katriel via Python-Dev wrote: Hi all, We would like to request feedback on PEP 654 -- Exception Groups and except*. https://www.python.org/dev/peps/pep-0654/ Thank you for this PEP! Also, thank you Nathaniel (and

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

On 2/16/21 11:50 AM, Андрей Казанцев wrote: It seems technically possible to override attributes/methods of built-in types, but the question is more if it's desirable? The problem is that you cannot override the method not only in built-in types but also, for example, in `lxml.etree`

[Python-Dev] Re: Signature discrepancies between documentation and implementation

On 2/9/21 9:15 PM, Serhiy Storchaka wrote: 09.02.21 12:22, Erlend Aasland пише: What's the recommended approach with issues like https://bugs.python.org/issue43094? Change the docs or the implementation? I did a quick search on bpo, but could not find similar past issues. If the

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

On 2/2/21 12:36 PM, Stefano Borini wrote: Hi all, I would like to request feedback by python-dev on the current implementation of PEP 637 - Support for indexing with keyword arguments. https://www.python.org/dev/peps/pep-0637/ The PEP is ready for SC submission and it has a prototype

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On 1/13/21 8:24 PM, Brett Cannon wrote: On Wed, Jan 13, 2021 at 7:25 AM Serhiy Storchaka > wrote: 12.01.21 22:38, Julien Palard via Python-Dev пише: > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > Problem is Sphinx 3 have

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/12/21 8:23 PM, Neil Schemenauer wrote: On 2021-01-12, Pablo Galindo Salgado wrote: One worry that I have in general with this move is the usage of _PyType_GetModuleByDef to get the type object from the module definition. This normally involves getting a TLS in every instance creation,

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/12/21 7:48 PM, Pablo Galindo Salgado wrote: One worry that I have in general with this move is the usage of _PyType_GetModuleByDef to get the type object from the module definition. This normally involves getting a TLS in every instance creation, Not TLS, it's walking the MRO. which

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/12/21 7:16 PM, Neil Schemenauer wrote: On 2021-01-12, Victor Stinner wrote: It seems like a safer approach is to continue the work on bpo-40077: "Convert static types to PyType_FromSpec()". I agree that trying to convert static types is a good idea. Another possible bonus might be that

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/12/21 4:34 PM, Antoine Pitrou wrote: On Tue, 12 Jan 2021 15:22:36 +0100 Petr Viktorin wrote: On 1/11/21 5:26 PM, Victor Stinner wrote: Hi, There are multiple PEPs covering heap types. The latest one refers to other PEPs: PEP 630 "Isolating Extension Modules" by Petr Vikto

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/12/21 4:09 PM, Victor Stinner wrote: On Tue, Jan 12, 2021 at 3:28 PM Petr Viktorin wrote: If a type is immutable and has no references to heap-allocated objects, it could stay as a static type. The issue is that very many types don't fit that. For example, if some method needs to raise

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On 1/11/21 5:26 PM, Victor Stinner wrote: Hi, There are multiple PEPs covering heap types. The latest one refers to other PEPs: PEP 630 "Isolating Extension Modules" by Petr Viktorin. https://www.python.org/dev/peps/pep-0630/#motivation The use case is to embed multiple Python

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

On 11/24/20 7:50 PM, Brett Cannon wrote: If enough people were interested we could create a "Distributors" category on discuss.python.org . I'd join :) On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi > wrote: > I'd love to have an

[Python-Dev] Re: Speeding up CPython

On 10/21/20 1:40 PM, Mark Shannon wrote: Hi Petr, On 21/10/2020 11:49 am, Petr Viktorin wrote: Let me explain an impression I'm getting. It is *just one aspect* of my opinion, one that doesn't make sense to me. Please tell me where it is wrong. In the C API, there's a somewhat

[Python-Dev] Re: Speeding up CPython

Let me explain an impression I'm getting. It is *just one aspect* of my opinion, one that doesn't make sense to me. Please tell me where it is wrong. In the C API, there's a somewhat controversial refactoring going on, which involves passing around tstate arguments. I'm not saying [the

[Python-Dev] Taking over xxlimited for PEP 630

Hello, The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP 384 (Defining a Stable ABI), and is undocumented. As far as I can tell, it was added partly to test the stable ABI, and partly as an example of how to write a module (like "xx" from xxmodule.c). In the last few years

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

On 2020-07-02 14:57, Victor Stinner wrote: Le jeu. 2 juil. 2020 à 14:44, Barry Scott a écrit : It's not obvious to me why the latin1 encoding is in this list as its just one of all the 8-bit char sets. Why is it needed? The Latin-1 (ISO 8859-1) charset is kind of special: it maps bytes

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On 2020-06-30 02:46, Victor Stinner wrote: You missed the point of the PEP: "It becomes possible to experiment with more advanced optimizations in CPython than just micro-optimizations, like tagged pointers." I don't think experiments are a good motivation. When the C API is broken, everyone

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 2020-06-26 16:54, Stéfane Fermigier wrote: [...] Here's one example: https://github.com/clojure/core.match (in particular: https://github.com/clojure/core.match/wiki/Understanding-the-algorithm ). Alson some insights from

[Python-Dev] Re: New optional dependency - TkDND

On 2020-06-23 12:14, Elisha Paine wrote: Hi all, I am looking at getting TkDND support into tkinter, and have created issue40893. However, we are currently considering the practicalities of adding a new optional dependency to Python and I was hoping someone could help answer the question of: is

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On 2020-06-22 14:10, Victor Stinner wrote: Hi, PEP available at: https://www.python.org/dev/peps/pep-0620/ This PEP is the result of 4 years of research work on the C API: https://pythoncapi.readthedocs.io/ It's the third version. The first version (2017) proposed to add a "new C API" and

[Python-Dev] Re: Cython and incompatible C API changes

On 2020-06-17 12:03, Victor Stinner wrote: re: [Python-Dev] When can we remove wchar_t* cache from string? Le mar. 16 juin 2020 à 21:19, Steve Dower a écrit : On 16Jun2020 1641, Inada Naoki wrote: * This change doesn't affect to pure Python packages. * Most of the rest uses Cython. Since

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 2020-06-16 20:28, Mark Shannon wrote: On 16/06/2020 1:24 pm, Nick Coghlan wrote: Multiprocessing serialisation overheads are abysmal. With enough OS support you can attempt to mitigate that via shared memory mechanisms (which Davin added to the standard library), but it's impossible to

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 2020-06-16 19:20, Guido van Rossum wrote: Has anybody brought up the problem yet that if one subinterpreter encounters a hard crash (say, it segfaults due to a bug in a C extension module), all subinterpreters active at that moment in the same process are likely to lose all their

[Python-Dev] Re: Improving inspect capabilities for classes

On 2020-06-17 09:02, Serhiy Storchaka wrote: 16.06.20 21:02, Guido van Rossum пише: It would certainly be much easier to get through the review process. Adding a `__filename__` (why not `__file__`?) attribute to classes is a major surgery, presumably requiring a PEP, and debating the pros and

[Python-Dev] Re: Removal of _Py_ForgetReference from public header in 3.9 issue

On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: Please excuse if this is the wrong mailing list. I couldn't find one for module maintainers. This is relevant to capi-...@python.org; let's continue here. I maintain an open source Python module in C. I'm trying to verify for the first time

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 2020-06-10 04:43, Inada Naoki wrote: On Tue, Jun 9, 2020 at 10:28 PM Petr Viktorin wrote: Relatively recently, there is an effort to expose interpreter creation & finalization from Python code, and also to allow communication between them (starting with something rudimentary, sha

[Python-Dev] My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 2020-06-05 16:32, Mark Shannon wrote: Hi, There have been a lot of changes both to the C API and to internal implementations to allow multiple interpreters in a single O/S process. These changes cause backwards compatibility changes, have a negative performance impact, and cause a lot of

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

On 2020-04-29 16:34, ro...@reportlab.com wrote: While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using the standard configure make dance. Is this a real change? Hi, This is a known issue, currently discussed in

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 2020-04-28 00:26, Steve Dower wrote: On 27Apr2020 2311, Tom Forbes wrote: Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object. It’s not that it’s impossible, but I didn’t think the current implementation doesn’t

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On 2020-04-22 08:05, Glenn Linderman wrote: On 4/21/2020 10:26 PM, Greg Ewing wrote: And if I understand correctly, you won't get any nice "This module does not support subinterpreters" exception if you import an incompatible module -- just an obscure crash, probably of the core-dumping

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On 2020-04-21 11:01, Antoine Pitrou wrote: On Mon, 20 Apr 2020 19:21:21 -0600 Eric Snow wrote: Honest question: how many C extensions have process-global state that will cause problems under subinterpreters? In other words, how many already break in mod_wsgi? A slightly tricky question is

[Python-Dev] Re: Moving threadstate to thread-local storage.

On 2020-03-24 16:31, Mark Shannon wrote: Hi, As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS. https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls It works, passing all the tests, and seems

[Python-Dev] Re: Accepting PEP 573 (Module State Access from C Extension Methods)

On 2020-03-23 17:43, Stefan Behnel wrote: As (first-time) BDFL delegate, I accept PEP 573 for Python 3.9, "Module State Access from C Extension Methods" https://www.python.org/dev/peps/pep-0573/ Petr, Nick, Eric and Marcel, thank you for your work and intensive discussions on this PEP, and

[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)

On 2020-03-10 19:21, Stefan Behnel wrote: Hi Petr! Petr Viktorin schrieb am 14.01.20 um 14:37: It also includes a more drastic change: it removes the MRO walker from the proposal. Reflecting on the feedback, it became clear to me that a MRO walker, as it was described, won't give correct

[Python-Dev] Re: Unpacking native bools in the struct module: Is Python relying on undefined behavior?

On 2020-02-27 17:14, Serge Guelton wrote: On Thu, Feb 27, 2020 at 10:51:39AM -0500, Charalampos Stratakis wrote: Hello folks, I recently observed a failure on the s390x fedora rawhide buildbot, on the clang builds, when clang got updated to version 10: https://bugs.python.org/issue39689

<    1   2   3   4   >