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

2021-08-23 Thread Gregory P. Smith
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

2021-08-22 Thread Gregory P. Smith
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

2021-08-17 Thread Gregory P. Smith
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

2021-08-17 Thread Gregory P. Smith
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?

2021-07-07 Thread Gregory P. Smith
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"

2021-06-03 Thread Gregory P. Smith
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

2021-05-25 Thread Gregory P. Smith
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

2021-05-11 Thread Gregory P. Smith
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

2021-05-09 Thread Gregory P. Smith
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

2021-05-08 Thread Gregory P. Smith
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

2021-05-08 Thread Gregory P. Smith
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

2021-05-08 Thread Gregory P. Smith
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

2021-05-08 Thread Gregory P. Smith
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

2021-05-08 Thread Gregory P. Smith
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

2021-05-07 Thread Gregory P. Smith
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

2021-05-07 Thread Gregory P. Smith
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

2021-05-07 Thread Gregory P. Smith
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

2021-05-07 Thread Gregory P. Smith
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.

2021-04-23 Thread Gregory P. Smith
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

2021-04-03 Thread Gregory P. Smith
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

2021-03-26 Thread Gregory P. Smith
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

2021-02-21 Thread Gregory P. Smith
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

2021-02-21 Thread Gregory P. Smith
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

2021-02-14 Thread Gregory P. Smith
(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

2021-02-12 Thread Gregory P. Smith
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

2021-02-12 Thread Gregory P. Smith
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?

2021-01-28 Thread Gregory P. Smith
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?

2021-01-13 Thread Gregory P. Smith
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

2020-12-22 Thread Gregory P. Smith
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

2020-12-09 Thread Gregory P. Smith
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

2020-12-08 Thread Gregory P. Smith
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 ?

2020-12-07 Thread Gregory P. Smith
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

2020-10-30 Thread Gregory P. Smith
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

2020-10-30 Thread Gregory P. Smith
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

2020-10-30 Thread Gregory P. Smith
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

2020-10-30 Thread Gregory P. Smith
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

2020-10-29 Thread Gregory P. Smith
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?

2020-10-26 Thread Gregory P. Smith
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

2020-10-21 Thread Gregory P. Smith
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

2020-10-20 Thread Gregory P. Smith
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?

2020-10-19 Thread Gregory P. Smith
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?

2020-10-17 Thread Gregory P. Smith
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.

2020-09-15 Thread Gregory P. Smith
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.

2020-07-29 Thread Gregory P. Smith
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.

2020-07-22 Thread Gregory P. Smith
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.

2020-07-21 Thread Gregory P. Smith
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.

2020-07-21 Thread Gregory P. Smith
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.

2020-07-21 Thread Gregory P. Smith
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

2020-06-26 Thread Gregory P. Smith
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

2020-06-25 Thread Gregory P. Smith
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

2020-06-25 Thread Gregory P. Smith
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

2020-06-25 Thread Gregory P. Smith
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

2020-06-25 Thread Gregory P. Smith
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

2020-06-25 Thread Gregory P. Smith
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

2020-06-23 Thread Gregory P. Smith
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

[Python-Dev] Re: Can we stop adding to the C API, please?

2020-06-03 Thread Gregory P. Smith
On Wed, Jun 3, 2020 at 2:13 PM Victor Stinner wrote: > Le mer. 3 juin 2020 à 19:17, Mark Shannon a écrit : > > > I also *added* a bunch of *new* "getter" or "setter" functions to the > > > public C API for my project of hiding implementation details, like > > > making structures opaque: > > >

[Python-Dev] Re: Map errno==ETIME to TimeoutError

2020-05-24 Thread Gregory P. Smith
Sounds like a natural fit, I'd just do it for 3.10. On Sun, May 24, 2020, 9:45 AM Eric V. Smith wrote: > Does anyone have an opinion on https://bugs.python.org/issue39673? It > maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT. > >

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-20 Thread Gregory P. Smith
On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett wrote: > David Mertz wrote: > > > Fwiw, I don't think it changes my order, but 'strict' is a better word > than > > 'equal' in all those places. I'd subtract 0.1 from each of those votes if > > they used "equal". > > I would say that 'equal' is

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-15 Thread Gregory P. Smith
On Fri, May 15, 2020 at 11:55 AM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > I'll join in with the fun... > > zip(strict=True) +1 > itertools.zip_strict() +0 > Agreed. The best way to reduce accidental incorrect use of the builtin is to make the builtin capable of doing what a

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

2020-05-07 Thread Gregory P. Smith
On Wed, May 6, 2020 at 1:14 PM Serhiy Storchaka wrote: > 06.05.20 00:46, Victor Stinner пише: > > Subinterpreters and multiprocessing have basically the same speed on > > this benchmark. > > It does not look like there are some advantages of subinterpreters > against multiprocessing. > There is

[Python-Dev] Re: Remove ctypes from uuid

2020-05-04 Thread Gregory P. Smith
On Mon, May 4, 2020 at 9:45 AM Steve Dower wrote: > For those who haven't looked in a while, the uuid module uses ctypes to > look up libuuid for uuid_generate_time_safe() and uuid_generate_time() > functions. > > I've run into scenarios where I need to remove this from our own builds, > but it

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

2020-04-29 Thread Gregory P. Smith
On Wed, Apr 29, 2020 at 5:40 AM Julien Salort wrote: > Le 29/04/2020 à 03:18, Eric Snow a écrit : > > > My (honest) question is, how many folks using subinterpreters are > > going to want to use numpy (or module X) enough to get mad about it > > before the extension supports subinterpreters?

[Python-Dev] Re: PEP 617: New PEG parser for CPython

2020-04-21 Thread Gregory P. Smith
On Tue, Apr 21, 2020 at 9:35 PM Gregory P. Smith wrote: > Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can > get it out of the stdlib by 3.11 or 3.12? > I'm going ahead and tracking the idea in https://bugs.python.org/issue40360. > > lib2to3 is the bas

[Python-Dev] Re: PEP 617: New PEG parser for CPython

2020-04-21 Thread Gregory P. Smith
Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can get it out of the stdlib by 3.11 or 3.12? lib2to3 is the basis of all sorts of general source code manipulation tooling. Its name and original reason d'etre have moved on. It is actively used to parse and rewrite Python

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

2020-04-21 Thread Gregory P. Smith
On Tue, Apr 21, 2020 at 10:49 AM Antoine Pitrou wrote: > On Tue, 21 Apr 2020 18:46:04 +0200 > Petr Viktorin wrote: > > On 2020-04-21 11:01, Antoine Pitrou wrote: > > > On Mon, 20 Apr 2020 19:21:21 -0600 > > > Eric Snow wrote: > > >> Honest question: how many C extensions have process-global

[Python-Dev] Re: Improvement to SimpleNamespace

2020-04-15 Thread Gregory P. Smith
On Wed, Apr 15, 2020 at 7:37 AM Victor Stinner wrote: > Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger > a écrit : > > I would like to make that functionality available to the JSON module (or > just about anything else that accepts a custom dict) by adding the magic > methods for mappings so

[Python-Dev] Re: Improvement to SimpleNamespace

2020-04-15 Thread Gregory P. Smith
On Wed, Apr 15, 2020 at 12:49 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > First of all, be aware of the limitations of this approach (which will > need to be clearly documented if we go this way): > >- It only allows valid Python identifiers -- while JSON accepts any >

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

2020-03-24 Thread Gregory P. Smith
On Tue, Mar 24, 2020 at 11:55 AM Brett Cannon wrote: > -1 on "cut*" because my brain keeps reading it as "cute". > +1 on "trim*" as it is clear what's going on and no confusion with > preexisting methods. > +1 on "remove*" for the same reasons as "trim*". > > And if no consensus is reached in

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

2020-03-21 Thread Gregory P. Smith
Nice PEP! That this discussion wound up in the NP-complete "naming things" territory as the main topic right from the start/prefix/beginning speaks highly of it. :) The only things left I have to add are (a) agreed on don't specify if it is a copy or not for str and bytes.. BUT (b) do specify

