[Python-Dev] Re: Exception compatibility with aliens

On Wed, 18 Jan 2023 12:04:41 +0200 Ville Voutilainen via Std-Proposals wrote: > On Wed, 18 Jan 2023 at 11:45, Frederick Virchanza Gotham via > Std-Proposals wrote: > > > > I have sent this email to two mailing lists for programming language > > proposals, the one for C++ and the one for Python.

[Python-Dev] Re: Switching to Discourse

On Fri, 02 Dec 2022 18:41:44 -0500 "Gordon R. Burgess" wrote: > I am a long time lurker here*, a professional and educational user of > the language, a list moderator with practical exeperience managing a > engaged community of a few thousand users over the course of a decade - > and yes, I am

[Python-Dev] Re: How about using modern C++ in development of CPython ?

Haven't we migrated to Discourse? This discussion will probably not have any effects on this mailing-list. (yes, not everyone likes Discourse, and I'm skeptical as well, but the decision has been made by now) On Mon, 17 Oct 2022 09:13:34 - "Denis Kotov" wrote: > Stephen J. Turnbull

[Python-Dev] Re: Adding new escapes to regex module

On Wed, 17 Aug 2022 19:23:02 +0100 MRAB wrote: > >> > >> I do not like introducing escapes which are not supported in other RE > >> implementations. There is a chance of future conflicts. > >> > >> Java broke compatibility in Java 8 by redefining \v from a single > >> vertical tab character to

[Python-Dev] Re: Switching to Discourse

On Thu, 21 Jul 2022 07:59:46 +0200 Stefan Behnel wrote: > h.vetin...@gmx.com schrieb am 18.07.22 um 18:04: > > One of the comments in the retro was: > >> Searching the archives is much easier and have found me many old threads > >> that I probably would have problem finding before since I

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

On Mon, 30 May 2022 12:53:57 -0700 Guido van Rossum wrote: > I would love to see header files used for this -- while I know there is a > long tradition of feature-flags that must be #defined by the user before > #including a header in order to affect what the header exports (or not!), > 30 years

[Python-Dev] Re: New public PyUnicodeBuilder C API

On Mon, 16 May 2022 14:22:44 +0200 Victor Stinner wrote: > On Mon, May 16, 2022 at 2:11 PM Antoine Pitrou wrote: > > > PyUnicodeBuilder_Init(); > > > > > > // Overallocation is more efficient if the

[Python-Dev] Re: New public PyUnicodeBuilder C API

On Mon, 16 May 2022 11:13:56 +0200 Victor Stinner wrote: > Hi, > > I propose adding a new C API to "build an Unicode string". What do you > think? Would it be efficient with any possible Unicode string storage > and any Python implementation? > > PyPy has an UnicodeBuilder type in Python, but

[Python-Dev] Re: Starting a new thread

On Tue, 10 May 2022 16:12:13 +0100 Barney Stratford wrote: > Hello all. > > It occurs to me that creating threads in Python is more awkward than it needs > to be. Every time I want to start a new thread, I end up writing the same > thing over and over again: > > def target(*args, **kwds): >

[Python-Dev] Re: Using the Python C API in C++

On Mon, 2 May 2022 15:21:24 +0200 Victor Stinner wrote: > > Slowly, more and more tests can be added. For example, this change fixing > compiler warnings when passing "const PyObject*" to Python C API functions > adds tests to _testcppext.cpp: > https://github.com/python/cpython/pull/92138

[Python-Dev] Re: Using the Python C API in C++

thon/cpython/issues/83536 > > In fact, after a long study, Python C API is *not* affected by this > issue. Using "module" remains valid in C++20: see the issue for > details. I'm not surprised. The C++ committee takes compatibility extremely seriously... Regards Antoine. > >

[Python-Dev] Re: Using the Python C API in C++

As a data point, I don't remember that recent versions of CPython brought any particular pain for PyArrow, which is a set of bindings written in Cython around some C++ core library code. Regards Antoine. On Wed, 27 Apr 2022 18:31:13 +0200 Victor Stinner wrote: > Hi, > > If you got issues

[Python-Dev] Re: Using the Python C API in C++

On Thu, 28 Apr 2022 22:03:25 +0900 "Stephen J. Turnbull" wrote: > h.vetin...@gmx.com writes: > > > While I don't know who proposed C++11 or where, I'd therefore like > > to propose to move to _at least_ C++14. > > What benefits does this have for Python development? Let me second that

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

