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

[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 <mailto:ronaldousso...@mac.com>> wrote: > > >> On 29 Mar 2022, at 00:34, Brett Cannon > <mailto:br...@python.org>> wrote: >> >

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

[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

rt for old versions is also work. The universal2 patches finally dropped support for weak linking a couple of APIs that were introduced in macOS 10.4, which we haven’t supported in a very long while. Ronald > > -gps > > On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <mailto:gregory.s

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

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

[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 “Py

[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 <mailto:ronaldousso...@mac.com>> wrote: > > >> On 13 Feb 2019, at 13:2

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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

> On 17 Jun 2018, at 16:31, Stefan Behnel wrote: > > Ronald Oussoren schrieb am 17.06.2018 um 14:50: >> Why did you add a tp_ccalloffset slot to the type with the actual >> information in instances instead of storing the information in a slot? > > If the co

Re: [Python-Dev] Some data points for the "annual release cadence" concept

> On 15 Jun 2018, at 13:00, Nick Coghlan wrote: > > On 14 June 2018 at 06:30, Ronald Oussoren <mailto:ronaldousso...@mac.com>> wrote: >> On 13 Jun 2018, at 15:42, Nick Coghlan > <mailto:ncogh...@gmail.com>> wrote: >> >> Yeah, pretty much -

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

> On 17 Jun 2018, at 11:00, Jeroen Demeyer wrote: > > Hello, > > I have been working on a slightly different PEP to use a new type slot > tp_ccalloffset instead the base_function base class. You can see the work in > progress here: > > https://github.com/jdemeyer/PEP-ccall > > By

Re: [Python-Dev] Some data points for the "annual release cadence" concept

> On 13 Jun 2018, at 15:42, Nick Coghlan wrote: > > On 13 June 2018 at 02:23, Guido van Rossum > wrote: > So, to summarize, we need something like six for C? > > Yeah, pretty much - once we can get to the point where it's routine for folks > to be building "abiX" or

Re: [Python-Dev] Idea: reduce GC threshold in development mode (-X dev)

> On 8 Jun 2018, at 12:36, Serhiy Storchaka wrote: > > 08.06.18 11:31, Victor Stinner пише: >> Do you suggest to trigger a fake "GC collection" which would just >> visit all objects with a no-op visit callback? I like the idea! >> >> Yeah, that would help to detect objects in an inconsistent

Re: [Python-Dev] Stable ABI

> On 3 Jun 2018, at 17:04, Eric V. Smith wrote: > > On 6/3/2018 10:55 AM, Christian Tismer wrote: >> On 03.06.18 13:18, Ronald Oussoren wrote: >>> >>> >>>> On 3 Jun 2018, at 12:03, Christian Tismer wrote: >> ... >>>> &g

Re: [Python-Dev] Stable ABI

> On 4 Jun 2018, at 08:35, Ronald Oussoren wrote: > > > >> On 3 Jun 2018, at 17:04, Eric V. Smith > <mailto:e...@trueblade.com>> wrote: >> >> On 6/3/2018 10:55 AM, Christian Tismer wrote: >>> On 03.06.18 13:18, Ronald Oussoren wrote: &

Re: [Python-Dev] Stable ABI

> On 3 Jun 2018, at 12:03, Christian Tismer wrote: > > On 02.06.18 05:47, Nick Coghlan wrote: >> On 2 June 2018 at 03:45, Jeroen Demeyer > > wrote: >> >>On 2018-06-01 17:18, Nathaniel Smith wrote: >> >>Unfortunately, very few people use the stable ABI

Re: [Python-Dev] Drop/deprecate Tkinter?

> On 2 May 2018, at 22:51, Ivan Pozdeev via Python-Dev > wrote: > > As https://bugs.python.org/issue33257 and https://bugs.python.org/issue33316 > showed, Tkinter is broken, for both Py2 and Py3, with both threaded and > non-threaded Tcl, since 2002 at least, and

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 01:40 PM, Antoine Pitrou wrote: A safer alternative is to use the *lower* bits of pointers. The bottom 3 bits are always available for storing ancillary information, since typically all heap-allocated data will be at least 8-bytes aligned (probably

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 03:11 PM, "Joao S. O. Bueno" wrote: Not only that, but afaik Linux could simply raise that 57bit virtual to 64bit virtual without previous warning on any version change. The change from 48-bit to 57-bit virtual addresses was not done without any

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 08:31 AM, INADA Naoki wrote: Hi, As far as I know, most amd64 and arm64 systems use only 48bit address spaces. (except [1]) [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf It means there are some

Re: [Python-Dev] [python-committers] [RELEASE] Python 3.7.0b1 is now available for testing

> On 1 Feb 2018, at 02:34, Ned Deily wrote: > > […] > > Attention macOS users: with 3.7.0b1, we are providing a choice of > two binary installers. The new variant provides a 64-bit-only > version for macOS 10.9 and later systems; this variant also now > includes its own

Re: [Python-Dev] OS-X builds for 3.7.0

> On 30 Jan 2018, at 18:42, Chris Barker wrote: > > Ned, > > It looks like you're still building OS-X the same way as in the past: > > Intel 32+64 bit, 10.6 compatibility > > Is that right? > > Might it be time for an update? > > Do we still need to support 32 bit?

Re: [Python-Dev] [ssl] The weird case of IDNA

> On 31 Dec 2017, at 18:07, Nathaniel Smith wrote: > > On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" > > wrote: > Nathaniel Smith writes: > > > Issue 1: Python's built-in IDNA implementation

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

> On 1 Nov 2017, at 22:47, Ned Deily wrote: > > Happy belated Halloween to those who celebrate it; I hope it wasn't too > scary! Also possibly scary: we have just a little over 12 weeks remaining > until Python 3.7's feature code cutoff, 2018-01-29. Those 12 weeks include a

Re: [Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

> On 14 Oct 2017, at 16:37, Martin Teichmann wrote: > >> Things that will not work if Enum does not have a metaclass: >> >> list(EnumClass) -> list of enum members >> dir(EnumClass) -> custom list of "interesting" items >> len(EnumClass) -> number of members >>

Re: [Python-Dev] Investigating time for `import requests`

Op 10 okt. 2017 om 01:48 heeft Brett Cannon <br...@python.org <mailto:br...@python.org>> het volgende geschreven: > > > On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> wrote: > Op 3 okt. 2017 om 04:

Re: [Python-Dev] Investigating time for `import requests`

Op 3 okt. 2017 om 04:29 heeft Barry Warsaw het volgende geschreven: > On Oct 2, 2017, at 14:56, Brett Cannon wrote: > >> So Mercurial specifically is an odd duck because they already do lazy >> importing (in fact they are using the lazy loading support

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

> On 6 Sep 2017, at 00:03, Larry Hastings wrote: > > > > I've written a PEP proposing a language change: > https://www.python.org/dev/peps/pep-0549/ > > The TL;DR summary: add support for property objects to modules. I've

Re: [Python-Dev] Remove embedded expat library?

> On 11 Jun 2017, at 12:10, Victor Stinner <victor.stin...@gmail.com> wrote: > > Le 11 juin 2017 09:38, "Ronald Oussoren" <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> a écrit : > I don’t think it would be a good idea to rely on the sys

Re: [Python-Dev] Remove embedded expat library?

> On 9 Jun 2017, at 18:03, Ned Deily wrote: > > On Jun 9, 2017, at 08:43, Victor Stinner wrote: > >> I expect that all Linux distributions build Python using >> --with-system-expat. It may become the default? What about macOS and >> other operating

Re: [Python-Dev] Can we use "designated initializer" widely in core modules?

> On 18 Jan 2017, at 02:16, Victor Stinner wrote: > > 2017-01-18 1:59 GMT+01:00 INADA Naoki : >> I think mixing two forms is OK only if new form is used only at bottom. >> (like keyword arguments are allowed after all positional arguments in >>

Re: [Python-Dev] Document C API that is not part of the limited API

> On 30 Dec 2016, at 15:33, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 29 December 2016 at 06:41, Steve Dower <steve.do...@python.org > <mailto:steve.do...@python.org>> wrote: > On 28Dec2016 1145, Brett Cannon wrote: > On Tue, 27 Dec 2016 at 12:15 Ron

Re: [Python-Dev] Document C API that is not part of the limited API

> On 27 Dec 2016, at 20:04, Serhiy Storchaka wrote: > > From the documentation: > > https://docs.python.org/3/c-api/stable.html > >In the C API documentation, API elements that are not part of the limited > API are marked as "Not part of the limited API." > > But

Re: [Python-Dev] Making sure dictionary adds/deletes during iteration always raise exception

> On 13 Dec 2016, at 17:52, Eric V. Smith wrote: > > >> On Dec 13, 2016, at 11:42 AM, Raymond Hettinger >> wrote: >> >> >>> On Dec 13, 2016, at 1:51 AM, Max Moroz wrote: >>> >>> Would it be worth ensuring that an

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

> On 24 Jul 2016, at 13:06, Ronald Oussoren <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> wrote: > … > But on the other hand, that’s why wanted to use PyObjC to validate > the PEP in the first place. I’ve hit a fairly significant issue with this, P

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

On 24 Jul 2016, at 13:06, Ronald Oussoren <ronaldousso...@mac.com> wrote:…But on the other hand, that’s why wanted to use PyObjC to validatethe PEP in the first place.I’ve hit a fairly significant issue with this, PyObjC’s super contains more magic than just this magic that would be fixed

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

> On 24 Jul 2016, at 12:37, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 23 July 2016 at 22:26, Ronald Oussoren <ronaldousso...@mac.com> wrote: >> I’m currently working on getting the patch in 18181 up-to-date w.r.t. the >> current trunk, the patch in th

[Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

Hi, It’s getting a tradition for me to work on PEP 447 during the EuroPython sprints and disappear afterwards. Hopefully I can manage to avoid the latter step this year… Last year the conclusion appeared to be that this is an acceptable PEP, but Mark Shannon had a concern about a default

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

On 26 Jul 2015, at 14:18, Mark Shannon m...@hotpy.org wrote: On 26 July 2015 at 10:41 Ronald Oussoren ronaldousso...@mac.com wrote: On 26 Jul 2015, at 09:14, Ronald Oussoren ronaldousso...@mac.com wrote: On 25 Jul 2015, at 17:39, Mark Shannon m...@hotpy.org mailto:m...@hotpy.org

Re: [Python-Dev] Status on PEP-431 Timezones

On 28 Jul 2015, at 03:13, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:11 PM, Ronald Oussoren wrote: Treating time as UTC with conversions at the application edge might be cleaner in some sense, but can make code harder

  1   2   3   4   5   >