[Python-Dev] Re: Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

2020-01-17 Thread Gregory P. Smith
for upgrading us to 3.9 so we'd simply make that happen at that time) -gps On Fri, Jan 17, 2020 at 11:09 AM Gregory P. Smith wrote: > +1 remove it to match that policy. I find it unlikely someone will ask > for it to be restored, but our first response before doing so should be to > see if

[Python-Dev] Re: Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

2020-01-17 Thread Gregory P. Smith
+1 remove it to match that policy. I find it unlikely someone will ask for it to be restored, but our first response before doing so should be to see if they can instead use it as a dependency via PyPI: Someone who wants to maintain it for future use can take 3.8 formatter module and put it

[Python-Dev] Re: Adding a scarier warning to object.__del__?

2020-01-01 Thread Gregory P. Smith
On Wed, Jan 1, 2020 at 6:40 AM Andrew Svetlov wrote: > __del__ is very useful not for interpreter shutdown but as a regular > destructor in object's lifecycle. > The reason we should warn people against ever implementing __del__ is that people rarely actually understand object lifecycle. Its

[Python-Dev] Re: sqlite3 module and thread-safe SQLite library

2019-12-17 Thread Gregory P. Smith
On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom wrote: > We ran into an issue where having the SQLite library built with > -DSQLITE_THREADSAFE=0, > but then the sqlite3 module (really, the _sqlite3.so0 crashing in > threading code. So I have > to ask if it is intended that the sqlite3 Python

[Python-Dev] Re: GitHub Actions enabled (was: Travis CI for backports not working)

2019-12-16 Thread Gregory P. Smith
On Mon, Dec 16, 2019 at 11:11 AM Steve Dower wrote: > On 13Dec2019 0959, Brett Cannon wrote: > > Steve Dower wrote: > >> If people are generally happy to move PR builds/checks to GitHub > >> Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7 > >> into > >> our active branches

[Python-Dev] Re: Handling cross-distro variations when running autoreconf?

2019-12-15 Thread Gregory P. Smith
I personally think we shouldn't worry about it. I *try* to use an autoconf version at least as recent as what was used for the current file, but beyond that it is unlikely anything depends on autoconf distroisms within our own in tree configure. Forcing humans to do weird tricks (always

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

2019-12-09 Thread Gregory P. Smith
My overall problem with the PEP and a reason I'd reject it by default it that it is asking to pre-emptively impose limits on things, some of which we believe would cause problems to existing long running applications (limiting the total number of types for example), without having actually

[Python-Dev] Re: PEP 611: The one million limit.

2019-12-06 Thread Gregory P. Smith
I'd prefer it if we stayed on topic here... On Fri, Dec 6, 2019 at 3:15 PM Chris Angelico wrote: > On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing > wrote: > > > > On 7/12/19 2:54 am, Rhodri James wrote: > > > > > You've talked some about not making the 640k mistake > > > > I think it's a bit unfair

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

2019-12-03 Thread Gregory P. Smith
On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon wrote: > Hi Everyone, > > I am proposing a new PEP, still in draft form, to impose a limit of one > million on various aspects of Python programs, such as the lines of code > per module. > > Any thoughts or feedback? > > The PEP: >

[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?

2019-11-27 Thread Gregory P. Smith
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon wrote: > Gregory P. Smith wrote: > > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon br...@python.org wrote: > > > Python 3.9 is going to be the first release which > > > will exist without any > > > Python 2.7

[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?

2019-11-26 Thread Gregory P. Smith
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon wrote: > Python 3.9 is going to be the first release which will exist without any > Python 2.7 overlap. Does this mean we are ready to start removing things > that have been deprecated since at least Python 3.7? PEP 4 says [we are in > the clear for

[Python-Dev] Re: Stalemate on bringing back PEP 523 support into Python 3.8

2019-11-22 Thread Gregory P. Smith
On Fri, Nov 22, 2019 at 10:10 AM Mark Shannon wrote: > Hi, > > On 21/11/2019 8:04 pm, Brett Cannon wrote: > > An unfortunate side-effect of making PyInterpreterState in Python 3.8 > opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) > support.

[Python-Dev] Re: What to do about invalid escape sequences

2019-08-09 Thread Gregory P. Smith
On Fri, Aug 9, 2019 at 11:37 AM Eric V. Smith wrote: > On 8/9/2019 2:28 PM, Jonathan Goble wrote: > > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: > >> I find the "Our deprecation warnings were even less visible than > >> normal" argument for extending the deprecation period compelling.

[Python-Dev] Re: What to do about invalid escape sequences

2019-08-09 Thread Gregory P. Smith
On Fri, Aug 9, 2019 at 8:43 AM Guido van Rossum wrote: > This discussion looks like there's no end in sight. Maybe the Steering > Council should take a vote? > I've merged the PR reverting the behavior in 3.8 and am doing the same in the master branch. The sheer volume of email this is

[Python-Dev] Re: What to do about invalid escape sequences

2019-08-06 Thread Gregory P. Smith
People distribute code via pypi. if we reject uploads of packages with these problems and link to fixers (modernize can be taught what to do), we prevent them from spreading further. A few years after doing that, we can revisit how much pain and for whom making this a SyntaxWarning or even

[Python-Dev] Re: What to do about invalid escape sequences

2019-08-06 Thread Gregory P. Smith
On Tue, Aug 6, 2019 at 10:06 AM Neil Schemenauer wrote: > > Making it an error so soon would be mistake, IMHO. That will break > currently working code for small benefit. When Python was a young > language with a few thousand users, it was easier to make these > kinds of changes. Now, we

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

2019-07-02 Thread Gregory P. Smith
On Mon, Jul 1, 2019 at 9:01 AM Steven D'Aprano wrote: > On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > > You have missed at least one: the minimum technology requirement for > > > using Github is a lot more stringent than for Roundup. Github's minimum > > > system

[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty

2019-06-07 Thread Gregory P. Smith
On Thu, Jun 6, 2019 at 6:19 AM Victor Stinner wrote: > Le jeu. 6 juin 2019 à 14:18, Steven D'Aprano a > écrit : > > i.e. 25-40% longer. Is there a shorter permalink form available, like > > goo.gl, bitly, youtu.be etc use? That would be awesome if we could use > > them instead. > > I really

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Gregory P. Smith
On Fri, May 24, 2019 at 1:48 PM Ezio Melotti wrote: > > On Fri, May 24, 2019, 20:23 Gregory P. Smith wrote: > >> -cc: committers to avoid crossposting. >> > > +1 (I wanted to include committers, since the announcement about PEP 581 > was posted there too, but it's

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

2019-05-24 Thread Gregory P. Smith
-cc: committers to avoid crossposting. I have feedback for roundup as experienced on BPO that should be represented within PEP 595 if we are going to have a summary of "improving roundup for BPO" captured in a PEP (presumably already rejected given 581? But good to have documented regardless so

Re: [Python-Dev] Have a big machine and spare time? Here's a possible Python bug.

2019-05-23 Thread Gregory P. Smith
I suggest filing a bug to track this... On Thu, May 23, 2019 at 10:13 AM Tim Peters wrote: > [Inada Naoki ] > > ... > > 2. This loop is cleary hot: > > > https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819 > > Which is 3 lines of code

Re: [Python-Dev] bpo-36829: Add sys.unraisablehook()

2019-05-16 Thread Gregory P. Smith
I like the feature, we should have it. It'll be useful for debugging and probably more. Which brings me to the annoying paint color question: These exceptions were most definitely raised. Thus the term "unraisable" is wrong. I believe you really mean "uncatchable". -gps On Thu, May 16, 2019 at

Re: [Python-Dev] Unicode identifiers in test files?

2019-05-03 Thread Gregory P. Smith
On Fri, May 3, 2019 at 10:46 PM Eric V. Smith wrote: > Is there a policy against using Unicode identifiers in test files? > > As part of adding !d to f-strings, there's a code path that's only > executed if the text of the expression is non-ascii. The easiest way to > exercise it, and the way I

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

2019-04-10 Thread Gregory P. Smith
On Wed, Apr 10, 2019 at 11:00 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 10.04.2019 7:30, Karthikeyan wrote: > > Thanks Gregory. I think it's a good tradeoff to ensure this validation > only for URLs of http scheme. > > I also agree handling newline is little

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

2019-04-09 Thread Gregory P. Smith
On Tue, Apr 9, 2019 at 4:45 PM Karthikeyan wrote: > I would recommend fixing it since it's potentially remote code execution > on systems like Redis (latest versions of Redis have this mitigated) though > I must admit I don't fully understand the complexity since there are > multiple issues

Re: [Python-Dev] Strange umask(?)/st_mode issue

2019-04-01 Thread Gregory P. Smith
On Mon, Apr 1, 2019 at 4:49 PM Cameron Simpson wrote: > On 01Apr2019 15:44, Steve Dower wrote: > >On 01Apr2019 1535, Cameron Simpson wrote: > >>On 01Apr2019 09:12, Steve Dower wrote: > >>>On 30Mar2019 1130, Gregory P. Smith wrote: > >>>>I wouldn't

Re: [Python-Dev] Strange umask(?)/st_mode issue

2019-03-30 Thread Gregory P. Smith
I wouldn't expect it to be the case in a CI environment but I believe a umask can be overridden if the filesystem is mounted and configured with acls set? (oh, hah, Ivan just said the same thing) -gps On Sat, Mar 30, 2019 at 9:05 AM Steve Dower wrote: > On 29Mar.2019 1944, Steve Dower wrote:

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-27 Thread Gregory P. Smith
of such a report. -G On Wed, Mar 27, 2019, 5:38 PM Tim Peters wrote: > [Gregory P. Smith ] > > ... > > A situation came up the other day where I believe this could've helped. > > > > Scenario (admittedly not one most environments run into): A Python > process &

[Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-27 Thread Gregory P. Smith
https://www.python.org/dev/peps/pep-0556/ This PEP is currently Deferred as nobody is actively working on a test implementation. A situation came up the other day where I *believe* this could've helped. Scenario (admittedly not one most environments run into): A Python process with a C++

Re: [Python-Dev] Best way to specify docstrings for member objects

2019-03-20 Thread Gregory P. Smith
(answers above and below the quoting) I like the idea of documenting attributes, but we shouldn't force the user to use __slots__ as that has significant side effects and is rarely something people should bother to use. There are multiple types of attributes. class and instance. but regardless

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

2019-03-19 Thread Gregory P. Smith
On Tue, Mar 19, 2019, 4:53 AM Ned Batchelder wrote: > On 3/19/19 4:13 AM, Serhiy Storchaka wrote: > > 19.03.19 00:41, Raymond Hettinger пише: > >> 4) Fix the tests in the third-party modules to be more focused on > >> their actual test objectives, the semantics of the generated XML > >> rather

  1   2   3   4   5   6   >