[Python-Dev] Re: Changing Python's string search algorithms

On Fri, 16 Oct 2020 20:24:22 -0500 Tim Peters wrote: > > Note that no "extra" storage is needed to exploit this. No character > lookups, no extra expenses in time or space of any kind. Just "if we > mismatch on the k'th try, we can jump ahead k positions". Ok, so that means that on a N-characte

[Python-Dev] Re: Speeding up CPython

On Tue, 20 Oct 2020 13:53:34 +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 five over the next few > years. But it needs funding. > > I am aware that t

[Python-Dev] Re: Speeding up CPython

On Tue, 20 Oct 2020 16:10:27 +0100 Mark Shannon wrote: > Hi Antoine, > > On 20/10/2020 2:32 pm, Antoine Pitrou wrote: > > On Tue, 20 Oct 2020 13:53:34 +0100 > > Mark Shannon wrote: > >> Hi everyone, > >> > >> CPython is slow. We all know that,

[Python-Dev] Re: Speeding up CPython

On Wed, 21 Oct 2020 12:49:54 +0200 Petr Viktorin wrote: > > Later, Mark says there is an even better way – or at least, a less > intrusive one! In [the second discussion], he hints at it vaguely (from > that limited info I have, it involves switching to C11 and/or using > compiler-specific ext

[Python-Dev] Re: Macro for logging

On Wed, 21 Oct 2020 14:19:37 +0200 Marco Sulla wrote: > If not already present, do you think it's useful to add a macro that does > something like > > # ifdef Py_DEBUG > fprintf(stderr, "%s\n", message); > # endif In general, you want to do this on a per-component basis, so each C source fil

[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)

On Wed, 21 Oct 2020 22:48:59 +1100 Chris Angelico wrote: > > Ah, cool, got it - thanks! My reading of this is that a good few of > the benchmarks are coming out firmly in PyPy's favour, but a number of > them are still in CPython's favour (including "telco" where PyPy is > staggeringly worse for

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

On Fri, 30 Oct 2020 09:34:37 + Pablo Galindo Salgado wrote: > Regarding having a Solaris buildbot: if someone provides a Solaris buildbot > then the deal is that that someone or some other party must look after that > buildbot and fix problems that appear in it in a timely manner. Broken > bui

[Python-Dev] Re: Speeding up CPython

Hello, On Wed, 4 Nov 2020 13:27:50 +0100 Thomas Wouters wrote: > > And it may not be immediately obvious from Mark's plans, but as far as we > can tell, the proposal is for speeding up pure-Python code. It will do > little for code that is hampered, speed-wise, by CPython's object model, or >

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On Mon, 23 Nov 2020 16:15:12 - "Brian Coleman" wrote: > > Furthermore, Python has a regular expression module which implements it's own > DSL for the purpose of matching string patterns. Regular expressions, in a > similar way to pattern matching, > allow string patterns to be expressed i

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

On Mon, 7 Dec 2020 16:19:02 + David Mertz wrote: > Are there any filesystems that can actually record a meaningful ns > modification time? I find discussions claiming this: > > - XFS and EXT3: second precision > - EXT4: millisecond precision > - NTFS: 100ns precision > - APFS: 1 ns precision

[Python-Dev] Re: SC 2020 recommendation for PEP 634

On Mon, 7 Dec 2020 11:29:55 -0800 Brett Cannon wrote: > After much deliberation, the 2020 SC will be making a recommendation to the > 2021 SC to accept PEP 634 (although this was not a unanimous decision). > This is in no way a binding recommendation to the 2021 SC (even if a > majority of current

[Python-Dev] Re: unittest of sequence equality

On Tue, 22 Dec 2020 19:32:15 + David Mertz wrote: > > If you know you might be dealing with NumPy arrays (as the import > suggests), I think it's simply right to spell it as: > > unittest.TestCase().assertTrue(np.array_equal([1., 2., 3.], np.array([1., > 2., 3.]))) Please don't suggest this

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, 28 Dec 2020 11:07:46 +0900 Inada Naoki wrote: > > Additionally, if we introduce the customizable lazy str object, it's > very easy to release GIL during basic Unicode operations. Many third > parties may assume PyUnicode_Compare doesn't release GIL if both > operands are Unicode objects.

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Tue, 29 Dec 2020 02:20:45 +0900 Inada Naoki wrote: > On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote: > > > > On Mon, 28 Dec 2020 11:07:46 +0900 > > Inada Naoki wrote: > > > > > > Additionally, if we introduce the customizable lazy str obje

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, 28 Dec 2020 14:27:00 +0100 Ronald Oussoren via Python-Dev wrote: > > On 28 Dec 2020, at 14:00, Inada Naoki wrote: > > > > On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson > > wrote: > >> > >> > >> I would have thought that an object was defined by its behaviour rather > >> than by any

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

On Sun, 3 Jan 2021 16:19:01 + Barry Scott wrote: > > > > I’ll also quote the example match statement from the PEP abstract, > > which extracts “host” and “port” details from a 2 item sequence, a > > mapping with “host” and “port” keys, any object with “host” and “port” > > attributes, or a “h

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On Sat, 9 Jan 2021 02:02:17 +0100 Victor Stinner wrote: > > It's an hard problem and I don't see any simple/obvious solution right > now, except of *workarounds* that I dislike. Maybe the only good > solution is to fix all heap types, one by one. Ok. Why are we adding heap types to the stdlib ex

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

On Sat, 9 Jan 2021 12:17:32 + Paul Moore wrote: > On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky wrote: > > > case {"host" as host, "port" as port}: > > > > There're 2 obvious problems with it: > > > > a) In Python, {} with things inside it, but no ":" inside it, is a set, > > set. > > b) Ev

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Le 09/01/2021 à 15:18, Paul Moore a écrit : > > But the PEP 642 form: > > case {"text" as message, "color" as c}: > > is essentially identical except for using "as" rather than a colon. My view > is: > > 1. Nowhere else in Python does "as" indicate a dictionary, and braces > alone don't (

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On Tue, 12 Jan 2021 15:22:36 +0100 Petr Viktorin wrote: > On 1/11/21 5:26 PM, Victor Stinner wrote: > > Hi, > > > > There are multiple PEPs covering heap types. The latest one refers to > > other PEPs: PEP 630 "Isolating Extension Modules" by Petr Viktorin. > > https://www.python.org/dev/peps/pep

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

On Tue, 12 Jan 2021 18:48:39 + Pablo Galindo Salgado wrote: > One worry that I have in general with this move > is the usage of _PyType_GetModuleByDef to get the type object > from the module definition. This normally involves getting a TLS in every > instance creation, > which can impact nota

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Fri, 15 Jan 2021 09:36:11 +0100 Julien Danjou wrote: > On Thu, Jan 14 2021, Tim Peters wrote: > > > I'm not clear on exactly what it is you're after, but CPython faces > > the same question all the time: _given_ a pointer to an object, is > > there, or is there not, a GC header prepended? Tha

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

Le 15/01/2021 à 13:08, Julien Danjou a écrit : > On Fri, Jan 15 2021, Antoine Pitrou wrote: > >> Also note that PyObject_Malloc() may also be used to allocate >> non-objects, for example a bytearray's payload, IIRC. > > Interesting. What's the rational fo

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On Mon, 18 Jan 2021 12:41:45 -0800 Chris Barker via Python-Dev wrote: > > And in "real world" code, I've done just this -- building a system for > saving / restoring dataclasses to/from JSON. In that case, each of the > dataclasses knows how to save itself and build itself from JSON-compatible >

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On Mon, 18 Jan 2021 15:54:32 -0800 Larry Hastings wrote: > On 1/18/21 3:42 PM, Inada Naoki wrote: > > Many type hinting use cases don't need type objects in runtime. > > So I think PEP 563 is better for type hinting user experience. > > You mean, in situations where the user doesn't want to imp

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: > Hi everyone, > > It's time for yet another PEP :) > > Fortunately, this one is a small one that doesn't change much. > It's aim is to make the VM more robust. On the principle, no objection. In practice, can you show how an implementatio

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 15:54:39 + Mark Shannon wrote: > On 19/01/2021 3:40 pm, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 13:31:45 + > > Mark Shannon wrote: > >> Hi everyone, > >> > >> It's time for yet another PEP :) > >> >

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 16:28:46 + Mark Shannon wrote: > On 19/01/2021 4:15 pm, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 15:54:39 + > > Mark Shannon wrote: > >> On 19/01/2021 3:40 pm, Antoine Pitrou wrote: > >>> On Tue, 19 Jan 2021 13:3

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Mon, 25 Jan 2021 14:03:22 +0100 Victor Stinner wrote: > > The list is opinionated and defined by its documentation: So "the list is opinionated" means there can be false negatives, i.e. some stdlib modules which are not present in this list? This will probably make life harder for third-part

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Tue, 26 Jan 2021 10:36:10 +1100 Steven D'Aprano wrote: > On Mon, Jan 25, 2021 at 06:17:09PM +0100, Victor Stinner wrote: > > Hi Bernat, > > > > "stdlib_module_names" was my first idea but it looks too long, so I > > chose "module_names". But someone on Twitter and now you asked me why > > not

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Mon, 25 Jan 2021 23:05:07 +0100 Victor Stinner wrote: > > This is a different use case which requires a different solution. > sys.module_names solve some specific use cases (that I listed in my > first email). > > In Python 3.9, you can already check if a module __file__ is in the > sysconfig

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Wed, 27 Jan 2021 11:05:28 +1100 Steven D'Aprano wrote: > On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote: > > On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote: > > [...] > > > Disagreed. This is niche enough that it warrants a long but exp

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

On Thu, 28 Jan 2021 16:26:37 + Mark Shannon wrote: > Hi everyone, > > PEP 7 says that C code should conform to C89 with a subset of C99 allowed. > It's 2021 and all the major compilers support C11 (ignoring the optional > parts). I think that CPython is supposed to compile on non-mainstream

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

On Fri, 29 Jan 2021 18:15:37 +0100 Victor Stinner wrote: > Hi Mark, > > I tried to use C11 _Thread_local (Thread Local Storage, TLS) only with > GCC and clang and I got issues on macOS: > https://github.com/python/cpython/pull/23976 > > My PR uses __thread if _Thread_local is not available. > >

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On Mon, 1 Feb 2021 17:39:16 +0100 "M.-A. Lemburg" wrote: > > They should not use Py_UNICODE. > > wchar_t is standard C and is in wide spread use in C code for > storing Unicode data. Do you have any data points about "wide spread use"? I work in C++ daily and don't see any "wide spread use" of

[Python-Dev] Re: Python standardization

On Fri, 12 Feb 2021 21:54:44 +0300 Ivan Pozdeev via Python-Dev wrote: > How a standard by ANSI, ECMA and/or ISO is any better than a standard by the > PSF? The PSF has nothing to do with it. The Python language is controlled by the core development team. I wouldn't be surprised if some members

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

On Mon, 22 Feb 2021 19:50:43 + Rob Boehne wrote: > > The other thing that crept into this thread was the mention of test that > intermittently fail. > That's a huge problem because it suggests that applications will sometimes > fail. > I have usually seen these sort of issues because of >

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

On Tue, 23 Feb 2021 16:45:27 + Rob Boehne wrote: > On 2/22/21, 4:06 PM, "Antoine Pitrou" wrote: > > On Mon, 22 Feb 2021 19:50:43 + > Rob Boehne wrote: > > > > The other thing that crept into this thread was the mention o

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Tue, 23 Feb 2021 20:29:52 -0500 Jonathan Goble wrote: > > I can't speak for distributors or maintainers [1], but I can speak for > myself as a user. I run Debian testing (currently bullseye as that is > preparing for release) as my daily OS on my personal laptop, used for > personal matters an

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

On Fri, 5 Mar 2021 15:03:59 + Mark Shannon wrote: > > There are two issues here. Portability and changes to behaviour. > > Regarding portability, I have to admit that PEP is rather vague. > That's my fault; I should have done more implementation first :( > FWIW, I have an implementation that

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

Hi Mark, Le 05/03/2021 à 18:06, Mark Shannon a écrit : Hi Antoine, On 05/03/2021 4:07 pm, Antoine Pitrou wrote: On Fri, 5 Mar 2021 15:03:59 + Mark Shannon wrote: There are two issues here. Portability and changes to behaviour. Regarding portability, I have to admit that PEP is rather

[Python-Dev] Re: Python history: origin of the arrow annotation

On Fri, 5 Mar 2021 16:45:25 -0800 Guido van Rossum wrote: > Good question. I don't think anyone has ever asked this before... Given the > variants you propose, I'd say that the 3-character ones would be more > effort to type without real benefits, and `=>` would at the time (and > perhaps still :

[Python-Dev] Re: Steering Council update for February

On Wed, 10 Mar 2021 10:30:43 +0900 Inada Naoki wrote: > On Wed, Mar 10, 2021 at 10:10 AM Ivan Pozdeev via Python-Dev > wrote: > > > > On 10.03.2021 3:53, Chris Angelico wrote: > > > On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw > > > wrote: > > >>> Does 'master' confuse people? > > >> There

[Python-Dev] Re: Steering Council update for February

On Wed, 10 Mar 2021 11:14:26 +0100 Christian Heimes wrote: > On 10/03/2021 10.30, Antoine Pitrou wrote: > > On Wed, 10 Mar 2021 10:30:43 +0900 > > Inada Naoki wrote: > >> On Wed, Mar 10, 2021 at 10:10 AM Ivan Pozdeev via Python-Dev > >> wrote: > >>

[Python-Dev] Re: New name for the development branch [was Steering Council update for February]

Indeed, if we change the name of the default branch, it should be something standard, so "main". Projects with non-standard branch names are pointlessly annoying to navigate. Regards Antoine. On Wed, 10 Mar 2021 13:47:11 +0300 Ivan Pozdeev via Python-Dev wrote: > I think > https://mail.pyt

[Python-Dev] Re: Steering Council update for February

On Wed, 10 Mar 2021 14:23:33 + David Mertz wrote: > > Renaming main branches as 'main' is currently predominant practice on > GitHub (and more broadly in Free Software communities). Python doesn't > need to cling to an old name based on a tired argument that political > sensitivity is a cree

[Python-Dev] Re: Steering Council update for February

On Wed, 10 Mar 2021 15:38:46 + MRAB wrote: > On 2021-03-10 15:17, Antoine Pitrou wrote: > > On Wed, 10 Mar 2021 14:23:33 + > > David Mertz wrote: > >> > >> Renaming main branches as 'main' is currently predominant practice on > >> G

[Python-Dev] Re: pth file encoding

On Tue, 16 Mar 2021 11:44:13 +0900 Inada Naoki wrote: > Hi, all. > > I found .pth file is decoded by the default (i.e. locale-specific) encoding. > https://github.com/python/cpython/blob/0269ce87c9347542c54a653dd78b9f60bb9fa822/Lib/site.py#L173 > > pth files contain: > > * import statements > *

[Python-Dev] Buildbot UI auto-refreshes

Hello, It seems the buildbot Web UI has the bad habit of auto-refreshing itself (by doing a full page reload) every minute or two. I also couldn't find a setting to disable it (despite being logged in). Am I missing something? Regards Antoine. __

[Python-Dev] Re: Buildbot UI auto-refreshes

rker itself but the proxy. > > - > > Pablo > > > On Sun, 21 Mar 2021, 17:12 Antoine Pitrou, wrote: > > > > > Hello, > > > > It seems the buildbot Web UI has the bad habit of auto-refreshing > > itself (by doing a full page reload) every

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

On Wed, 24 Mar 2021 19:45:49 +0300 Ivan Pozdeev via Python-Dev wrote: > How does C++ fare in binary compatibility? Last time I checked it out (about > 10 years ago), there was completely none, every compiler's ABI > was a black box without any guarantees whatsoever. > For any software that's goi

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

On Thu, 25 Mar 2021 20:22:55 +0300 Ivan Pozdeev via Python-Dev wrote: > On 24.03.2021 19:58, Antoine Pitrou wrote: > > On Wed, 24 Mar 2021 19:45:49 +0300 > > Ivan Pozdeev via Python-Dev wrote: > >> How does C++ fare in binary compatibility? Last time I checked it out

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

On Thu, 25 Mar 2021 23:37:46 -0700 "Gregory P. Smith" wrote: > 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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Sun, 04 Apr 2021 00:34:18 - "Brandt Bucher" wrote: > Mark Shannon said: > > I was relying on the "reference" implementation, which is also in the PEP. > > Can you please stop putting scare quotes around "reference implementation"? > You've done it twice now, and it's been a weekend-ruin

[Python-Dev] Re: When we remove 'U' mode of open()?

On Wed, 7 Apr 2021 23:44:18 +0900 Inada Naoki wrote: > On Wed, Apr 7, 2021 at 11:29 PM Miro Hrončok wrote: > > > > On 07. 04. 21 14:53, Inada Naoki wrote: > > > 'U' mode was removed once and resurrected. > > > https://bugs.python.org/issue39674 > > > > > > As far as I can see, it is postponed t

[Python-Dev] Re: NamedTemporaryFile and context managers

On Thu, 8 Apr 2021 13:31:26 -0700 Ethan Furman wrote: > > ```python > from tempfile import NamedTemporaryFile > > with NamedTemporaryFile() as fp: > fp.write(b'some data') > fp.close() # Windows workaround > fp.open() > data = fp.read() > > assert data == 'some_data' > ```

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 13 Apr 2021 03:09:28 +0100 Filipe Laíns wrote: > > This is simply not a good point in itself, and on top of that it seems to > completely ignore that Python could be untyped, Python is definitely not untyped. It's strongly typed. Its typing is just dynamic and isn't explicitly spelled

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

For the record, Cython allows using annotations for typing: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations I don't know if they are fully compatible with the type hints we're talking about here. Regards Antoine. On Wed, 14 Apr 2021 10:58:07 +0900 Inad

[Python-Dev] Re: Typing syntax and ecosystem

On Wed, 14 Apr 2021 10:12:19 +1000 Hugh Fisher wrote: > > For example, type equivalence by name only is used in Ada (or was, > it's been many years) and probably other languages. In equivalence > by name, the following code would not pass the type checker. > x : list[int] > y : list[int]

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, 14 Apr 2021 22:23:44 +0100 Paul Moore wrote: > On Wed, 14 Apr 2021 at 21:59, David Mertz wrote: > > > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: > >> > >> If it's not basically equivalent to packaging.version.Version (and > >> based on PEP 440) then we'll be creating a nightma

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Wed, 14 Apr 2021 21:38:11 +0100 Steve Holden wrote: > DEFAULT_TIMESTAMP? It's not a default timestamp, it's a placeholder value meaning "no timestamp". The aforementioned RFC 1952 explicitly says: "MTIME = 0 means no time stamp is available". So yes, it really means "no timestamp", regardles

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 11:37:28 +0200 Victor Stinner wrote: > Paul Bryan: > > Seems like this is something that should make its way into stdlib? > > In the last 10 years, the trend is more to remove anything related to > packaging *outside* the stdlib :-) Since it's evolving way faster What is "e

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Thu, 15 Apr 2021 11:28:03 +0200 Victor Stinner wrote: > If gzip is modified to use SOURCE_DATE_EPOCH timestamp, you get a > reproducible binary and you don't need to add a new constant ;-) > SOURCE_DATE_EPOCH is a timestamp: number of seconds since Unix Epoch > (January 1, 1970 at 00:00). Chan

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Thu, 15 Apr 2021 14:32:05 +0200 Victor Stinner wrote: > SOURCE_DATE_EPOCH is not a random variable, but is a *standardised* > environment variable: > https://reproducible-builds.org/docs/source-date-epoch/ Standardized by whom? This is not a POSIX nor Windows standard at least. Just because a

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 09:38:41 -0700 Barry Warsaw wrote: > On Apr 14, 2021, at 23:11, Christopher Barker wrote: > > > > You wrote the original PEP, so of course you can withdraw it (or reject > > it), but... > > > > Are you sure? See this discussion, I don't think it's as simple as all > > that

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 10:28:53 -0700 Brett Cannon wrote: > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker > wrote: > > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > > wrote: > > > >> Paul Bryan: > >> > Seems like this is something that should make its way into stdlib? > >> > >> In

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 16:12:57 -0700 Brett Cannon wrote: > > So I don't think version comparison occurs often enough to be in the > stdlib, and the fact that an external project exists which isn't interested > in being put in the stdlib suggests to me it isn't worth doing. > > But that's a separat

[Python-Dev] Re: In support of PEP 649

On Fri, 16 Apr 2021 10:35:19 +0900 Inada Naoki wrote: > > And personally, I love static typing but I don't use type hint for > performance/memory usage reason. > I spend much effort to optimize PEP 563 to minimize type hinting overhead. > So it's very sad that if I can not use type hinting when I

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

On Fri, 16 Apr 2021 18:08:58 - "Denis Kotov" wrote: > > Okay lets try to discuss one by one: > 1) Readability - less code, most code is hidden by abstraction without losing > performance > In CPython code lots of stuff like Py_INCREF, Py_DECREF .. it could be fixed > with C++ std::shared_pt

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

On Sun, 18 Apr 2021 02:13:57 +1000 Nick Coghlan wrote: > > If > they want automatic resource management, then we want them working out how > to lift the affected code out of C and into Python (for example, the import > system rewrite). There's a significant amount of wishful thinking here. When

[Python-Dev] Re: PEP 563 in light of PEP 649

On Mon, 19 Apr 2021 13:37:56 -0700 Ethan Furman wrote: > On 4/19/21 10:51 AM, Larry Hastings wrote: > > > Something analogous /could/ happen in the PEP 649 branch but currently > > doesn't.  When running Inada Noki's benchmark, > > there are a total of nine possible annotations code objects.  E

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

Perhaps an unconventional artistic performance ;-) But more probably some kind of loony with a lot of free time... On Fri, 23 Apr 2021 16:49:15 +0100 Pablo Galindo Salgado wrote: > I had I and still don't know what's going on. Mine was in a response to a > release announcement so it was extra w

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Tue, 11 May 2021 10:25:38 +0200 Petr Viktorin wrote: > On 10. 05. 21 10:53, Inada Naoki wrote: > > Hi, folks. > > > > Now Python 3.11 development is open and I am removing some deprecated > > stuffs carefully. > > > > I am considering `configparser.ParseError.filename` property that is > > de

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

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

[Python-Dev] Re: Speeding up CPython

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<    7   8   9   10   11   12   13   14   15   16   >