able is an easy to influence a program or system whose inner workings you don't control (for example a system that spawns child Python processes). And it sounds like a good idea to allow that given that it improves security? Regards Antoine. > > Victor > > On Wed, Apr 27, 2022 at 4:

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

On Tue, 26 Apr 2022 11:46:41 +0200 Victor Stinner wrote: > I prefer to add an environment variable, only pass the option > explicitly on the command line. I don't really understand this sentence, can you rephrase? ___ Python-Dev mailing list --

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Wed, 20 Apr 2022 12:52:53 +0200 Victor Stinner wrote: > On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote: > > If the HPy design is the long term goal, why not just recommend that > > people use HPy? And keep the C API for expert users with specific > > needs tha

[Python-Dev] Re: Updating inspect APIs

On Sun, 17 Apr 2022 19:00:45 -0700 Guido van Rossum wrote: > Is it not acceptable to create new functions that return non-named-tuple > objects (e.g. dataclasses with slots)? I'd advocate creating a single new function that provides more structured access to that various information, like we did

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Tue, 5 Apr 2022 22:54:00 +0200 Victor Stinner wrote: > IMO it would be better to keep the HPy design as the long term goal: > > * Refer to Python objects with opaque handles > * All structures are opaque (with a few exceptions, like PyType_Spec) If the HPy design is the long term goal, why

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

On Wed, 30 Mar 2022 12:03:58 +0100 Steve Dower wrote: > On 30Mar2022 1124, Barney Gale wrote: > > I'd like to become a maintainer for the pathlib module, if possible. I > > know the code and tests inside-out, and I've been wrestling the > > internals for past few Python releases. I check the

[Python-Dev] Re: Changing unittest verbose output.

On Sun, 27 Mar 2022 00:48:04 - "Itay Yeshaya" wrote: > When running unittest with the -v flag, if a test has errors, and has a > docstring, the test name is shown on one line, and the docstring is shown on > the next line with the `ERROR` word. > For example: > > ./python.exe -m unittest

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On Sat, 19 Feb 2022 12:05:22 -0500 Larry Hastings wrote: > On 2/19/22 04:41, Antoine Pitrou wrote: > > On Fri, 18 Feb 2022 14:56:10 -0700 > > Eric Snow wrote: > >> On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings > >> wrote: > >>> He sugges

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On Fri, 18 Feb 2022 14:56:10 -0700 Eric Snow wrote: > On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote: > > I experimented with this at the EuroPython sprints in Berlin years ago. I > > was sitting next to MvL, who had an interesting observation about it. > > Classic MvL! :) > > > He

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

Hi, On Thu, 10 Feb 2022 23:58:31 +0100 Victor Stinner wrote: > > Would it make sense to move the pythoncapi_compat project under the > GitHub Python or PSF organization to make it more "official" and a > little bit more sustainable? I'm +1 on this. Many projects maintain their own set of

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

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 look at pythoncapi_compat.h, it provides backports for recently-introduced public APIs such as PyObject_CallOneArg().

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

On Wed, 9 Feb 2022 17:49:19 +0100 Victor Stinner wrote: > On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote: > > > Right now, a large number of macros cast their argument to a type. A > > > few examples: > > > > > > #define PyObject_TypeCheck(ob, type) > > >

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Wed, 09 Feb 2022 03:39:42 - h.vetin...@gmx.com wrote: > > That is becoming dated quickly, as Microsoft has deprecated, and is removing, > that version quite rapidly from their CI services (azure/GHA), i.e. mid > March, see: > https://github.com/actions/virtual-environments/issues/4312. >

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Tue, 08 Feb 2022 01:12:22 - "Jim J. Jewett" wrote: > - Should we require the presence of NaNs in order for CPython to build? > - Should we require IEEE 754 floating-point for CPython-the-implementation? > - Should we require IEEE 754 floating-point for Python-the-language? > > I don't

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On Tue, 8 Feb 2022 00:39:12 -0800 "Gregory P. Smith" wrote: > What does pyperformance say about --enable-optimizations builds with all of > those compiled out vs today? > > I like the runtime safety checking for purposes of making the lives of > Python C API users easier. But without the use of

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Mon, 7 Feb 2022 15:29:39 +0100 Victor Stinner wrote: > On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote: > > CPython is also affected by these issues, but the benefits of PEP 674 > > (alone) are too indirect, so I chose to avoid mentioning CPython > > issues directly, to avoid confusion.

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

