[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: [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: [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: 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: 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: 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: 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: 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] 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: 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: 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: 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 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 docstring you should assign it dynamically, > not smuggle it in using a string-like expression. We don't allow "blah {x} >

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

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

xprNodes.py?l=397. I don't see anything obvious mentioning the limited API in that code generator. it'd be best to loop in Cython maintainers for more of an idea of Cython's intents and needs with PyCode_New APIs. I've cc'd cython-de...@python.org. -Greg > On Tue, Aug 17, 2021 at 8:51 AM Grego

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

Doing a search of a huge codebase (work), the predominant user of PyCode_New* APIs appears to be checked in Cython generated code (in all sorts of third_party OSS projects). It's in the boilerplate that Cython extensions make use of via it's __Pyx_PyCode_New macro.

[Python-Dev] Re: Does anyone use threading debug PYTHONTHREADDEBUG=1 env var? Can I remove it?

On Wed, Jul 7, 2021 at 2:28 AM Victor Stinner wrote: > Hi, > > Does anyone use threading debug PYTHONTHREADDEBUG=1 env var on a > Python debug build? If not, can I just remove it? > > -- > > To fix a race condition at thread exit on Linux using the glibc, I > removed calls to pthread_exit()

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

Overall agreement. Your list of ast and code objects and bytecode instructions are things that I'd _hope_ people already consider unstable so declaring them as such just makes sense if we're not doing that already. The ideal way to declare an API as unstable is to constantly change it in a

[Python-Dev] Re: GDB not breaking at the right place

On Tue, May 25, 2021 at 7:49 PM Inada Naoki wrote: > On Tue, May 25, 2021 at 5:38 AM Guido van Rossum wrote: > > > > To the contrary, I think if you want the CI jobs to be faster you should > add the CFLAGS to the configure call used to run the CI jobs. > > > > -Og makes it faster not only CI

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

On Tue, May 11, 2021 at 3:33 PM Mike Miller wrote: > > On 5/11/21 1:57 AM, Baptiste Carvello wrote: > > Le 11/05/2021 à 09:35, Steven D'Aprano a écrit : > >> On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote: > >> > >>> The vanilla interpreter could be updated to recognize when it is >

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

On Sun, May 9, 2021 at 9:13 AM Antoine Pitrou wrote: > 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

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

On Sat, May 8, 2021 at 2:40 PM Jonathan Goble wrote: > On Sat, May 8, 2021 at 5:08 PM Pablo Galindo Salgado > wrote: > >> > Why not put in it -O instead? Then -O means lose asserts and lose >> fine-grained tracebacks, while -OO continues to also >> strip out doc strings. >> >> What if someone

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

On Sat, May 8, 2021 at 2:09 PM Pablo Galindo Salgado wrote: > > Why not put in it -O instead? Then -O means lose asserts and lose > fine-grained tracebacks, while -OO continues to also > strip out doc strings. > > What if someone wants to keep asserts but do not want the extra data? > exactly

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

will cause crashes when reading pyc > files produced by the interpreter compiled without the flag. > I don't think the optional existence of column number information needs a different kind of pyc file. Just a flag in a pyc file's header at most. It isn't a new type of file. > On Sat, 8 May

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

On Sat, May 8, 2021 at 11:58 AM Pablo Galindo Salgado wrote: > Hi Brett, > > Just to be clear, .pyo files have not existed for a while: >> https://www.python.org/dev/peps/pep-0488/. > > > Whoops, my bad, I wanted to refer to the pyc files that are generated > with -OO, which have the "opt-2"

[Python-Dev] Re: a name for the ExceptHandler.type when it is a literal tuple of types

On Sat, May 8, 2021 at 8:54 AM Thomas Grainger wrote: > That's this bit: > > ``` > except (A, B): >^^ > ``` > > bpo-43149 currently calls it an "exception group", but that conflicts with > PEP 654 -- Exception Groups and except* > > ``` > >>>> try: >... pass >

[Python-Dev] Re: Speeding up CPython

On Fri, May 7, 2021 at 6:51 PM Steven D'Aprano wrote: > On Tue, Oct 20, 2020 at 01:53:34PM +0100, 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

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

On Fri, May 7, 2021 at 3:24 PM Pablo Galindo Salgado wrote: > Thanks a lot Gregory for the comments! > > An additional cost to this is things that parse text tracebacks not >> knowing how to handle it and things that log tracebacks >> generating additional output. > > We should provide a way for

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

On Fri, May 7, 2021 at 2:50 PM Pablo Galindo Salgado wrote: > Hi there, > > We are preparing a PEP and we would like to start some early discussion > about one of the main aspects of the PEP. > > The work we are preparing is to allow the interpreter to produce more > fine-grained error messages,

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

On Fri, May 7, 2021 at 3:01 PM Larry Hastings wrote: > On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote: > > Given that column numbers are not very big compared with line numbers, we > plan to store these as unsigned chars > or unsigned shorts. We ran some experiments over the standard library and

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

When reading this, I wrote most of it early and left a draft to bake Then deleted a ton of it after other people replied. I'm conscious that my terminology might be all over the map. Keep that in mind before hitting reply. It'll take me a while to digest and pedantically use Luciano's terms,

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

On Sat, Apr 3, 2021 at 7:49 PM Terry Reedy wrote: > On 4/3/2021 7:15 PM, Miro Hrončok wrote: > > On 03. 04. 21 21:44, Łukasz Langa wrote: > >> The memory layout of PyThreadState was unintentionally changed in the > >> recent 3.9.3 bugfix release. This leads to crashes on 32-bit systems > >> when

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

On Thu, Mar 25, 2021 at 11:58 AM Mark Shannon wrote: > Hi Victor, > > I'm with you 100% on not returning borrowed references, doing so is just > plain dangerous. > > However, is a blanket ban on stealing references the right thing? > > Maybe the problem is the term "stealing". > The caller is

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On Sun, Feb 21, 2021 at 12:03 PM Michał Górny wrote: > On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote: > > On 21/02/2021 13.13, Victor Stinner wrote: > > > Hi, > > > > > > I propose to actively remove support for *legacy* platforms and > > > architectures which are not supported by

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes wrote: > On 21/02/2021 13.47, glaub...@debian.org wrote: > > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 > platforms. There is no separate configure guard. All platforms that Rust > can build for, are always enabled by

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

(there's a small TL;DR towards the end of my reply if you want to read in reverse to follow my thought process from possible conclusions to how i got there - please don't reply without reading the whole thing first) *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return annotation

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

My primary reaction seems similar to Mark Shannon's. When I see this code: def is_str_list(val: List[object]) -> TypeGuard[List[str]]: ... I cannot tell what it returns. There is no readable indication in that this returns a boolean so the reader cannot immediately see how to use the

[Python-Dev] Re: Security releases of CPython

On Thu, Feb 11, 2021 at 8:29 PM Terry Reedy wrote: > On 2/11/2021 3:23 PM, Michał Górny wrote: > > Hello, > > > > I'm the primary maintainer of CPython packages in Gentoo. I would like > > to discuss possible improvement to the release process in order to > > accelerate releasing security fixes

[Python-Dev] Re: Why aren't we allowing the use of C11?

On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis wrote: > > > - Original Message - > > From: "Mark Shannon" > > To: "Python Dev" > > Sent: Thursday, January 28, 2021 5:26:37 PM > > Subject: [Python-Dev] Why aren't we allowing the use of C11? > > > > Hi everyone, > > > > PEP 7

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

My take on this is to keep it simple for CPython: Require the newer version of Sphinx on all branches we backport docs changes to. We, the CPython project, determine the exact version(s) of Sphinx a documentation build for a given version of CPython requires. If Sphinx has unfortunately made a

[Python-Dev] Re: unittest of sequence equality

Numpy chose to violate the principal of equality by having __eq__ not return a bool. So a numpy type can't be used reliably outside of the numpy DSL. -gps On Tue, Dec 22, 2020, 11:51 AM Alan G. Isaac wrote: > Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean > values). >

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

As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1? Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network? Yes, that means some very old

[Python-Dev] Re: __future__ annotations loses closure scope

What is the utility of a type annotation when the thing it refers to cannot exist? Deferred annotation lookups are intended to be something that analysis time can make sense of but can always have no useful meaning at runtime. No nesting required: ``` from __future__ import annotations Class X:

[Python-Dev] Re: nanosecond stat fields, but not os.path methods ?

If the precision is available via OS APIs, this is mostly an issue+PR away from being implemented by someone who cares. FAT32 has a two billion nanosecond resolution IIRC. :P -gps On Mon, Dec 7, 2020 at 8:22 AM David Mertz wrote: > Are there any filesystems that can actually record a

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

On Fri, Oct 30, 2020 at 2:30 PM Garrett D'Amore via Python-Dev < python-dev@python.org> wrote: > I’m not on this list. But I have offered to help - if there are tasks > that need to be done to help this I can help put the weight of a commercial > entity behind it whether that involves assigning

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

On Fri, Oct 30, 2020 at 1:14 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > FWIW, when the tracker issue landed with a PR, I became concerned that it > would be applied without further discussion and without consulting users. An issue and a PR doesn't simply mean "it is

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

On Fri, Oct 30, 2020 at 11:03 AM Brett Cannon wrote: > > On Fri, Oct 30, 2020 at 6:37 AM Pablo Galindo Salgado > wrote: > >> >Two volunteer core developers and at least one buildbot would help a >> > lot to ensure that Python is working on Solaris for real, and reduce >> > the number of open

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

On Fri, Oct 30, 2020 at 8:26 AM Sebastian Wiedenroth wrote: > Hi, > > I've already commented on the issue, but want to make a few more points > here as well. > > Removing Solaris support would not only impact Oracle Solaris but the open > source illumos community as well. > Both systems share

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

I agree, remove Solaris support. Nobody willing to contribute seems interested. -gps -- blame half the typos on my phone. On Thu, Oct 29, 2020, 2:50 PM Victor Stinner wrote: > Hi, > > I propose to drop the Solaris support in Python to reduce the Python > maintenance burden: > >

[Python-Dev] Re: os.scandir bug in Windows?

On Mon, Oct 26, 2020, 4:06 PM Chris Angelico wrote: > On Tue, Oct 27, 2020 at 10:00 AM Greg Ewing > wrote: > > > > On 27/10/20 8:24 am, Victor Stinner wrote: > > > I would > > > rather want to kill the whole concept of "access" time in operating > > > systems (or just configure the OS to not

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 4:04 PM Greg Ewing wrote: > A concern I have about this is what effect it will have on the > complexity of CPython's implementation. > > CPython is currently very simple and straightforward. Some parts > are not quite as simple as they used to be, but on the whole it's >

[Python-Dev] Re: Speeding up CPython

On Tue, Oct 20, 2020 at 5:59 AM 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 there

[Python-Dev] Re: os.scandir bug in Windows?

On Mon, Oct 19, 2020 at 6:28 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 19.10.2020 14:47, Steve Dower wrote: > > On 19Oct2020 1242, Steve Dower wrote: > >> On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: > >>> TLDR: In os.scandir directory entries, atime is always a

[Python-Dev] Re: os.scandir bug in Windows?

Could you please file this as an issue on bugs.python.org? Thanks! -Greg On Sat, Oct 17, 2020 at 7:25 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > > TLDR: In os.scandir directory entries, atime is always a copy of mtime > rather than the actual access time. > > Demo program:

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020 at 1:27 PM wrote: > September 15, 2020 4:02 PM, "Daniel Butler" > > wrote: > > > Users would be encouraged to try it but > > > NOT to publish code using it. > > Thinking out loud, macros could be enabled with a command line flag. > Advanced users would know how to use it

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Tue, Jul 28, 2020 at 2:12 PM Jim J. Jewett wrote: > ah... we may have been talking past each other. > > Steve Dower wrote: > > On 25Jul2020 2014, Jim J. Jewett wrote: > > > But it sounds as though you are saying the benefit > > [of storing the line numbers in an external table, I thought, >

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 5:19 AM Mark Shannon wrote: > > > On 21/07/2020 9:46 pm, Gregory P. Smith wrote: > > > > > > On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder > <mailto:n...@nedbatchelder.com>> wrote: > > > > https://www

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Tue, Jul 21, 2020 at 1:39 PM Gregory P. Smith wrote: > > On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado < > pablog...@gmail.com> wrote: > >> I like the proposal in general but I am against removing lnotab. The >> reason is that many tools rely on readin

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder wrote: > https://www.python.org/dev/peps/pep-0626/ :) > > --Ned. > > On 7/17/20 10:48 AM, Mark Shannon wrote: > > Hi all, > > > > I'd like to announce a new PEP. > > > > It is mainly codifying that Python should do what you probably already > >

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado wrote: > I like the proposal in general but I am against removing lnotab. The > reason is that many tools rely on reading this attribute to figure out the > Python call stack information. For instance, many sampler profilers read > this

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Fri, Jun 26, 2020 at 6:42 AM Mark Shannon wrote: > > > Let us start from some anecdotal evidence: isinstance() is one of the > most called functions in large scale Python code-bases (by static call > count). In particular, when analyzing some multi-million line production > code base, it was

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Litmus test: Give someone who does not know Python this code example from the PEP and ask them what it does and why it does what it does: match get_shape(): case Line(start := Point(x, y), end) if start == end: print(f"Zero length line at {x}, {y}") I expect confusion to be the

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > it is hard to make a decision between the pros and cons, > > when the pros are in a single formal document and the > > cons are scattered across the internet. > > Mark, I support your idea. It is natural

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 7:58 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Ethan Furman writes: > > > _ does not bind to anything, but of what practical importance is that? > > *sigh* English speakers ... mutter ... mutter ... *long sigh* > > It's absolutely essential to

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 7:34 PM Taine Zhao wrote: > > e.g., "or", and then I wonder "what does short-circuiting have to do > > with it?". All reuse of symbols carries baggage. > > "or" brings an intuition of the execution order of pattern matching, just > like how people already know about

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 1:38 PM Luciano Ramalho wrote: > Thank you Guido, Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin > for this fun and very useful new feature. > > I do enjoy pattern matching a lot in Elixir—my favorite language these > days, after Python. > > I don't want to start a

[Python-Dev] Re: New optional dependency

On Tue, Jun 23, 2020 at 7:41 AM Elisha Paine wrote: > Hi all, > > I am looking at getting TkDND support into tkinter, and have created > issue40893. However, we are currently considering the practicalities of > adding a new optional dependency to Python and I was hoping someone > could help

  1   2   3   4   5   6   7   >