[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

2021-06-04 Thread Steve Dower
On 6/3/2021 7:42 PM, Senthil Kumaran wrote: On Thu, Jun 03, 2021 at 07:08:06PM +0100, Robin Becker wrote: The regression may well be a platform issue. I am by no means an expert at building python; I followed a recipe from the ARCH PKGBUILD of some time I meant the change in the diff we were

[Python-Dev] Summary of Python tracker Issues

2021-06-04 Thread Python tracker
ACTIVITY SUMMARY (2021-05-28 - 2021-06-04) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7426 ( +2) closed 48623 (+49) total 56049 (+51) Open issues

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

2021-06-04 Thread Victor Stinner
On Fri, Jun 4, 2021 at 12:29 AM Guido van Rossum wrote: >> In the C API, there is the internal C API which fits with your >> description. To access it, you have to declare the >> Py_BUILD_CORE_MODULE macro. It's not usable directly on purpose. It's >> an user agreement: I know what I am doing,

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

2021-06-04 Thread Sebastian Rittau
Am 03.06.21 um 20:11 schrieb Gregory P. Smith: The ideal way to declare an API as unstable is to constantly change it in a breaking manner.  With every release and potentially even within some patch releases when the point really needs to be made.  Even when you didn't have a reason to change

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

2021-06-04 Thread Petr Viktorin
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: Proposal: declare "unstable APIs"

2021-06-04 Thread Serhiy Storchaka
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), and > stable APIs (which everyone can rely