On Tue, 18 Jan 2022 15:17:41 +0100 Victor Stinner wrote: > Hi, > > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on > updating Python 3.10 to Python 3.11 in Fedora, but some specific > Python 3.11 incompatible changes are causing more troubles than > others: >

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

discussion about it. See https://bugs.python.org/issue28739 for at least > part of the discussion. Ah, sorry for the misunderstanding. While the example I showed doesn't have any substitutions, I'm interested in the non-trivial (non-constant) case actually :-) Regards Antoine. > > Eric

[Python-Dev] Minor inconvenience: f-string not recognized as docstring

Hello, Currently, a f-string is not recognized as a docstring: >>> class C: f"foo" >>> C.__doc__ >>> This means you need to use a (admittedly easy) workaround: >>> class C: __doc__ = f"foo" >>> C.__doc__ 'foo' Shouldn't the former be allowed for convenience? Regards Antoine.

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

Hi Christian, On Sun, 9 Jan 2022 19:39:06 +0100 Christian Heimes wrote: > Hi, > > I would like to remind everybody that Python's support for OpenSSL 3.0 > is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code > kinda works. However there are known performance regressions,

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Mon, 3 Jan 2022 22:40:25 -0800 "Gregory P. Smith" wrote: > > rerunning a mere few of those in --rigorous mode for more runs does not > significantly improve the stddev so I'm not going to let that finish. The one benchmark that is bigint-heavy is pidigits AFAIK, so you might want to re-run

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Fri, 31 Dec 2021 11:18:34 + Mark Dickinson wrote: > > It looks as though the next step would be to run some integer-intensive > benchmarks on 32-bit ARM, with both --enable-big-digits=15 and > --enable-big-digits=30. If those show a win (or at least, not a significant > loss) for 30-bit

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On Sat, 18 Dec 2021 08:40:57 - "Jim J. Jewett" wrote: > Why are Immutability and transitive Immortality needed to share an object > across interpreters? Immutability is a functional requirement: you don't want one interpreter to be able to change the state of another one by mistake. Unlike

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

On Thu, 16 Dec 2021 11:38:28 -0700 Eric Snow wrote: > On Thu, Dec 16, 2021 at 4:34 AM Antoine Pitrou wrote: > > As a data point, in PyArrow, we have a bunch of C++ code that interacts > > with Python but doesn't belong in a particular Python module. That C++ > > code can

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

On Thu, 16 Dec 2021 13:25:53 +0100 Petr Viktorin wrote: > On 16. 12. 21 12:33, Antoine Pitrou wrote: > > On Tue, 14 Dec 2021 10:38:25 -0700 > > Eric Snow wrote: > >> > >> So we (the core devs) would effectively be requiring those extensions > >&

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

On Thu, 16 Dec 2021 23:32:17 +1100 Steven D'Aprano wrote: > On Thu, Dec 16, 2021 at 12:23:09PM +0100, Antoine Pitrou wrote: > > > > The "real number of references" would not be known for immortal objects. > > Oh that surprises me. How does that work? Does tha

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

On Tue, 14 Dec 2021 10:38:25 -0700 Eric Snow wrote: > > So we (the core devs) would effectively be requiring those extensions > to support subinterpreters, regardless of letting them opt out. This > situation has been weighing heavily on my mind since Nathaniel brought > this up. Here are some

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

On Thu, 16 Dec 2021 14:32:05 +1100 Steven D'Aprano wrote: > On Wed, Dec 15, 2021 at 02:57:46PM -0800, Guido van Rossum wrote: > > > Another potential issue is that there may be some applications that take > > refcounts at face value (perhaps obtained using sys.getrefcount()). These > > would

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

On Wed, 15 Dec 2021 14:13:03 +0100 Antoine Pitrou wrote: > Hi Eric, > > Did you try to take into account the envisioned project for adding a > "complete" GC and removing the GIL? Sorry, I was misremembering the details. Sam Gross' proposal (posted here on 07/1

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

Hi Eric, Did you try to take into account the envisioned project for adding a "complete" GC and removing the GIL? Regards Antoine. On Tue, 14 Dec 2021 10:12:07 -0700 Eric Snow wrote: > Hi all, > > I'm still hoping to land a per-interpreter GIL for 3.11. There is > still a decent amount

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On Wed, 15 Dec 2021 10:42:17 +0100 Christian Heimes wrote: > On 14/12/2021 19.19, Eric Snow wrote: > > A while back I concluded that neither approach would work for us. The > > approach I had taken would have significant cache performance > > penalties in a per-interpreter GIL world. The

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

