[Python-Dev] Accepting PEP 590 (Vectorcall)

As BDFL-Delegate, I am accepting PEP 590 -- Vectorcall: a fast calling protocol for CPython. https://www.python.org/dev/peps/pep-0590/ There was a major last-minute change to the text (though one that was discussed since PyCon US): The API is not finalized yet, and it's provided using private

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 2:25 PM, Jeroen Demeyer wrote: Hello, I have one implementation question about vectorcall which is not specified in PEP 590: what should happen if a type implements vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e. tp_call == NULL)? I see the follow

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 3:36 PM, Jeroen Demeyer wrote: On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall is no longer provisional

[Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures

Hello, PEP 570 (Positional-Only Parameters) changed the signatures of PyCode_New() and types.CodeType(), adding a new argument for "posargcount". Our policy for such changes seems to be fragmented tribal knowledge. I'm writing to check if my understanding is reasonable, so I can apply it and do

[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures

On 6/12/19 7:40 AM, Stefan Behnel wrote: Victor Stinner schrieb am 12.06.19 um 00:09: So yeah, the PyCode_New() change is very annoying in practical, since every single project using Cython requires a new release in practice. I think Cython's deal with regard to this is: """ If you use Cyt

[Python-Dev] Re: EuroPython 2019 sprints

Hello, I'll be at the EuroPython CPython sprints too, happy to help out. On Thu, Jun 13, 2019 at 6:36 PM Steve Dower wrote: > Just letting everyone know that I signed up any core devs who are going > to be at EuroPython to run sprints :) (including myself, since I'll be > there) FWIW, I read th

[Python-Dev] Re: Comparing dict.values()

On 7/25/19 2:25 AM, David Mertz wrote: Exactly! that was my thought that the exception message could hint at likely approaches. The NumPy example seems to have a good pattern: arr1 == arr2 |ValueError:Thetruth value of an array withmore than one element |isambiguous. |Usea.any()ora.all().|

[Python-Dev] Re: typing: how to use names in result-tuples?

On 7/29/19 4:36 PM, Christian Tismer wrote: Hi friends, I am meanwhile the PySide maintainer at The Qt Company, and we are trying to make the mapping from Qt functions to Python functions as comparable as possible. One problem are primitive pointer variables: In Qt, it is natural to use "somety

[Python-Dev] Re: What to do about invalid escape sequences

On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran:     s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw string"; let s = r#"Here's a raw string with

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 2019-09-30 00:33, Nick Coghlan wrote: [...] We'll never change the size of the config structs (or any other public struct) in a maintenance branch But we *will* change it in alphas/betas, and then we will ask people to try their software out with these. Of course, there are no actual API/AB

[Python-Dev] Re: Getting function arguments of PyCFunctionObject

On 2019-10-19 00:31, Sümer Cip wrote: Hi everyone, I have been working on some feature of a deterministic profiler(github.com/sumerc/yappi ). The feature is about getting arguments for a given set of function names. For example: you can define something like fo

[Python-Dev] Re: Steering Council Update (July through October)

[PEP 484](https://www.python.org/dev/peps/pep-0484/) policy for inclusion of stubs in typeshed was discussed and the [PR](https://github.com/python/peps/pull/1218/) around it. It was decided that a sentence would be changed to make type stubs an opt-out situation and not opt-in.  - [PEP 608](ht

[Python-Dev] Belatedly accepting PEP 579 (design discussion leading to vectorcall)

I approve [PEP 579], with the understanding that acceptance of an Informational PEP doesn't really mean that much. PEP 579 charts the design issues addressed in PEP 575, PEP 580, PEP 590 (and hopefully more upcoming proposals). As noted in PEP 1: Informational PEPs do not necessarily repres

[Python-Dev] Re: Pass the Python thread state to internal C functions

On 2019-11-12 23:03, Victor Stinner wrote: Hi, Are you ok to modify internal C functions to pass explicitly tstate? In short, yes, but: - don't make things slower :) - don't break the public API or the stable ABI I'm a fan of explicitly passing state everywhere, rather than keeping it in "g

[Python-Dev] Re: Why limit coroutines?

On 2019-12-11 22:45, Antoine Pitrou wrote: On Mon, 9 Dec 2019 21:42:36 -0500 Kyle Stanley wrote: (b) Why limit coroutines? It's just another Python object and has no operating resources associated with it. Perhaps your definition of coroutine is different, and you are thinking of OS threads?

[Python-Dev] Re: Python 3.8 error?

I'm quite interested in the rest of the story here. PySide is probably the biggest open-source user of the limited API, so IMO it is relevant to this list. On 2019-12-11 23:48, Christian Tismer wrote: Hi all, Sorry for the noise, I was wrong, and I retract. I was somehow mislead and hunted a

[Python-Dev] Re: Should set objects maintain insertion order too?

On 2019-12-16 06:00, Larry Hastings wrote: [...] These are all performance concerns.  As I mentioned previously in this thread, in my opinion we should figure out what semantics we want for the object, then implement those, and only after that should we worry about performance.  I think we sh

[Python-Dev] Re: Adding a scarier warning to object.__del__?

Could there be a clearer separation between the language semantics and current CPython behavior? On 2020-01-02 03:53, Yonatan Zunger wrote: Oh, I'm absolutely thinking about clarity. Something like: This method is called when the instance is about to be destroyed. Because it may be call

[Python-Dev] Re: Python Documentation and AIX specifics - how to proceed?

On 2019-12-26 14:35, Michael wrote: First - best wishes all for a happy and healthy 2020! As my nickname implies - my primary means to contribute to Python is with regard to AIX. One of the things I recently came across is Misc/README.AIX which was last updated sometime between 2010 and 2014. I

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

On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations and

[Python-Dev] Re: Why doesn't venv also install python3*-config?

On 2020-01-08 17:53, Victor Stinner wrote: Hi, I dislike python-config for multiple reasons You may get the wrong information if you pick the wrong python-config script :-( IMHO we should add a new module (problem: how should it be called? pyconfig?) which could be used using "python3 -m xx

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

On 2020-01-03 14:36, Petr Viktorin wrote: On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original

[Python-Dev] Re: extern "C" { ... } in Include/cpython/*.h

On 2020-01-27 21:42, Skip Montanaro wrote: (Apologies. Not sure where to ask this, and I'm not much of a C++ programmer. Maybe I should have just added a comment to the still-open issue.) I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's n

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

On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations and

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-01-30 07:12, Dima Tisnek wrote: On Fri, 24 Jan 2020 at 00:27, Victor Stinner wrote: Miro and me consider that Python 3.9 is pushing too much pressure on projects maintainers to either abandon Python 2.7 right now... Let's not conflate py2 EOL with what-should-go-into-py39. https://

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-01-31 19:47, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: > Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-02-03 12:55, Thomas Wouters wrote: On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 2020-01-31 19:47, Mike Miller wrote: > > On 2020-01-23 07:20, Victor Stinner wrote: >  > Python 3.9 introduces many small

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-02-03 16:44, Antoine Pitrou wrote: On Mon, 3 Feb 2020 13:18:46 +0100 Petr Viktorin wrote: I agree with the sentiment that gradual deprecations are more easily managed, this statement about Python 3.0 is not true. The unicode transition was never thought to be small, and that's

[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

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

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

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

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

[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 variety.

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

[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 https://bugs.python.org/issue40

[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: 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] 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: 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: 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 outstanding

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

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

[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: 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 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 https://softwareengineering.stackexchange.com/questions/237023/pa

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

[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 0x00-

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

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

[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&#x

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

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

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

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

[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, wh

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

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

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

[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` cl

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

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

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

[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! T

[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. https://github.com/python/cpython/blob/8e8307d70bb9dc18cfe

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

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

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

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

[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), an

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

[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 "futur

[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 cross-versi

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

[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: 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 sc

[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()

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] 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: >> The prop

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

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

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

[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 "trashc

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

[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, of

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

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

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

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

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

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

ar gotchas in 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 ==

[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 language p

[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. It is an

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

ork! 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: >&

[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, bu

[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: 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, th

<    1   2   3   4   >