[Python-Dev] Re: Retiring this mailing list ?

On 11/14/2023 1:21 PM, Steve Holden wrote: On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg wrote: [...] Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) [...] Hi Marc-Andre, Maybe just require senders to be members

[Python-Dev] Re: Fwd: Python 3.11 performance with frame pointers

I suggest re-posting this on discuss.python.org as more engaged active core devs will pay attention to it there. On Wed, Jan 4, 2023 at 11:12 AM Daan De Meyer wrote: > Hi, > > As part of the proposal to enable frame pointers by default in Fedora >

[Python-Dev] Re: Switching to Discourse

On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner wrote: > > Should we *close* the python-dev mailing list? > I'd be in favor of this. Or at least setting up an auto-responder suggesting people post on discuss.python.org instead. -gps ___ Python-Dev

[Python-Dev] Re: RFC: expose ssl internals for use by ctypes/cffi

On Wed, Nov 30, 2022 at 12:47 PM Steve Dower wrote: > On 11/30/2022 4:52 PM, chris...@weinigel.se wrote: > > Does this seem like a good idea? As I said, I feel that it is a bit > ugly, but it does mean that if someone wants to use some > SSL_really_obscure_function in libcrypto or libssl they

[Python-Dev] Re: [CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10

The patches to 3.6-3.10 have been merged, which means they will go out in the next Python patch release for those updates. ie: https://github.com/python/cpython/issues/98517 You can see the planned schedule of those on https://peps.python.org/pep-0619/ and related similar peps for older python

[Python-Dev] Re: Embedded Python Memory Leaks

On Thu, Oct 6, 2022 at 12:48 PM wrote: > Hi Python team > > Is any plan to try and fix memory leaks when embedding Python in a C/C++ > application? > Please file issues on github with details if you find problems. -gps ___ Python-Dev mailing list --

[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization

You should bring this up on discuss.python.org. It's not going to see much if any discussion here. Eric On 9/14/2022 10:05 AM, Philipp Burch wrote: Hello everyone, the docs on the upcoming 3.11 release state > This [specializing adaptive interpreter] also brings in another concept called

[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install

-cc:help (bcc) FWIW the thing to do to move this forward is to open a new PR. Patches attached to an email are lost like tears in the rain. What you describe of cross compilation where host and target triples appear the same but use different libraries is a valid cross compilation case. But

[Python-Dev] Re: Is it possible to view tokenizer output?

python -m tokenize < file-to-parse.py See the comment at the top of tokenize.py. IIRC, it re-implements the tokenizer, it does not call the one used for python code. Eric On 5/29/2022 6:59 PM, Jack wrote: Hi, I'm just getting into the CPython codebase just for fun, and I've just started

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

On Sat, May 28, 2022 at 12:55 PM Guido van Rossum wrote: > > On Sat, May 28, 2022 at 12:11 MRAB > > Names in Python are case-sensitive, yet the string prefixes are >> case-/insensitive/. >> >> Why? > > > IIRC we copied this from C for numeric suffixes (0l and 0L are the same; > also hex digits

[Python-Dev] Re: Raw strings ending with a backslash

On 5/28/2022 7:57 AM, Damian Shaw wrote: That PR seems to make \' and \" not special in general right? I think this is a more limited proposal, to only change the behavior when \ is at the end of a string, so the only behavior difference would never receiving the error "SyntaxError: EOL while

[Python-Dev] Re: Starting a new thread

On Tue, May 10, 2022 at 10:34 AM Barney Stratford < barney_stratf...@fastmail.fm> wrote: > > 1. Does t = target(...) start the thread? I think it does. > I think it does too. In the commonest use case, immediately after creating > a thread, you start it. And if you want to delay the thread but

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

> On Apr 26, 2022, at 3:05 PM, Thomas Kehrenberg wrote: > >  > Apr 26, 2022 20:32:55 Eric V. Smith : > >> How would runtime consumers of annotations use this? >> >> -- >> Eric >> >>>> On Apr 26, 2022, at 12:05 PM, Thomas K

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

How would runtime consumers of annotations use this? -- Eric > On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg wrote: > > If the problem is mostly type annotations, then another potential > solution would be to make use of .pyi files, which are not hamstrung by > circular definitions. The

[Python-Dev] New functionality for unittest.mock side_effect

I often want a side_effect of "if called with foo, return bar" functionality. This is really useful when the order of calls to your mock is indeterminate, so you can't just use an iterable. What I end up doing is writing a little function: def f(x): data = { 'foo':

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/25/2022 9:13 PM, Mehdi2277 wrote: We could have forward part include all of method signatures/attributes which is what a type checker needs. In theory we could do, forward class Foo: x: int y: list[str] def __init__(self, ...) def process(self, data: list[float]) ->

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/25/2022 1:10 PM, Jim J. Jewett wrote: (That said, my personal opinion is that this is pretty heavyweight for very little gain; why not just create a placeholder class that static analysis tools are supposed to recognize as likely-to-be-replaced later? And why not just use strings

[Python-Dev] Re: What is Modules/rotatingtree.c for?

On Sun, Apr 24, 2022 at 9:24 AM Patrick Reader <_...@pxeger.com> wrote: > I've just noticed Modules/rotatingtree.{h,c}, which don't seem to be > used anywhere. Are they just dead code? If so, is there a reason they > haven't been removed? > grep -R rotatingtree ; grep -R _lsprof rotatingtree is

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote: What's the use case for arbitrary expressions vs. a (possibly qualified) name? A class factory that produces forward declarations? Do you have a use case in mind? It's: x.py: --8< forward class A() --8< x_impl.py

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/2022 9:55 AM, Jelle Zijlstra wrote: However, it doesn't solve the problem for base classes. For example, str is conceptually defined as `class str(Sequence["str"]):`. A forward reference can't make `str` defined when the bases are evaluated, because bases are resolved at the `forward

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/2022 3:28 AM, Tobias HT wrote: On the other hand, there's something I've been seeing around. I don't know if it was introduced by Mypy or something, but its the use of declaration files. I think they are saved as pyi files. They just have the declaration of a python object, be it

[Python-Dev] Re: Updating inspect APIs

Things like os.stat_result use PyStructSequence_NewType, which is the C equivalent of a namedtuple. But a Struct Sequence has the extension of being able to have more named fields than the tuple length. It was designed, so I understand, just for cases like this. I don't know if it would be

[Python-Dev] Re: Proposal to deprecate mailcap

+1 add it to the 3.11 deprecations and proactively reach out to the mitmproxy owners. (internal code search: aside from mitmproxy I only see a _single_ use of this in our codebase and it was simply convenient but has a clear simpler alternative assuming that ~2008 era code is even still in use)

[Python-Dev] Re: PEP 678: Enriching Exceptions with Notes

On Thu, Jan 27, 2022 at 10:10 AM Zac Hatfield Dodds < zac.hatfield.do...@gmail.com> wrote: > Hi all, > > I've written PEP 678, proposing the addition of a __note__ attribute > which can be used to enrich displayed exceptions. This is particularly > useful with ExceptionGroup, or where exception

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

On 4/9/2022 4:28 PM, Terry Reedy wrote: On 4/9/2022 5:09 AM, Arfrever Frehtes Taifersar Arahesis wrote: Not only deletion, but also random assignments: Ok.  Change "Manual deletion of entries from sys.modules" to "Direct manipulation of sys.modules" I'm not sure it's worth the hassle to

[Python-Dev] Re: About PEPs being discussed on Discourse

On Thu, Apr 7, 2022 at 4:31 PM Jean Abou Samra wrote: > > I'm only a lurker here, but find the split between this mailing list > and various Discourse categories a little confusing from the outside. > As far as I understand, the Discourse server was originally an experiment. > Today, it has

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On Fri, Apr 1, 2022 at 2:06 AM Victor Stinner wrote: > Hi, > > Update on this issue: I merged my 2 PRs. > https://bugs.python.org/issue46850 > > The following APIs have been moved to the internal C API: > > - _PyFrameEvalFunction type > - _PyInterpreterState_GetEvalFrameFunc() > -

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

On 3/29/2022 4:55 PM, Skip Montanaro wrote: I was trying to think through how a "remote" stdlib might work. In the process, I got to wondering if there are known "specialists" for various current modules. Every now and then I still get assigned (or at least made nosy) about something to do

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

ittest/runner.py#L46 > > On Sun, Mar 27, 2022 at 2:42 PM Gregory P. Smith wrote: > >> For many of us, this isn't a nuisance. It is a desirable feature. >> >> test_xxx functions and methods typically don't have docstrings at all as >> the majority of tests tend to b

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

For many of us, this isn't a nuisance. It is a desirable feature. test_xxx functions and methods typically don't have docstrings at all as the majority of tests tend to be concise and obvious with the function name itself describes what its purpose is. When we added printing the docstring, it

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

> On Mar 27, 2022, at 11:20 AM, Eric V. Smith wrote: > >  > On 3/27/2022 10:51 AM, Jelle Zijlstra wrote: >> >> >> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () >> escribió: >>> >>> Any thoughts on the mentioned solutions? >>

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

On 3/27/2022 10:51 AM, Jelle Zijlstra wrote: El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () escribió: Any thoughts on the mentioned solutions? This is a bit more out there, but can anyone explain why we show the docstring at all? As far as I can tell it causes a bunch of confusion

[Python-Dev] Accepting PEP 655 - Marking individual TypedDict items as required or potentially-missing

On behalf of the Python Steering Council, we are pleased to accept PEP 655 - Marking individual TypedDict items as required or potentially-missing . Thanks for considering the potential for confusion with Optional during the design and recommending best

[Python-Dev] Accepting PEP 675 - Arbitrary Literal String Type

On behalf of the Python Steering Council, we are accepting PEP 675 - Arbitrary Literal String Type . TL;DR - PEP 675 allows type checkers to help prevent bugs allowing attacker-controlled data to be passed to APIs that declare themselves as requiring literal,

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

On 3/18/2022 4:58 PM, Guido van Rossum wrote: On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan wrote: On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote: The motivation has been explained already. In this thread? Yes, Eric's message. What on earth did your test do that

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

On 3/18/2022 10:01 AM, Ronald Oussoren via Python-Dev wrote: On 18 Mar 2022, at 14:37, Joao S. O. Bueno wrote: IMO this is a purism that have little, if any place in language restrictions. I see that not allowing. "run once" iterables could indeed void attempts to write "deliberatly non

[Python-Dev] Re: New PEP website is horrible to read on mobile device

On 3/16/2022 11:23 AM, Skip Montanaro wrote: Dang auto-correct... I meant "anti-tracking," in case it wasn't obvious. It wasn't obvious! I was wondering what nefarious entity had created an anti-teaching VPN, and just what that would involve. Thanks for clarifying! Eric

[Python-Dev] Re: Need Help

The embedded copy of expat was recently upgraded to 2.4.6 in https://bugs.python.org/issue46794 including on the 3.9 branch. That will wind up in 3.9.11 per https://www.python.org/dev/peps/pep-0596/. If you are using 3.9.5 you may also have a host of other potential security issues that updating

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

On Thu, Feb 24, 2022 at 3:27 PM Victor Stinner wrote: > On Thu, Feb 24, 2022 at 11:10 PM Barry wrote: > > > "Python 3.11 and newer versions use C11 without optional features. The > > > public C API should be compatible with C++." > > > https://github.com/python/peps/pull/2309/files > > > >

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Rejection notice.

it as *attempting* not to accumulate too many ways to do the same thing in the long term. If the 677 proposed syntax had been expanded to include more def features instead of being conservative I think it would've been an even easier rejection for many of us as that would've triggered more "point 4&

[Python-Dev] PEP 677 (Callable Type Syntax): Rejection notice.

Thank you PEP authors for producing a very well written and laid out PEP. That made it easy to understand the proposal, rationale, and alternatives considered. We agree that the existing typing.Callable syntax, while capable, is less than ideal for humans. That said, we deliberated last week and

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

On Wed, Feb 9, 2022 at 8:54 AM 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) > > > PyObject_TypeCheck(_PyObject_CAST(ob),

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

On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote: > On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote: > > > - Should we require IEEE 754 floating-point for > CPython-the-implementation? > > - Should we require IEEE 754 floating-point for Python-the-language? > > If the answer

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

On Tue, Feb 8, 2022 at 2:25 PM Steven D'Aprano wrote: > On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote: > > > CPython: yes. we use a double. > > Python the language: no. (float is single precision on many micropython > > platforms as it saves prec

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

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 assertion enabled CPython builds being the norm during development (we

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

On Mon, Feb 7, 2022 at 4:52 PM Christopher Barker wrote: > From the perspective of some that writes a lot of computational code: > > On Mon, Feb 7, 2022 at 10:25 AM Mark Dickinson wrote: > >> - Should we require the presence of NaNs in order for CPython to build? >> - Should we require IEEE 754

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

On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner wrote: > Hi Mark, > > Aha, good, you posted an email to python-dev, good :-) Last days, I > was trying to collect more data about this topic, especially find > platforms which *don't* support IEEE 754, before posting to > python-dev. > > Nowadays,

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On Sun, Feb 6, 2022 at 9:13 AM Paul Moore wrote: > On Sun, 6 Feb 2022 at 16:51, Christian Heimes > wrote: > > > The urllib package -- and to some degree also the http package -- are > > constant source of security bugs. The code is old and the parsers for > > HTTP and URLs don't handle edge

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

On 2/3/2022 12:15 PM, Victor Stinner wrote: I'm working bottom-to-top: prepare PyObject and PyVarObject to become opaque, *and* top-to-bottom: prepare subclasses (structures "inheriting" from PyObject and PyVarObject) to become opaque like PyFrameObject. IMO if PyObject* becomes a handle, the

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

On Wed, Feb 2, 2022 at 2:48 PM Eric Snow wrote: > I'm planning on moving us to a simpler, more efficient alternative to > _Py_IDENTIFIER(), but want to see if there are any objections first > before moving ahead. Also see https://bugs.python.org/issue46541. > > _Py_IDENTIFIER() was added in

[Python-Dev] Re: [Steering-council] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

-cc: python-steering-council On Fri, Mar 5, 2021 at 4:26 PM Guido van Rossum wrote: > On Fri, Mar 5, 2021 at 11:11 AM Brett Cannon wrote: > >> Speaking for myself ... >> > > Ditto ... > > On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon wrote: >> [...] >> >>> In some cases, the PEP would have

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

On Sat, Jan 29, 2022 at 7:38 PM Inada Naoki wrote: > On Sun, Jan 30, 2022 at 12:03 PM Ethan Smith wrote: > > > > As a non-committer, I want to make a plea for non-committer approval > reviews, or at least that they have a place. When asked how outsiders can > contribute I f

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

As a non-committer, I want to make a plea for non-committer approval reviews, or at least that they have a place. When asked how outsiders can contribute I frequently see "review open PRs" as a suggested way of contributing to CPython. Not being able to approve PRs that are good would be a barrier

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

On Thu, Jan 20, 2022 at 8:16 PM Dan Stromberg wrote: > > On Fri, Apr 16, 2021 at 11:13 AM Christian Heimes > wrote: > >> On 16/04/2021 19.14, redrad...@gmail.com wrote: >> > My personal stop of contributing in CPython is that it is written in >> pure C !! >> > I wrote code in both: pure C and

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

On Tue, Jan 18, 2022 at 6:24 AM 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: Request to revert unittest and configparser incompatible changes in Python 3.11

On Tue, Jan 18, 2022 at 10:58 PM Christopher Barker wrote: > On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon wrote: > >> I remember that "noisy by default" deprecation warnings were widely >>> despised. >>> >>> One thought, what if they were off by default UNLESS you were doing unit >>> tests?

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

On Sun, Jan 16, 2022 at 1:51 PM Mark Dickinson wrote: > On Sun, Jan 16, 2022 at 9:28 PM Guido van Rossum wrote: > >> Does the optimization for //10 actually help in the real world? [...] >> > > Yep, I don't know. If 10 is *not* the most common small divisor in real > world code, it must at

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

On Fri, Jan 14, 2022 at 9:50 AM Mark Dickinson wrote: > On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote: > >> Division may still be problematic. >> > > On that note: Python divisions are somewhat crippled even on x64. Assuming > 30-bit digits, the basic building block that's needed for

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

On 1/11/2022 3:44 PM, Brett Cannon wrote: On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith wrote: On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum wrote: I personally think F-strings should not be usable as docstrings. If you want a dynamically calculated

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

a linter for *all* of these dynamic situations that don't wind up populating __doc__. -gps > > On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou wrote: > >> On Tue, 11 Jan 2022 10:58:03 -0500 >> "Eric V. Smith" wrote: >> > Constant f-strings (those without sub

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

Constant f-strings (those without substitutions) as doc strings used to work, since the compiler turns them into normal strings. I can't find exactly where it was removed, but there was definitely discussion about it. See https://bugs.python.org/issue28739 for at least part of the discussion.

[Python-Dev] Re: About vulnerabilities in Cpython native code

This is also at https://bugs.python.org/issue46280. Please direct comments there. Eric On 1/6/2022 8:22 AM, lxr1210--- via Python-Dev wrote: Hi all, I am currently doing some research on the security of CPython. I used the open source vulnerability analysis engine,

[Python-Dev] Re: Sanity check about ctypes

On Wed, Jan 5, 2022 at 3:17 PM Yonatan Zunger wrote: > Hey everyone. > > Quick sanity check: The ctypes docs > refer to > _CData as a non-public class which is in the module, but _ctypes.c doesn't > actually export it >

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

Tue, Jan 4, 2022 at 10:59 AM Antoine Pitrou wrote: > >> 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

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

On Sun, Jan 2, 2022 at 2:37 AM Mark Dickinson wrote: > On Sat, Jan 1, 2022 at 9:05 PM Antoine Pitrou wrote: > >> Note that ARM is merely an architecture with very diverse >> implementations having quite differing performance characteristics. [...] >> > > Understood. I'd be happy to see timings

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

Regarding ABI issues, I don't see anything obvious either. I was probably misremembering the potential marshal issue, which was addressed. struct _longobject (the implementation details behind the public PyLongObject typedef name) and the digit definition are excluded from Py_LIMITED_API. So per

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

On Thu, Dec 30, 2021 at 12:42 PM Gregory P. Smith wrote: > > On Thu, Dec 30, 2021 at 4:47 AM Mark Dickinson wrote: > >> tl;dr: I'd like to deprecate and eventually remove the option to use >> 15-bit digits in the PyLong implementation. Before doing so, I'd like to >&g

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

On Thu, Dec 30, 2021 at 4:47 AM Mark Dickinson wrote: > tl;dr: I'd like to deprecate and eventually remove the option to use > 15-bit digits in the PyLong implementation. Before doing so, I'd like to > find out whether there's anyone still using 15-bit PyLong digits, and if > so, why they're

[Python-Dev] Re: issues-test-2 spam?

On 12/27/2021 12:43 PM, Zachary Ware wrote: On Mon, Dec 27, 2021 at 11:29 AM Matti Picus wrote: You may want to try the experiments in a private repo under your username rather than under the python organization. I think this will prevent anyone except you from getting notified. You could

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

e C API, but not for the stable C ABI -- that exports Py_None directly as a symbol. You also need a solution for all the static global PyTypeObjects in C extensions. I don't think there's any API-compatible way to make those heap-allocated. -n -- Nathaniel J. Smith -- https://vorpus.org _

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

ve-mode for a "+= 0". Which I guess is something you'd have to check empirically on every microarch and instruction pattern you care about, because there's no way it's documented. But maybe? CPUs are very smart, except when they aren't. -n -- Nathaniel J. Smith -- https://vorpus.org

[Python-Dev] Re: Python release announcement format

On Tue, Dec 14, 2021 at 9:06 AM Yann Droneaud wrote: > Hi, > > I'm not familiar with the Python release process, but looking at the latest > release > https://www.python.org/downloads/release/python-3101/ > > we can see MD5 is still used ... which doesn't sound right in 2021 ... > especially

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

Whoops, never mind, I see that you started the "immortal objects" thread to discuss this. On Tue, Dec 14, 2021 at 4:54 PM Nathaniel Smith wrote: > > How did you end up solving the issue where Py_None is a static global > that's exposed as part of the stable C ABI? > >

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

hon.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PNLBJBNIQDMG2YYGPBCTGOKOAVXRBJWY/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Nathaniel J. Smith -- http

[Python-Dev] Re: Should dataclasses add__set__ (and possibly __get __) descriptors ?

On 12/13/2021 1:43 AM, Vioshim wrote: Hello good morning. I've decided to open a discussion of a topic that I consider should be part of dataclasses, but not sure how suggestions work and many threads recommend to check python dev first so-. Anyways, at the moment that I write this message

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

Here's a use case for runtime type annotations: dataclasses use annotations to define fields. With the exception of ClassVar, the actual type is ignored. There's code in dataclasses.py to deal with stringized annotations, specifically just looking for ClassVar. I'd like to see this special

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

Python-Dev wrote: I am slightly surprised that it seems to be *easier* to fold selected constant expressions than to have more generic code to fold them all. Or at least, all those that don't contain containers, such as 1 in [0,1,2] Rob Cliffe On 28/11/2021 21:10,

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

> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka wrote: > > 28.11.21 17:13, Skip Montanaro пише: >>> That is not entirely true: >>> https://github.com/python/cpython/pull/29639#issuecomment-974146979 >> >> The only places I've seen "if 0:" or "if False:" in live code was for >> debugging.

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 11/14/2021 11:39 AM, Eric V. Smith wrote: For things that really are removed (and I won't get in to the reasons for why something must be removed), I think a useful stance is "we won't remove anything that would make it hard to support a single code base across all supported p

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 11/12/2021 5:55 AM, Petr Viktorin wrote: If deprecation now means "we've come up with a new way to do things, and you have two years to switch", can we have something else that means "there's now a better way to do things; the old way is a bit worse but continues to work as before"? I

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

On 11/12/2021 11:31 AM, Chris Angelico wrote: I think that proves the value of download counts: very little. The highest on the list is a thing called botocore, which I've never heard of. What is it? It's a dependency of a number of Amazon web services. My guess is that it's a dependency of

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

On Sun, Oct 10, 2021 at 7:25 AM 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 nums

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

ou try alternatives like that? If so, I assume they didn't work well -- can you give more details? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@pyth

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

On Sun, Oct 3, 2021 at 10:47 AM Łukasz Langa wrote: > > I know it's a bit late for bikeshedding this thing so if we want to be > conservative and stick to the current syntactical options already defined > in PEP 654, I'm voting Option 2 (given the awkwardness of the *(E1, E2) > example). > +1

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

On 9/28/2021 9:17 AM, Antoine Pitrou wrote: 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 frozen_modules=

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

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 frozen_modules=off" if they want to hack the stdlib for their greatest pleasure. I prefer that such special use case requi

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

On 9/28/2021 8:36 AM, Victor Stinner wrote: On Mon, Sep 27, 2021 at 6:58 PM 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

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

cadence. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at ht

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

't even out yet. So it's certainly possible to do, even for projects with a tiny fraction of Tensorflow's engineering budget. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send a

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

n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.p

[Python-Dev] Re: Changing exception text in micro releases

rote: On 9/24/2021 10:46 AM, Eric V. Smith wrote: > On 9/24/2021 10:39 AM, Ethan Furman wrote: >> On 9/24/21 6:51 AM, Eric V. Smith wrote: >> >> >> > This is clearly an improvement. My question is: is it okay to >> backport this to

[Python-Dev] Re: Changing exception text in micro releases

On 9/24/2021 10:39 AM, Ethan Furman wrote: On 9/24/21 6:51 AM, Eric V. Smith wrote: > This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I > think we have a rule that it's okay to change the exception text, but I'm not sure how that >

[Python-Dev] Changing exception text in micro releases

This PR https://github.com/python/cpython/pull/28310 changes the message for some exceptions. Currently: >>> format('', '%M') Traceback (most recent call last):   File "", line 1, in ValueError: Invalid format specifier With the proposed change: >>> format('', '%M') Traceback (most recent

[Python-Dev] Re: f-strings in the grammar

On 9/21/2021 7:15 PM, Guido van Rossum wrote: On Tue, Sep 21, 2021 at 4:08 PM Steve Dower <mailto:steve.do...@python.org>> wrote: On 9/21/2021 7:42 PM, Eric V. Smith wrote: > I don't recall exactly why, but I disallowed backslashes inside > expressions at the last mi

[Python-Dev] Re: f-strings in the grammar

To bring this back on track, I'll try and answer the questions from your original email. On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: I have started a project to move the parsing off-strings to the parser and the grammar. Appart from some maintenance improvements (we can drop a

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 11:19 AM, Terry Reedy wrote: On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: there are some interesting things we **could** (emphasis on could) get out of this and I wanted to discuss what people think about them. * The parser will allow nesting quote characters. This means

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 11:21 AM, Terry Reedy wrote: On 9/20/2021 8:46 AM, Serhiy Storchaka wrote: 20.09.21 14:18, Pablo Galindo Salgado пише: * The parser will likely have "\n" characters and backslashes in f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d",

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

I think we’re better off removing them. 2.7 is completely unsupported by us. Why do you think they should still be kept? -- Eric > On Aug 25, 2021, at 1:32 PM, Mike Miller wrote: > >  > How about moving Python 2 notes into a section at the bottom? > > > -Mike >

[Python-Dev] Re: PEP 667: Consistent views of namespaces

Just adding a datapoint, searching our internal codebase at work, I only found two things that I'd consider to be uses of PyEval_GetLocals() outside of CPython itself: https://github.com/earwig/mwparserfromhell/blob/develop/src/mwparserfromhell/parser/ctokenizer/tokenizer.c#L220

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

On Tue, Aug 10, 2021 at 3:48 PM Christopher Barker wrote: > On Tue, Aug 10, 2021 at 3:00 PM wrote: > >> The history of bytes/bytearray is a dual-purpose view. It can be used in >> a string-like way to emulate Python 2 string handling (hence all the usual >> string methods and a repr that

  1   2   3   4   5   6   7   8   9   10   >