On Tue, 7 Dec 2021 15:39:25 +0100 Petr Viktorin wrote: > On 30. 11. 21 19:52, Victor Stinner wrote: > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote: > >> How about *not* asking for an exception and just following the PEP 387 > >> process? Is that really too burdensome? > > > >

[Python-Dev] Re: Optimizing literal comparisons and contains

On Mon, 29 Nov 2021 12:32:19 + Mark Shannon wrote: > Hi, > > I am surprised by the insistence on this thread for excluding comparisons > from constant folding. > Why should we special case comparisons? Am I missing something here? Is it actually special-cased or is it just not implemented?

[Python-Dev] Re: The current state of typing PEPs

On Thu, 25 Nov 2021 23:51:58 + Oscar Benjamin wrote: > > > > Not a PEP proponent (or even a typing user), but I thought this had > > been made clear long ago. My understanding is that optional, > > incremental type hints are and have always been considered the primary > > use case for

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

On Tue, 23 Nov 2021 18:00:28 +0100 Victor Stinner wrote: > > From what I understood, debug builds are mostly used by Python core > developers to develop Python and so an important use case for > performance is running the Python test suite. > > (1) Replacing macros with static inline functions

[Python-Dev] Re: Having Sorted Containers in stdlib?

> Thanks, > Bob > > > On 11 Nov 2021, at 12:28, Paul Moore wrote: > > > > On Thu, 11 Nov 2021 at 11:51, Antoine Pitrou > <mailto:anto...@python.org>> wrote: > >> > >> On Wed, 10 Nov 2021 21:12:17 -0600 > >> Tim Peters

[Python-Dev] Re: Having Sorted Containers in stdlib?

On Thu, 11 Nov 2021 20:58:29 + Bob Fang wrote: > Just want to mention that we do have this nice website to look at, although I > am not sure how up to date it is: > > https://www.wheelodex.org/projects/sortedcontainers/rdepends/?page=1 Wow, thank you, that is very nice! Best regards

[Python-Dev] Re: Having Sorted Containers in stdlib?

On Thu, 11 Nov 2021 11:01:32 -0800 Richard Levasseur wrote: > > In the end, it was a fun exercise, but in practice a dictionary and > sorted() got me 90% of the way there and sufficed. Optimizing that last 10% > wasn't worth the effort. > > Anyways, I came to two particular, IMHO, conclusions:

[Python-Dev] Re: Having Sorted Containers in stdlib?

On Wed, 10 Nov 2021 21:12:17 -0600 Tim Peters wrote: > [Bob Fang ] > > This is a modest proposal to consider having sorted containers > > (http://www.grantjenks.com/docs/sortedcontainers/) in standard library. > > +1 from me, but if and only if Grant Jenks (its author) wants that too. > >

[Python-Dev] Re: PEP 3118 C APIs

Hi Joannah, On Thu, 21 Oct 2021 13:00:11 -0300 Joannah Nanjekye wrote: > Last year I opened the following issues, to implement > int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject > *obj). > > They were meant to be as part of PEP 3118, I wonder if they are worth an >

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

On Wed, 20 Oct 2021 02:55:52 +0200 Victor Stinner wrote: > > Debug build > --- > > When Python is built in debug mode, most compiler optimizations are > disabled. For example, Visual Studio disables inlining. Benchmarks must > not be run on a Python debug build, only on release build:

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

On Fri, 15 Oct 2021 12:36:15 +1100 Steven D'Aprano wrote: > Hello Doug, > > On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote: > > > I believe strong and valid arguments can be made about the use of None > > being a fundamental flaw in some types of coding > > Can you elaborate on

[Python-Dev] Re: What is __int__ still useful for?

On Thu, 14 Oct 2021 04:24:30 -0500 Eryk Sun wrote: > > > Note that PyNumber_Long() is now the only place inside the interpreter > > calling the `nb_int` slot. But since it also has those undesirable code > > paths accepting str and buffer-like objects, it's usable in fewer > > situations than

[Python-Dev] Re: What is __int__ still useful for?

