[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

> On 26 Apr 2022, at 20:52, Larry Hastings wrote: > > > > On 4/25/22 23:56, Ronald Oussoren wrote: >> A problem with this trick is that you don’t know how large a class object >> can get because a subclass of type might add new slots. This is currently >> not possible to do in Python code

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

> On 26 Apr 2022, at 07:32, Larry Hastings wrote: > > […] > What could go wrong? My biggest question so far: is there such a thing as a > metaclass written in C, besides type itself? Are there metaclasses with a > __new__ that doesn't call super().__new__ or three-argument type? If there

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

> On 26 Apr 2022, at 07:32, Larry Hastings wrote: > > [… snip …] > Next we have the "continue" class statement. I'm going to spell it like this: > > continue class C(BaseClass, ..., metaclass=MyMetaclass): > # class body goes here > ... > > I'll mention other possible spellings

[Python-Dev] Re: Need help on security vulnerability zlib 1.2.11

> On 19 Apr 2022, at 23:07, Prasad, PCRaghavendra > wrote: > > Hi All, > > We are facing some issue with the zlib package 1.2.11. Recently there was a > vulnerability in zlib and we had to upgrade to 1.2.12 on all supported > platforms > We did that in all platforms including windows,

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

> On 29 Mar 2022, at 19:51, Brett Cannon wrote: > > > > On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren > wrote: > > >> On 29 Mar 2022, at 00:34, Brett Cannon > > wrote: >> >> >> >> Once >>

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

> On 29 Mar 2022, at 00:34, Brett Cannon wrote: > > > > On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker > wrote: > On Mon, Mar 28, 2022 at 11:29 AM Paul Moore > wrote: > To be honest, I feel like I'm just reiterating stuff I've

[Python-Dev] Re: Restrict the type of __slots__

nd store that value in the __slots__ attribute of the class That way the value of the attribute reflects the slots that were created while not breaking code that uses __slots__ and doesn’t change the value after class creation. Ronald > > > > On Fri, Mar 18, 2022 at 6:57 AM Ronald Ouss

[Python-Dev] Re: Restrict the type of __slots__

> On 18 Mar 2022, at 10:29, Serhiy Storchaka wrote: > > Currently __slots__ can be either string or an iterable of strings. > > 1. If it is a string, it is a name of a single slot. Third-party code which > iterates __slots__ will be confused. > > 2. If it is an iterable, it should emit

[Python-Dev] Re: Defining tiered platform support

> On 4 Mar 2022, at 00: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

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

> On 14 Feb 2022, at 14:07, Petr Viktorin wrote: > > > > 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

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

> On 2 Feb 2022, at 23:41, Eric Snow wrote: > > I […] > > Cons: > > * a little less convenient: adding a global string requires modifying > a separate file from the one where you actually want to use the string > * strings can get "orphaned" (I'm planning on checking in CI) > * some strings

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

> On 2 Feb 2022, at 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

[Python-Dev] Re: Should isinstance call __getattribute__?

> On 10 Dec 2021, at 14:40, Steven D'Aprano wrote: > > On Thu, Dec 09, 2021 at 05:19:00PM +0100, Ronald Oussoren wrote: > >> https://mail.python.org/pipermail/python-dev/2015-October/141953.html >> is an old thread about the difference between type(x)/Py_TYPE(x) and >> x.__class__ that

[Python-Dev] Re: Should isinstance call __getattribute__?

> On 9 Dec 2021, at 16:41, Steven D'Aprano wrote: > > I'm looking for some guidance on a bug report involving isinstance and > __getattribute__` please. > > The issue is that if your class overloads `__getattribute__`, calling > isinstance on an instance will call the overloaded

[Python-Dev] Re: Should python-config be an stdlib module?

> On 23 Oct 2021, at 17:48, Filipe Laíns wrote: > > On Sat, 2021-10-23 at 12:25 -0300, Joannah Nanjekye wrote: >> I remembered this issue on bpo with contracting opinions from when I first >> looked in 2019. >> >> See https://bugs.python.org/issue33439 > > Hi, > > This script is currently

[Python-Dev] Re: Python multithreading without the GIL

> On 11 Oct 2021, at 18:58, Thomas Grainger wrote: > > Is D1.update(D2) still atomic with this implementation? > https://docs.python.org/3.11/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe > >

[Python-Dev] Re: The Default for python -X frozen_modules.

> On 28 Sep 2021, at 10:54, Antoine Pitrou wrote: > > On Tue, 28 Sep 2021 10:51:53 +0200 > Ronald Oussoren via Python-Dev wrote: >>> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote: >>> >>> On Mon, 27 Sep 2021 10:51:43 -0600 >>> Eric Sno

[Python-Dev] Re: The Default for python -X frozen_modules.

> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote: > > On Mon, 27 Sep 2021 10:51:43 -0600 > Eric Snow mailto:ericsnowcurren...@gmail.com>> > wrote: >> We've frozen most of the stdlib modules imported during "python -c >> pass" [1][2], to make startup a bit faster. Import of those modules >>

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

> On 26 Sep 2021, at 19:03, Christian Heimes wrote: > > On 26/09/2021 13.07, jack.jan...@cwi.nl wrote: >> The problem with the stable ABI is that very few developers are targeting >> it. I’m not sure why not, whether it has to do with incompleteness of the >> ABI, or with issues targeting it

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

> On 9 Jun 2021, at 12:28, Inada Naoki wrote: > > I think stable ABI keeps symbols, signatures, and memory layouts. > I don't think stable ABI keeps all behaviors. As often “it depends”. Behaviour is IMHO part of the API/ABI contract. That said, that does not necessarily mean that we

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

> On 9 Jun 2021, at 11:13, Victor Stinner wrote: > > On Wed, Jun 9, 2021 at 10:32 AM Ronald Oussoren via Python-Dev > wrote: >> Its a bit late to complain (and I’m not affected by this myself), but those >> functions are part of the stable ABI. The chang

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

> On 7 Jun 2021, at 05:05, Inada Naoki wrote: > > Hi, folks, > > Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted > DeprecationWarning when > '#' format is used without PY_SSIZE_T_CLEAN defined. > In Python 3.10, they raise a RuntimeError, not a warning. Extension >

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

> 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 singleton testable with `is`, > readily available, and extremely unlikely to appear in a data stream. > Its repr is "Ellipsis". >

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

> On 15 Apr 2021, at 14:48, Antoine Pitrou wrote: > > On Thu, 15 Apr 2021 14:32:05 +0200 > Victor Stinner wrote: >> SOURCE_DATE_EPOCH is not a random variable, but is a *standardised* >> environment variable: >> https://reproducible-builds.org/docs/source-date-epoch/ > > Standardized by

[Python-Dev] Re: NamedTemporaryFile and context managers

> On 8 Apr 2021, at 22:31, Ethan Furman wrote: > > In issue14243 [1] there are two issues being tracked: > > - the difference in opening shared files between posix and Windows > - the behavior of closing the underlying file in the middle of > NamedTemporaryFile's context management > > I'd

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

> On 19 Jan 2021, at 17:15, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 15:54:39 + > Mark Shannon mailto:m...@hotpy.org>> wrote: >> On 19/01/2021 3:40 pm, Antoine Pitrou wrote: >>> On Tue, 19 Jan 2021 13:31:45 + >>> Mark Shannon wrote: Hi everyone, It's time for

[Python-Dev] Re: Unification of the Mac builds?

> On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev > wrote: > > Ned, > > Thanks -- I'll take further discussion to the python-mac list. > > Ronald: > > That’s a feature of the framework build. The unix build is exactly the same > as a unix build on other platform. Adding the same

[Python-Dev] Re: Unification of the Mac builds?

> On 8 Jan 2021, at 20:38, Chris Barker via Python-Dev > wrote: > > Sorry if I'm out of the loop here, but with Apple's new chip coming out, we > need new a build configuration (which I think has already been started, if > not done). > > Perhaps we could take this opportunity to better

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 28 Dec 2020, at 14:00, Inada Naoki wrote: > > On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson > wrote: >> >> >> I would have thought that an object was defined by its behaviour rather >> than by any particular implementation detail. >> > > As my understanding, the policy "an object was

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 28 Dec 2020, at 03:58, Greg Ewing wrote: > > Rather than a full-blown buffer-protocol-like thing, could we > get by with something simpler? How about just having a flag > in the unicode object indicating that it doesn't own the > memory that it points to? I don’t know about the OP, but

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 26 Dec 2020, at 18:43, Guido van Rossum wrote: > > On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev > mailto:python-dev@python.org>> wrote: > It's worth comparing the situation with byte arrays. There is no problem > of translating different representations of an element,

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev > wrote: > > I was directed to post this request to the general Python development > community so hopefully this is on topic. > > One of the weaknesses of the PyUnicode implementation is that the type is > concrete and there is no

[Python-Dev] Re: macOS issues with 3.8.7rc1

> On 10 Dec 2020, at 06:38, Greg Ewing wrote: > > On 10/12/20 10:28 am, Guido van Rossum wrote: >> In my experience Apple hardware is very reliable and way outlives the OS >> updates. Even if an OS updates is still available, the newer OS often needs >> more memory, which can be a problem >

[Python-Dev] Re: macOS issues with 3.8.7rc1

> On 9 Dec 2020, at 19:10, Gregory P. Smith wrote: > > > > As a meta question: Is there a good reason to support binaries running on > macOS earlier than ~ $latest_version-1? > > Aren't systems running those old releases rather than upgrading unsupported > by Apple, never to be patched,

[Python-Dev] Re: macOS issues with 3.8.7rc1

> On 8 Dec 2020, at 19:59, Gregory Szorc wrote: > > Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS. > > Without the changes from https://github.com/python/cpython/pull/22855 > backported, attempting to > build a

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

> On 3 Nov 2020, at 16:36, Paul Svensson wrote: > > On Tue, 3 Nov 2020, Greg Ewing wrote: > >> On 3/11/20 11:01 am, Ethan Furman wrote: >> >>> I believe supporting >>> >>> case x, x # look ma! no guard! >>> is a possible future enhancement. >> >> In which case there will be a need

[Python-Dev] Re: Site Packages under LIB folder

> On 30 Oct 2020, at 08:37, rajesh.narasim...@gmail.com wrote: > > I have installed new python version 3.9, I wanted to move all the > site-packages that I have used in 3.8 to 3.9 lib. Is it possible? This is not a list for support on Python, but a list on the development of the Python

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

> On 30 Oct 2020, at 13:54, Victor Stinner wrote: > > Hi Ronald, > > Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren a > écrit : >> I agree. That’s what I tried to write, its not just providing a buildbot but >> also making sure that it keeps working and stays green. > > This is really

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

ro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/> > > On Fri, 30 Oct 2020, 09:29 Ronald Oussoren via Python-Dev, > mailto:python-dev@python.org>> wrote: > > > On 29 Oct 2020, at 22:43, Victor Stinner > <mai

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

> On 29 Oct 2020, at 22:43, Victor Stinner wrote: > > Hi, > > I propose to drop the Solaris support in Python to reduce the Python > maintenance burden: > > https://bugs.python.org/issue42173 > > I wrote a draft PR to show how much code could be removed (around 700 > lines in 65 files): >

[Python-Dev] Re: Speeding up CPython

> On 20 Oct 2020, at 14:53, Mark Shannon wrote: > > Hi everyone, > > CPython is slow. We all know that, yet little is done to fix it. > > I'd like to change that. > I have a plan to speed up CPython by a factor of five over the next few > years. But it needs funding. > > I am aware that

[Python-Dev] Re: Speeding up CPython

> On 21 Oct 2020, at 14:39, Larry Hastings wrote: > > On 10/21/20 4:04 AM, Antoine Pitrou wrote: >> (apart from small fixes relating to borrowed references, and >> that's mostly to make PyPy's life easier). > > Speaking as the Gilectomy guy: borrowed references are evil. The definition > of

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

> On 10 Jun 2020, at 14:33, Mark Shannon wrote: > > Hi Petr, > > On 09/06/2020 2:24 pm, Petr Viktorin wrote: >> 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

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

> On 29 Apr 2020, at 03:50, Eric Snow wrote: > > On Wed, Apr 22, 2020 at 2:43 AM Ronald Oussoren > wrote: >> My mail left out some important information, sorry about that. > > No worries. :) > >> PyObjC is a two-way bridge between Python and Objective-C. One half of this >> is that is

[Python-Dev] Re: killing static types (for sub-interpreters?)

> On 28 Apr 2020, at 20:38, Jim J. Jewett wrote: > > Why do sub-interpreters require (separate and) heap-allocated types? > > It seems types that are statically allocated are a pretty good use for > immortal objects, where you never change the refcount ... and then I don't > see why you

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

> On 21 Apr 2020, at 16:58, Eric Snow wrote: > > Thanks for explaining that, Ronald. It sounds like a lot of the > effort would relate to making classes work. I have some comments > in-line below. > > -eric > > On Tue, Apr 21, 2020 at 2:34 AM Ronald Oussoren > wrote: >>> On 21 Apr 2020,

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

> On 21 Apr 2020, at 03:21, Eric Snow wrote: > […] > On Mon, Apr 20, 2020 at 4:30 PM Nathaniel Smith wrote: > […] >> >> But notice that this means that no-one can use subinterpreters at all, >> until all of their C extensions have had significant reworks to use >> the new API, which will

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

> On 15 Apr 2020, at 03:39, Victor Stinner wrote: > > Hi Ronald, > > Le mar. 14 avr. 2020 à 18:25, Ronald Oussoren a > écrit : >> Making “PyObject” opaque will also affect the stable ABI because even types >> defined using the PyTypeSpec API embed a “PyObject” value in the structure >>

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

> On 10 Apr 2020, at 19:20, Victor Stinner wrote: > […] > > > PEP xxx: Modify the C API to hide implementation details > > > Abstract > > > * Hide implementation

[Python-Dev] Re: How official binaries are built?

> On 17 Oct 2019, at 08:13, Inada Naoki wrote: > > Thank you for your response. > And I'm sorry about ignoring this. Gmail marked it as spam. > > On Tue, Oct 15, 2019 at 6:20 PM Ned Deily wrote: >> >> We currently do not use those options to build the binaries for the >> python.org macOS

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

> On 1 Oct 2019, at 10:55, Thomas Wouters wrote: > > > > On Mon, Sep 30, 2019 at 11:00 PM Brett Cannon > wrote: > Victor Stinner wrote: > > Hi Nick, > > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan ncogh...@gmail.com > > a écrit : > > > I

[Python-Dev] Re: [Webmaster] Python for Mac OS X Catalina

Hi, As a workaround it is possible to install Python by choosing “open” from the context-menu of in the Finder instead of double clicking on the installer. This is currently necessary because the macOS Catalina has stricter requirements for signing installers, and the Python.org

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

> On 8 Aug 2019, at 17:42, Christian Tismer wrote: > > On 08.08.19 17:20, Ronald Oussoren via Python-Dev wrote: >> >> >>> On 8 Aug 2019, at 17:12, Christian Tismer >> <mailto:tis...@stackless.com>> wrote: >>> >>> Hi Ronald, &

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

> On 8 Aug 2019, at 17:12, Christian Tismer wrote: > > Hi Ronald, > > sure, the tuple is usually not very interesting; people look it up > once and use that info in the code. > > But I think things can be made quite efficient and pretty at the > same time. Such a return tuple could be hidden

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

Chrisian, How would these namedtuple/structseq values be used? I have a similar design with PyObjC: pass-by-reference “return” values are returned in a tuple, e.g.: void getpoint(pointclass* v, int* x, int *y)=>def get point(v: pointless) -> (int, int) BOOL getvalue(someclass*

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

Op 24 jul. 2019 om 02:27 heeft Steven D'Aprano het volgende geschreven: > But I can suggest at least one useful invariant. If a, b are two dicts: > >a.items() == b.items() > > ought to be equivalent to: > >(a.keys() == b.keys()) and (a.values() == b.values) I don’t think this

Re: [Python-Dev] Adding test.support.safe_rmpath()

— Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ > On 13 Feb 2019, at 16:10, Giampaolo Rodola' wrote: > > > > On Wed, Feb 13, 2019 at 2:27 PM Ronald Oussoren > wrote: > > >> On 13 Feb 2019, at 13:24, Giampaolo Rodola' >

Re: [Python-Dev] Adding test.support.safe_rmpath()

> On 13 Feb 2019, at 13:24, Giampaolo Rodola' wrote: > > > Hello, > after discovering os.makedirs() has no unit-tests > (https://bugs.python.org/issue35982 ) I > was thinking about working on a PR to increase the test coverage of > fs-related os.*

Re: [Python-Dev] Asking for reversion

> On 4 Feb 2019, at 04:25, Davin Potts > wrote: > > On 2/3/2019 7:55 PM, Guido van Rossum wrote: > > Also, did anyone ask Davin directly to roll it back? > > Simply put: no. There have been a number of reactionary comments in the > last 16 hours but no attempt to reach out to me directly

Re: [Python-Dev] Asking for reversion

> On 4 Feb 2019, at 03:10, Raymond Hettinger > wrote: > > >> On Feb 3, 2019, at 5:40 PM, Terry Reedy wrote: >> >> On 2/3/2019 7:55 PM, Guido van Rossum wrote: >>> Also, did anyone ask Davin directly to roll it back? >> >> Antoine posted on the issue, along with Robert O. Robert reviewed

Re: [Python-Dev] Python startup time

> On 9 Oct 2018, at 23:02, Gregory Szorc wrote: > > > > While we're here, CPython might want to look into getdirentriesattr() as > a replacement for readdir(). We switched to it in Mercurial several > years ago to make `hg status` operations significantly faster [2]. I'm > not sure if it

Re: [Python-Dev] A Subtle Bug in Class Initializations

> On 28 Aug 2018, at 22:09, Eddie Elizondo wrote: > > Hi everyone, > > Sorry for the delay - I finally sent out a patch: > https://bugs.python.org/issue34522. As I mentioned on the tracker this patch is incorrect because it redefines PyVarObject_HEAD_INIT in a way that changes the

Re: [Python-Dev] Use of Cython

> On 6 Aug 2018, at 17:13, Stefan Behnel wrote: > > Ronald Oussoren via Python-Dev schrieb am 06.08.2018 um 15:25: >>> On 5 Aug 2018, at 18:14, Nick Coghlan wrote: >>> On 5 August 2018 at 18:06, Ronald Oussoren wrote: >>>> I’m not sure if I understand thi

Re: [Python-Dev] Use of Cython

> On 5 Aug 2018, at 18:14, Nick Coghlan wrote: > > On 5 August 2018 at 18:06, Ronald Oussoren wrote: >> I’m not sure if I understand this, ctypes and cffi are used to access C APIs >> without writing C code including the CPython API (see for example >>

Re: [Python-Dev] Use of Cython

> On 5 Aug 2018, at 03:15, Nick Coghlan wrote: > > On 5 August 2018 at 00:46, Stefan Behnel wrote: >> Antoine Pitrou schrieb am 04.08.2018 um 15:57: >>> Actually, I think testing the C API is precisely the kind of area where >>> you don't want to involve a third-party, especially not a moving

Re: [Python-Dev] Let's change to C API!

> On 30 Jul 2018, at 10:20, Victor Stinner wrote: > > The API leaking all implementation details will remain available as an opt-in > option for Cython, cffi and debug tools. But this API will only be usable on > the "slow" Python runtime, the one which keeps maximum backward >

[Python-Dev] USE_STACKCHECK and running out of stack

Hi, I’m looking at PyOS_CheckStack because this feature might be useful on macOS (and when I created bpo-33955 for this someone ran with it and created a patch). Does anyone remember why the interpreter raises MemoryError and not RecursionError when PyOS_CheckStack detects that we’re about to

Re: [Python-Dev] Const access to CPython objects outside of GIL?

Op 17 jul. 2018 om 09:40 heeft Radim Řehůřek het volgende geschreven: > > > To be honest, I did do some CPython source code staring already. And at least > for the functions we care about, it wasn't all that painful (PyDict_GetItem > being the trickiest). Doing this wholesale might be a