On Wed, 13 Oct 2021 17:00:49 -0700 Guido van Rossum wrote: > On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner wrote: > > > Honestly, I don't understand well the difference between __int__() and > > __index__(). > > > > * https://docs.python.org/dev/reference/datamodel.html#object.__int__ > > *

[Python-Dev] Re: What is __int__ still useful for?

On Thu, 14 Oct 2021 11:52:11 +1300 Greg Ewing wrote: > On 14/10/21 11:19 am, Greg Ewing wrote: > > Not really -- __int__ is expected to return something of type > > int, whereas __trunc__ is expected to return the same type as > > its operand. > > Scratch that, it seems __trunc__ also returns

[Python-Dev] What is __int__ still useful for?

Hello, It used to be that defining __int__ allowed an object to be accepted as an integer from various functions, internal and third-party, thanks to being implicitly called by e.g. PyLong_AsLong. Today, and since bpo-37999, this is no longer the case. It seems that __int__ has now become a

[Python-Dev] Re: Packing a long list of numbers into memory

On Sun, 10 Oct 2021 11:19:44 -0300 Facundo Batista wrote: > Hello everyone! > > I need to pack a long list of numbers into shared memory, so I thought > about using `struct.pack_into`. > > Its signature is > > struct.pack_into(format, buffer, offset, v1, v2, ...) > > I have a long list of

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

On Thu, 7 Oct 2021 15:52:56 -0400 Sam Gross wrote: > Hi, > > I've been working on changes to CPython to allow it to run without the > global interpreter lock. I'd like to share a working proof-of-concept that > can run without the GIL. The proof-of-concept involves substantial changes > to

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

On Wed, 6 Oct 2021 09:05:57 -0700 Yury Selivanov wrote: > > So I'm -1 on `except group` or any variant that uses soft keywords. If the > SC considers making `group` a proper keyword I can possibly change my mind > on this. How about a dedicated keyword such as "exceptany" or "exceptall"?

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

On Mon, 4 Oct 2021 12:18:35 -0400 Calvin Spealman wrote: > On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote: > > > The question was about which style to *recommend* (a la PEP-8). > > > > I think the very fact that it can't (or is difficult) be enforced, How so? If style checkers are

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

On Sun, 3 Oct 2021 19:42:29 +0200 Łukasz Langa wrote: > > -1 > > If I could read the vertical line as a pipe character, the expression would > read "except or E as e". > But I can't read it that way anyway. Instead, all I see is a lowercase > EXCEPTL. > > My idea is this: > > try: > ...

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Sat, 2 Oct 2021 13:27:03 +0100 Paul Moore wrote: > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 > > I agree with the comment made on that issue - this isn't the right way > to handle the problem. We need

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

On Tue, 28 Sep 2021 09:14:38 -0400 "Eric V. Smith" wrote: > On 9/28/2021 9:10 AM, Antoine Pitrou wrote: > > On Tue, 28 Sep 2021 08:55:05 -0400 > > "Eric V. Smith" wrote: > >>> So I prefer to teach everybody how to use "-X froze

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

On Tue, 28 Sep 2021 08:55:05 -0400 "Eric V. Smith" wrote: > > > > So I prefer to teach everybody how to use "-X frozen_modules=off" if > > they want to hack the stdlib for their greatest pleasure. I prefer > > that such special use case requires an opt-in option, the special use > > case is not

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

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 Snow > <mailto:ericsnowcurren...@gmail.com>> wrote: > >> We've froz

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

On Mon, 27 Sep 2021 10:51:43 -0600 Eric Snow 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 > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Thu, 9 Sep 2021 12:06:49 +0200 Victor Stinner wrote: > I proposed bytes.byte earlier in this thread: > https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ > > Gregory dislikes the name: "I don't *like* to argue over names (the > last stage of

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Thu, 9 Sep 2021 18:55:04 +1000 Nick Coghlan wrote: > > P.S. The fact that it *didn't* look like the inverse operation for > `int.from_bytes` was one advantage of calling the method > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC > is right that `bytes.fromint` is a

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

On Thu, 2 Sep 2021 13:31:32 +1200 Greg Ewing wrote: > On 2/09/21 4:46 am, Victor Stinner wrote: > > If creating a fake frame is a common use case, we can maybe write a > > public C API for that. For example, I saw parser injecting frames to > > show the file name and line number of the parsed

[Python-Dev] Re: My apologies to the list

On Wed, 25 Aug 2021 12:22:29 -0700 Brett Cannon wrote: > I just wanted to apologize for any angst or noise my replies to Marco > caused folks. I should have known that correcting Marco on how to address > me would have triggered an outsized reply (the real intent of that overall > email was to

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Sun, 22 Aug 2021 16:08:56 -0700 Guido van Rossum wrote: > Hm, I don’t think the major use for bchr() will be with a constant. What would be the major use for bchr()? I don't think I've ever regretted its absence. Regards Antoine. > > On Sun, Aug 22, 2021 at 14:48 Gregory P. Smith

[Python-Dev] Re: Dropping out of this list

On Wed, 18 Aug 2021 21:14:22 -0500 Tim Peters wrote: > Various variations on: > > > ... I am also considering unsubscribing if someone doesn't step in and stop > > the mess going on between Brett and Marco. ... > > Overall, "me too!" pile-ons _are_ "the [bulk of the] mess" to most > list

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

On Tue, 17 Aug 2021 12:00:11 +0200 Łukasz Langa wrote: > > Now, there are a couple of things we can do here: > Option 1: Finish GH-12607 to fix the old macros, keeping in mind this will > restore compatibility lost with Python 3.8 - 3.10 only for users of 3.11+ > Option 2: Review and merge

[Python-Dev] Re: python-dev thread w/ Marco Sulla

On Mon, 16 Aug 2021 09:47:13 -0700 Brett Cannon wrote: > https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/ > > I can't be objective with Marco as I believe we have recorded issues with > him previously (as with Steven if you take Marco's initial

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Fri, 6 Aug 2021 01:37:48 +0900 "Stephen J. Turnbull" wrote: > Christopher Barker writes: > > > A byte is not a character > > While I am -0.5 on bchr for many of the reasons already cited in the > thread (and would be -1 if the methods names proposed for the feature > were a bit more

[Python-Dev] Re: Is the Python review process flawed?

On Tue, 29 Jun 2021 13:56:18 -0300 Joannah Nanjekye wrote: > > why doesn't it get merged? > > The last significant discussion from a core dev on the most relevant PR > here: https://github.com/python/cpython/pull/4819 > shows that Antoine was familiarizing himself with the feature and had

[Python-Dev] Re: Roundup to GitHub Issues migration

On Tue, 22 Jun 2021 19:49:12 -0400 Ned Deily wrote: > > I think this points out a problem with our current bug system and one that it > would be good to try to resolve in migrating to a new system: that is, the > ambiguity of the "version" metadata in an issue. Today, that list of versions >

[Python-Dev] Re: Roundup to GitHub Issues migration

On Tue, 22 Jun 2021 05:01:17 -0700 Nathaniel Smith wrote: > > As much as we might wish otherwise, the PSF is also a US entity and > has to comply with US laws. GitHub's official policy at > >https://docs.github.com/en/github/site-policy/github-and-trade-controls > > gives the impression

[Python-Dev] Re: Roundup to GitHub Issues migration

On Mon, 21 Jun 2021 11:27:27 +0200 Baptiste Carvello wrote: > Hi, > > Le 21/06/2021 à 04:20, Ezio Melotti a écrit : > > This effort is being tracked at > > : this board reflects > > the current status of the project. The PEPs (including PEP 588 --

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

On Mon, 7 Jun 2021 06:49:24 -0700 Senthil Kumaran wrote: > On Sun, Jun 06, 2021 at 04:07:57PM -0700, Dan Stromberg wrote: > > I've got a comparison of sort algorithms in both Cython and Pure Python > > (your > > choice) at: > > https://stromberg.dnsalias.org/~strombrg/sort-comparison/  > >

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

On Thu, 13 May 2021 13:44:54 +0100 Steve Dower wrote: > On 13May2021 1248, Petr Viktorin wrote: > > On 13. 05. 21 11:45, Antoine Pitrou wrote: > >> > >> Le 13/05/2021 à 11:40, Irit Katriel a écrit : > >>> > >>> > >>> On

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

Le 13/05/2021 à 11:40, Irit Katriel a écrit : On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou <mailto:anto...@python.org>> wrote:  I agree that is a reasonable spelling. I initially suggested , but now I'm not sure because it doesn't indicate what happens when you don'

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

On Thu, 13 May 2021 10:15:03 +0100 Irit Katriel via Python-Dev wrote: > Following a recent change, we now have in traceback.py: > > _sentinel = object() > def print_exception(exc, /, value=_sentinel, tb=_sentinel, limit=None, > file=None, chain=True): > > So now: > > >>> import

[Python-Dev] Re: Speeding up CPython

On Wed, 12 May 2021 17:05:03 -0400 Terry Reedy wrote: > > > contributing and level up to gain a pool of resources > > We don't need to wait for easy issues or things like > > that or wait for PR merge to level up. > > > > Yet you always see it: new people not knowing where to start, > > highly

[Python-Dev] Re: Necessary or not for enhancement of issue44097: “add configure option to control the groups of .pyc files to install”

Hi Peixing, On Wed, 12 May 2021 09:27:46 + "Xin, Peixing" wrote: > > I created issue44097 for build enhancement: “add configure option to control > the groups of .pyc files to install” and PR 23920 for the solution. From the > only a few of comments I’ve got, someone thinks this

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

On Tue, 11 May 2021 10:25:38 +0200 Petr Viktorin wrote: > 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 > >

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Sat, 8 May 2021 21:59:49 +0100 Pablo Galindo Salgado wrote: > > That could work, but in my personal opinion, I would prefer not to do > that as it complicates things and I think is overkill. > > Let me expand on this: > > I recognize the problem that -OO can be quite unusable if some of

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Sun, 09 May 2021 02:16:02 - "Jim J. Jewett" wrote: > Antoine Pitrou wrote: > > On Sat, 8 May 2021 02:58:40 + > > Neil Schemenauer nas-pyt...@arctrix.com wrote: > > > > It would be cool if we could mmap the pyc files and have the VM run

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

You can certainly get fancy and apply delta encoding + entropy compression, such as done in Parquet, a high-performance data storage format: https://github.com/apache/parquet-format/blob/master/Encodings.md#delta-encoding-delta_binary_packed--5 (the linked paper from Lemire and Boytsov gives a

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Fri, 7 May 2021 23:20:55 +0100 Irit Katriel via Python-Dev wrote: > On Fri, May 7, 2021 at 10:52 PM Pablo Galindo Salgado > wrote: > > > > > The cost of this is having the start column number and end column number > > information for every bytecode instruction > > > > > Is it really

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Sat, 8 May 2021 02:58:40 + Neil Schemenauer wrote: > On 2021-05-07, Pablo Galindo Salgado wrote: > > Technically the main concern may be the size of the unmarshalled > > pyc files in memory, more than the storage size of disk. > > It would be cool if we could mmap the pyc files and have

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Fri, 7 May 2021 22:45:38 +0100 Pablo Galindo Salgado wrote: > > The cost of this is having the start column number and end column number > information for every bytecode instruction > and this is what we want to discuss (there is also some stack cost to > re-raise exceptions but that's not a

[Python-Dev] Re: In what tense should the changelog be written?

On Thu, 29 Apr 2021 21:52:14 -0700 Larry Hastings wrote: > D'oh!  I have a second draft already. > > Your NEWS entry should be written in the /present tense,/ and should > start with a verb: > > * Add foo [...] > * Change bar [...] > * Remove bat [...] > * Fix

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

On Thu, 29 Apr 2021 18:37:29 +0100 MRAB wrote: > On 2021-04-29 18:19, Ethan Furman wrote: > > An excerpt from bpo-31369: re.RegexFlag and `__all__` > > > > GvR: > > > > > One thing I discovered when developing this example: there doesn't seem > > to be a flag to > > > represent 0

[Python-Dev] Re: expanduser('~other') reliability and future

On Wed, 28 Apr 2021 10:05:32 -0700 Guido van Rossum wrote: > On UNIX-oid platforms (e.g. BSD, Linux, Mac), ~user/ should be reasonably > reliable, after all the shell does it. On Windows, only ~/ can be relied > upon -- the rest is "best effort". I'd be okay with deprecating ~user/ on > Windows,

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 12:47:42 -0300 Luciano Ramalho wrote: > > Go is by far the most successful statically typed language created so > far in the 21st century, First, it seems gratuitous to restrict your search to "created so far in the 21st century". I suppose that allows you to eliminate

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Wed, 21 Apr 2021 12:36:34 -0700 Christopher Barker wrote: > > But that's not what duck typing is (at least to me :-) ) For a given > function, I need the passed in object to quack (and yes, I need that quack > to sound like a duck) -- but I usually don't care whether that object > waddles

  1   2   3   4   5   6   7   8   9   10   >