[Python-Dev] PEP 554 comments

Hello, First, I would like to say that I have no fondamental problem with this PEP. While I agree with Nathaniel that the rationale given about the CSP concurrency model seems a bit weak, the author is obviously expressing his opinion there and I won't object to that. However, I think the PEP i

[Python-Dev] Re: PEP 554 comments

On Sat, 18 Apr 2020 19:02:47 +0200 Antoine Pitrou wrote: > > * I do think a minimal synchronization primitive would be nice. > Either a Lock (in the Python sense) or a Semaphore: both should be > relatively easy to provide, by wrapping an OS-level synchronization > primitive

[Python-Dev] Re: PEP 554 comments

On Mon, 20 Apr 2020 14:22:03 -0600 Eric Snow wrote: > > > The appeal of the PEP for experimentations is multiple: > > 1) ability to concurrently run independent execution environments > >without spawning child processes (which on some platforms and in some > >situations may not be very de

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

On Mon, 20 Apr 2020 15:30:37 -0700 Nathaniel Smith wrote: > > tl;dr: accepting PEP 554 is effectively a C API break, and will force > many thousands of people worldwide to spend many hours wrangling with > subinterpreter support. For the record, that's not my reading of the PEP. PEP 554 doesn't

[Python-Dev] Re: PEP 554 comments

On Tue, 21 Apr 2020 18:27:41 +1200 Greg Ewing wrote: > On 21/04/20 10:23 am, Eric Snow wrote: > > with the current spec channels get automatically closed > > sooner, effectively as soon as all wrapping objects *that were used* > > are garbage collected (or released). > > Maybe I'm missing somet

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

On Tue, 21 Apr 2020 19:45:02 +1200 Greg Ewing wrote: > On 21/04/20 11:24 am, Edwin Zimmerman wrote: > > Socket connections could be passed off from the main interpreter to > > sub-interpreters for concurrent processing that simply isn't possible > > with the global GIL > > I would need convinci

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

On Mon, 20 Apr 2020 19:21:21 -0600 Eric Snow wrote: > Honest question: how many C extensions have process-global state that > will cause problems under subinterpreters? In other words, how many > already break in mod_wsgi? A slightly tricky question is what happens if a PyObject survives longer

[Python-Dev] Re: PEP 554 comments

On Tue, 21 Apr 2020 09:36:22 -0600 Eric Snow wrote: > On Tue, Apr 21, 2020 at 2:18 AM Antoine Pitrou wrote: > > On Tue, 21 Apr 2020 18:27:41 +1200 > > Greg Ewing wrote: > > > On 21/04/20 10:23 am, Eric Snow wrote: > > > > with the current sp

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

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 state that > >> will cause problems

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

On Tue, 21 Apr 2020 12:05:28 -0700 "Gregory P. Smith" wrote: > 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: > > > >

[Python-Dev] Re: Adding a "call_once" decorator to functools

On Wed, 29 Apr 2020 12:01:24 -0700 Raymond Hettinger wrote: > > The call_once() decorator would need different logic: > > 1) if the function has already been called and result is known, return the > prior result :-) > 2) if function has already been called, but the result is not yet known, >

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

On Tue, 5 May 2020 18:59:34 -0700 Nathaniel Smith wrote: > On Tue, May 5, 2020 at 3:47 PM Guido van Rossum wrote: > > > > This sounds like a significant milestone! > > > > Is there some kind of optimized communication possible yet between > > subinterpreters? (Otherwise I still worry that it's n

[Python-Dev] Re: Maintainer for Multiprocessing

On Wed, 06 May 2020 09:42:02 - "Philipp Helo Rehs" wrote: > Hello, > > it looks like davin is no longer active and there is a pending merge request > open more than two years. > > https://github.com/python/cpython/pull/4819 For the record, I've punted on this for a while because reviewing

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

On Sun, 10 May 2020 16:04:02 - "Brandt Bucher" wrote: > I have pushed a second draft of PEP 618: > > https://www.python.org/dev/peps/pep-0618 > > Please let me know what you think – I'd love to hear any new feedback that > hasn't yet been addressed in the PEP! """ >>> x = iter([iter([1, 2,

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

On Tue, 12 May 2020 06:48:32 - "Brandt Bucher" wrote: > > > > A good rule of thumb is that "mode-switches" which change return types or > > > significantly alter functionality are indeed an anti-pattern, > > Source? > > This was based on a chat with someone who has chosen not to become

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

On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: > > Also, if a flag is used, won't that slow down every call to zip even when the > flag is False? Why would it? Is that based on a rational analysis of how argument parsing works? Regards Antoine. __

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

On Wed, 13 May 2020 19:27:57 -0700 Ethan Furman wrote: > On 05/13/2020 06:04 AM, Antoine Pitrou wrote: > > On Tue, 12 May 2020 11:36:38 -0700 > > Ethan Furman wrote: > >> > >> Also, if a flag is used, won't that slow down every call to zip even when > &

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

On Fri, 15 May 2020 10:46:25 -0400 David Mertz wrote: > > > 1. +1 itertools.zip_strict function > > 2. +1 zip.strict(*args) > > 3. +1 zip(*args, mode='strict') # mode='shortest' by default > > 4. +0 zip(*args, strict=True) > > > > Mostly I agree with Steven on relative preference: > > iterto

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

On Fri, 15 May 2020 06:06:00 - "Brandt Bucher" wrote: > Ethan Furman wrote: > > Can you do those with _pydecimal? If performance were an issue anywhere I > > would expect to see it with number crunching. > > No difference, probably because those methods look like they spend most of > th

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

On Mon, 25 May 2020 04:38:17 -0400 "Eric V. Smith" wrote: > On 5/25/2020 4:25 AM, Serhiy Storchaka wrote: > > 24.05.20 17:48, Eric V. Smith пише: > >> Does anyone have an opinion on https://bugs.python.org/issue39673? It > >> maps ETIME to TimeoutError, in addition to the already existing > >>

[Python-Dev] Re: When can we remove wchar_t* cache from string?

On Mon, 15 Jun 2020 11:22:09 +0100 Mark Shannon wrote: > > I don't like this approach. > Adding compile time options means we need to test more versions, but is > no help to end users as they will end up with the release version anyway. I agree with Mark. This sounds less pointless complicatio

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

Thank you Guido :-) Regards Antoine. On Tue, 16 Jun 2020 16:07:43 -0700 Guido van Rossum wrote: > After taking a break to recapitulate from the vigorous debate, Brandt > Bucher has revised PEP 618 and > submitted it for review

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

On Tue, 23 Jun 2020 11:18:37 +0200 Victor Stinner wrote: > > Pseudo-code: > > void iterate(PyObject *obj) > { > PyObjectPP_View view; > > if (PyObjectPP_View_Get(&view, obj)) { > // fast-path: the object provides a PyObject** view > for (Py_ssize_t i=0; i < view.len; i++ { > PyObject *i

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

> > I don't know why Py_TPFLAGS_HAVE_FINALIZE was added, but it wasn't for > > the PEP 384 stable ABI. > > Maybe Antoine Pitrou knows the rationale why Py_TPFLAGS_HAVE_FINALIZE > flag was added. Removing the flag was discussed at: Mainly because some packagers

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

Some comments: * What you call "Constant Value Patterns" can really refer to any local or non-local name, regardless of how complex the referred object is, right? Also, __eq__ is called in that case, not __match__? * If I understand correctly, these: case b"": print("it's an e

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

On Tue, 23 Jun 2020 14:56:47 -0700 Barry Warsaw wrote: > On Jun 23, 2020, at 14:34, Richard Levasseur wrote: > > > I agree with not having flat indentation. I think having "case" indented > > from "match" makes it more readable overall. > > I don’t know whether my suggestion to use `match:`

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

On Wed, 24 Jun 2020 21:54:24 +1200 Greg Ewing wrote: > On 24/06/20 5:20 am, Antoine Pitrou wrote: > > suddently `Point(x, 0)` means something entirely > > different (it doesn't call Point.__new__, it doesn't lookup `x` in the > > locals or globals...). > >

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

On Wed, 24 Jun 2020 12:38:52 -0700 Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please add > your issue *concisely* to this new thread. Note that the following issues > are already open and will be responded to separately; please don't bot

[Python-Dev] Re: Intended invariants for signals in CPython

On Wed, 24 Jun 2020 16:54:34 -0700 Yonatan Zunger via Python-Dev wrote: > ... Reading through more of the code, I realized that I greatly > underestimated the number of interruptible operations. > > That said, the meta-question still applies: Are there things which are > generally intended *not*

[Python-Dev] Re: The Anti-PEP

On Thu, 25 Jun 2020 11:57:49 +0100 Mark Shannon wrote: > > An Anti-PEP is a way to ensure that those opposed to a PEP can be heard > and, if possible, have a coherent voice. > Hopefully, it would also make things a lot less stressful for PEP authors. I don't think this really works. A PEP has

[Python-Dev] Re: Intended invariants for signals in CPython

Le 25/06/2020 à 16:00, Guido van Rossum a écrit : > On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou <mailto:solip...@pitrou.net>> wrote: > > ...  The intent, though, is that any function > waiting on an external event (this can be a timer, a socket, a > lock, a

[Python-Dev] Re: Intended invariants for signals in CPython

On Thu, 25 Jun 2020 11:18:13 -0700 Yonatan Zunger via Python-Dev wrote: > Also, just to sanity-check that I understand things correctly: Python > signal handlers *are* reentrant, in that a signal handler can be > interrupted by another signal, is that right? Is there any general > recommendation o

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On Mon, 29 Jun 2020 12:43:18 +0100 Rhodri James wrote: > On 29/06/2020 11:31, Steve Holden wrote: > > If I am being oversensitive it is perhaps because I have trodden in these > > waters before, and have frequently been surprised by what other people find > > distasteful or offensive. I do not nec

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On Mon, 29 Jun 2020 06:21:36 -0700 Nathaniel Smith wrote: > > You all are displaying breathtakingly levels of ignorance here. Ah... How about you drop the condescending tone, Nathaniel? You certainly can make your point without attacking your fellow contributors. > But using a thread on > pytho

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On Mon, 29 Jun 2020 23:31:31 -0700 Emily Bowman wrote: > On Mon, Jun 29, 2020 at 7:41 PM Raymond Hettinger < > raymond.hettin...@gmail.com> wrote: > > > Perhaps you don't want to believe the results, but the timings are > > careful, stable, repeatable, and backed-up by a disassembly that shows

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On Tue, 30 Jun 2020 11:52:52 +0200 Thomas Wouters wrote: > > I'm not sure who 'our' is in this sentence, but I'm certainly not glad > Python ever took any of your patches. Really? You know, I don't care (and few people probably care) what you think personally of other core developers. But that

[Python-Dev] Re: Recent PEP-8 change

> The grammarian movement, in general, was built on elevating a very specific > form of English over others. Hmm, I'm curious: which form of English do you propose Python should standardize on? I agree that for code comments it may not matter much, but it probably does for documentation. There ar

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On Wed, 1 Jul 2020 12:50:01 +0200 Victor Stinner wrote: > Le mer. 1 juil. 2020 à 03:53, Inada Naoki a écrit : > > I confirmed the performance regression, although the difference is 12%. > > And I find the commit cause the regression. > > > > https://github.com/python/cpython/commit/45ec5b99aefa54

[Python-Dev] Re: Recent PEP-8 change

On Thu, 2 Jul 2020 01:40:56 +0100 Henk-Jaap Wagenaar wrote: > > What I think was meant here: S&W is inappropriate to use as a community > guideline for a diverse community like Python because it is not inclusive > and forces (a particular version of) "Standard English" on others, however, > you u

[Python-Dev] Re: Recent PEP-8 change

On Thu, 2 Jul 2020 19:38:28 +1000 Chris Angelico wrote: > Standardizing on a > single language ensures that everyone can read the comments in a > single, consistent language. That was precisely my point. But "language" doesn't stop at the broad category "English" or "French", there are variation

[Python-Dev] Re: Recent PEP-8 change

On Thu, 2 Jul 2020 14:52:04 +0100 Paul Moore wrote: > On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar > wrote: > > > PEP-8 however does not mention a particular edition and the version that is > > readily available (in the public domain) does contain this problematic > > section "to use the ma

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion

On Thu, 02 Jul 2020 20:41:54 - "Carol Willing" wrote: > > Earlier this year at the Python Language Summit, Ned Batchelder and I > presented the concept of a Documentation Workgroup and a vision for the next > few years: > > - Slidedeck > https://speakerdeck.com/willingc/cpython-documentat

[Python-Dev] Re: Recent PEP-8 change

On Thu, 02 Jul 2020 17:58:44 -0400 Random832 wrote: > On Thu, Jul 2, 2020, at 05:20, Antoine Pitrou wrote: > > We're not talking about posting "your own writing", we're talking about > > comments (and presumably documentation) in a collective software > >

[Python-Dev] Re: Recent PEP-8 change

On Thu, 02 Jul 2020 18:54:26 -0400 Random832 wrote: > On Thu, Jul 2, 2020, at 18:15, Antoine Pitrou wrote: > > On Thu, 02 Jul 2020 17:58:44 -0400 > > Random832 wrote: > > > Why indeed? > > > > Because we're talking about PEP 8, and PEP 8 inte

[Python-Dev] Re: PEP 622 railroaded through?

On Wed, 1 Jul 2020 21:14:00 +0100 Rob Cliffe via Python-Dev wrote: > Whoa! > > I have an uneasy feeling about this PEP. > > AFAIK the usual procedure for adding a new feature to Python is: >     An idea is raised and attracts some support. >     Someone sufficiently motivated writes a PEP. >

[Python-Dev] Re: In case you're wondering about 3.5.10rc1

On Sat, 4 Jul 2020 00:01:56 -0700 Larry Hastings wrote: > It's held up on SSL.  Ubuntu 20.04 changed some security parameter > tunings, which breaks some uses of the SSL module, and approximately > eight modules in the test suite.  I assume this wasn't caught on the > buildbots because they don

[Python-Dev] Re: In case you're wondering about 3.5.10rc1

On Sat, 4 Jul 2020 13:16:50 +0200 Antoine Pitrou wrote: > On Sat, 4 Jul 2020 00:01:56 -0700 > Larry Hastings wrote: > > It's held up on SSL.  Ubuntu 20.04 changed some security parameter > > tunings, which breaks some uses of the SSL module, and approximately > &

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, 8 Jul 2020 18:38:12 +0100 Rhodri James wrote: > On 08/07/2020 16:02, Guido van Rossum wrote: > > Today I’m happy (and a little trepidatious) to announce the next > > version of PEP 622, Pattern Matching. > > Thank you very much to everyone who has been working on this, it is much > app

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, 8 Jul 2020 20:08:34 +0200 Antoine Pitrou wrote: > On Wed, 8 Jul 2020 18:38:12 +0100 > Rhodri James wrote: > > On 08/07/2020 16:02, Guido van Rossum wrote: > > > Today I’m happy (and a little trepidatious) to announce the next > > > versio

[Python-Dev] Re: Memory address vs serial number in reprs

On Sun, 19 Jul 2020 18:38:30 +0300 Serhiy Storchaka wrote: > I have problem with the location of hexadecimal memory address in custom > reprs. > > > > vs > > How about putting it in parentheses, to point more clearly that it can most of the time be ignored: > I do not propose

[Python-Dev] Re: datetime module refactoring: folder vs parallel private modules

On Mon, 20 Jul 2020 19:49:38 -0700 Guido van Rossum wrote: > I would go with Ivan's second suggestion (_pydatetime.py). The Zen of > Python mentions "flat is better than nested" and a package seems overkill > here (I'm not sure why you chose a package for zoneinfo, but it looks like > it has a lit

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

On Wed, 22 Jul 2020 12:46:40 +0900 Inada Naoki wrote: > On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote: > > > > On 18/07/2020 9:20 am, Inada Naoki wrote: > > > It seems great improvement, but I am worrying about performance. > > > > > > Adding more attributes to the code object will increas

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

On Wed, 22 Jul 2020 19:42:30 +0900 Inada Naoki wrote: > On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou wrote: > > > > > > > > But if we merge two equal code blocks, we can not produce precise line > > > numbers, can we? > > > Is this inconsistent mi

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

Le 22/07/2020 à 15:48, Inada Naoki a écrit : > On Wed, Jul 22, 2020 at 8:51 PM Antoine Pitrou wrote: >> >>> >>> I don't think all attempts are failed. Note that current CPython includes >>> some optimization already. >> >> The set of compi

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, 5 Aug 2020 09:47:30 -0700 Ethan Furman wrote: > On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: > > > The debate is still going on as to whether "capture" variables should be > > marked... > I don't think the PEP authors are debating it any more. That would be a pity. Readabilit

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 7 Aug 2020 17:33:04 -0300 "Joao S. O. Bueno" wrote: > > Branch comparison for the match/case version: > https://github.com/jsbueno/terminedia/compare/patma For me, your example is bonkers from the start. Anyone who thinks `Rect(left_or_corner1=None, top_or_corner2=None, right=None,

[Python-Dev] Re: Resurrecting PEP-472

On Fri, 28 Aug 2020 10:20:08 +0200 Victor Stinner wrote: > Hi, > > IMO a new PEP would avoid confusion: > > * The new PEP should list differences with the previously rejected PEP > * The old PEP remains available unchanged to help to understand why it > has been rejected > > It's common to have

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

Hi, On Tue, 01 Sep 2020 02:52:07 - "Raihan Rasheed Apurbo" wrote: > In CPython we have reference counting. My question is can we optimize current > RC using > strategies like Deferred RC and Coalescing? If no then where would I face > problems if I try > to implement these sorts of strate

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On Thu, 03 Sep 2020 18:17:12 - "Brandt Bucher" wrote: > Tim Peters wrote: > > `zip` then creates `n` 2-tuple objects, each of which lives only long > > enough to be unpacked into `x` and `y`... With "immediate" reclamation of > > garbage via refcounting, memory use is trival regardless of ho

[Python-Dev] Re: PEP 632: Deprecate distutils module

On Fri, 4 Sep 2020 12:28:30 +0100 Steve Dower wrote: > > It will also help > promote the development of alternative build backends, which can now > be supported more easily thanks to PEP 517. While I agree with the general suggestion of deprecating distutils as a publicly-visible module (in favo

[Python-Dev] Re: PEP 632: Deprecate distutils module

On Sat, 5 Sep 2020 07:39:10 -0400 Edwin Zimmerman wrote: > On 9/5/2020 3:59 AM, Emily Bowman wrote: > > On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah > > wrote: > > > > > > > > It is not hyperbolic at all. You can get permissions for a certain set > > of modules

[Python-Dev] Re: Enum and the Standard Library

On Fri, 18 Sep 2020 18:14:35 -0700 Ethan Furman wrote: > > So at this point, I think the choices are: > > Standard Enum >__repr__ __str__ >RegexFlag.IGNORECASE > > and > > Modified Converted Constant >__repr__ __str__ > re.IGNORECASE

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On Mon, 21 Sep 2020 20:35:33 +0200 Victor Stinner wrote: > > When I proposed my PEP 620 "Hide implementation details from the C > API", I was asked about a proof that the PEP unlocks real optimization > possibilities. So I wrote an implementation of tagged pointers: > https://github.com/vstinner/

[Python-Dev] Re: unable to create PR on github

On Mon, 21 Sep 2020 20:56:18 -0700 Ethan Furman wrote: > And even more data: > > I added a body to the PR I was originally having trouble with: >button stayed gray > > I went away for a while, say 5 - 10 minutes, and when I went back to > that screen the button was green. I created the PR.

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On Tue, 22 Sep 2020 17:11:40 -0700 Guido van Rossum wrote: > On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing > wrote: > > > What are you trying to achieve by using tagged pointers? > > > > It seems to me that in a dynamic environment like Python, tagged > > pointer tricks are only ever going to redu

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On Wed, 23 Sep 2020 12:46:25 +0100 Ivan Levkivskyi wrote: > > Another thing is that making CPython itself JITted may be even harder than > adding some (opt-in) static based optimizations, but > I am clearly biased here. > > Actually what would be really cool is having both: i.e. have a JIT that

[Python-Dev] Resignation from Stefan Krah

Hello, Apparently, Stefan Krah (core developer and author of the C _decimal module) was silently banned or moderated from posting to python.org mailing-lists. He asked me to forward the following message: == Hello

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Fri, 9 Oct 2020 05:04:55 +0300 Ivan Pozdeev via Python-Dev wrote: > I don't see the point of requiring to "write an apology", especially *before > a 12-month ban*. If they understand that their behavior is > wrong, there's no need for a ban, at least not such a long one; if they > don't, the

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

Le 09/10/2020 à 15:57, Christian Heimes a écrit : > On 09/10/2020 15.48, Antoine Pitrou wrote: >> On Fri, 9 Oct 2020 05:04:55 +0300 >> Ivan Pozdeev via Python-Dev wrote: >>> I don't see the point of requiring to "write an apology", especially >>>

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On Sun, 11 Oct 2020 16:05:07 +0900 "Stephen J. Turnbull" wrote: > Ivan Pozdeev via Python-Dev writes: > > > Possessive and obstructive behavior like Victor describes below is > > incompatible with the bazaar model of development (=a model where > > the dev team accepts contributions from a wid

[Python-Dev] Re: [python-committers] Performance benchmarks for 3.9

Le 14/10/2020 à 15:16, Pablo Galindo Salgado a écrit : > Hi! > > I have updated the branch benchmarks in the pyperformance server and now > they include 3.9. There are > some benchmarks that are faster but on the other hand some benchmarks > are substantially slower, pointing > at a possible perf

[Python-Dev] Re: [python-committers] Re: Performance benchmarks for 3.9

Le 14/10/2020 à 17:25, M.-A. Lemburg a écrit : > > Well, there's a trend here: > > [...] > > Those two benchmarks were somewhat faster in Py3.7 and got slower in 3.8 > and then again in 3.9, so this is more than just an artifact. unpack-sequence is a micro-benchmark. It's useful if you want t

Re: [Python-Dev] str() on memoryview of bytearray failing on py3k

Mark Hammond gmail.com> writes: > >I'm not sure if the following is a bug I should report or simply an > artifact of the implementation and/or simply the way things work on py3k: > [...] It's a bug. Regards Antoine. ___ Python-Dev mailing list

Re: [Python-Dev] Expression optimizations

Cesare Di Mauro a-tono.com> writes: > Could it be applyable to other operations as well? So, if I wrote: > > c = not(a < b) > > the compiler and/or peephole optimizer can generate bytecodes instructions which, instead, execute the > following operation: > > c = a >= b > > Is it right? No,

Re: [Python-Dev] Expression optimizations

Steve Holden holdenweb.com> writes: > > That's true, but the same *could* be said about the existing > optimizations for objects that define their own __contains__. No, because there is no such thing as __not_contains__. Regards Antoine. ___ Python

Re: [Python-Dev] Python-acceleration instructions on ARM

Martin v. Löwis v.loewis.de> writes: > - efficient array indexing: they give shift-and-index back to > Thumb mode, for a shift by 2, allowing to index arrays with > 4-byte elements in a single instruction (rather than requiring > a separate multipy-by-four). Again useful for JIT of array >

Re: [Python-Dev] 3.0.1 and 2.6.2

Jesse Noller gmail.com> writes: > > I'm afraid I've gone branch-stupid. I have a a few changes that should > be on the boat for the next release, but I can't for the life of me > remember which branch to push to - right now the changes are on trunk > and py3k. The next release (3.0.1) is tomorro

Re: [Python-Dev] The fate of 3.0.*

Benjamin Peterson python.org> writes: > > Are we going to keep developing the 3.0 maintenance branch in > expectation of releasing 3.0.2 sometime or will we just focus our > efforts on 3.1? Focusing on 3.1 should be ok. So what are the expected efforts for 3.1? - io-in-C - import-in-Python - ..

Re: [Python-Dev] No 2.x->3.x porting documentation?

pobox.com> writes: > > I'm making a naive stab at converting nose to Python3 so I can hopefully run > the lockfile test cases under Python 3. Apparently, Jason Pellerin has started a py3k branch for the same purpose: http://groups.google.com/group/nose-dev/browse_thread/thread/621c3767bbce3abc h

Re: [Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?

Hello, Nick Coghlan gmail.com> writes: > > I *think* the 2.x system had an internal buffer that was used by the > file iterator, but not by the file methods. With the new IO stack for > 3.0, there is now a common buffer shared by all the file operations > (including iteration). > > However, gi

Re: [Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?

Hello, bitdance.com> writes: > > Since the 'pipe' comment is an XXX, it is not clear that my use case > is covered. However, the actual implementation of readinto seems to > only call 'read' once, so as long as the 'read' of the subclass returns > whatever bytes are available, then it looks go

Re: [Python-Dev] IO implementation: in C and Python?

Benjamin Peterson python.org> writes: > > As we prepare to merge the io-c branch, the question has come up [1] > about the original Python implementation. Should it just be deleted in > favor C version? The wish to maintain the two implementations together > has been raised on the basis that Pyth

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

Georg Brandl gmx.net> writes: > > The Python Wiki should also be considered: > > * Comparing versions is easy, and versions are only saved on "Save" > > * It supports reStructuredText, so there is no need for conversion > afterwards. And it's vendor-neutral :-)

Re: [Python-Dev] IO implementation: in C and Python?

Georg Brandl gmx.net> writes: > > I just hope everyone updates both versions when making changes to IO. My proposal is just organizational, it is neutral in terms of whether or not the Python version is correctly maintained. We can hope that the IO lib *semantics* won't change too much in the f

Re: [Python-Dev] IO implementation: in C and Python?

Guido van Rossum python.org> writes: > > I worry that with your proposal people are once again going to import > the pure Python version where they shouldn't. Maybe _pyio.py would > work though? I'm ok with _pyio.py. > Hoping that modules won't evolve is futile. The concern for divergence > is

Re: [Python-Dev] Attention Bazaar mirror users

Stephen J. Turnbull xemacs.org> writes: > > > > Whether it is depends on when a DVCS gets selected. If it gets selected > > after lenny+1 has been released, I see no problem with requiring version > > 1.12 (or whatever lenny+1 will then ship with). > > I really hope we won't have to wait tha

[Python-Dev] Silencing IO errors on del/dealloc?

Hello, The Python version of IO lib has taken the stance that all errors happening in the destructor of an IO object are silenced. Here is the relevant code in IOBase: def __del__(self) -> None: """Destructor. Calls close().""" # The try/except block is in case this is calle

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Guido van Rossum python.org> writes: > > OTOH the is a much larger category of false positives, where a close() > call raise an exception for some spurious reason (see the quoted > comment) but no harm is done; in the past the tracebacks printed for > __del__ by default have caused nothing but co

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Greg Ewing canterbury.ac.nz> writes: > > I would hope that the C version could at least ensure that > buffers are flushed properly without having to rely on any > global variables, so that this would not be so much of an > issue. The C version cleans up after itself just fine :) The issue is whe

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Guido van Rossum python.org> writes: > > If you want to ensure buffers are flushed, why not call self.flush() > for writable files outside the try/except? If flush() fails it *is* a > real problem. Well, my concern is less about flushing writable files (they will be implemented in C and the flus

Re: [Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Farshid Lashkari gmail.com> writes: > > It seems like some code in safelite passes a file object to > isinstance. By overriding the builtin isinstance function I can get > access to the original file object and create a new one. Here is the > code I used: I guess Tav should open a restaurant :-)

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

tav espians.com> writes: > > I've fixed this hole in safelite.py, but would be interested to know > if there are other non-user-initiated dynamically imported modules? You'd better make __builtins__ read-only, it will plug a whole class of attacks like this. ___

[Python-Dev] Shared ABCs for the IO implementation

Hello, I would like to know if both IO implementations (the C one and the Python one) should share their ABCs (IOBase, RawIOBase, etc.). It looks preferable to me but since I'm not very familiar with ABCs I'd like to be sure it's the good choice. (of course, the *implementations* won't be shared

Re: [Python-Dev] Shared ABCs for the IO implementation

Guido van Rossum python.org> writes: > > Without a shared ABC you'd defeat the whole point of having ABCs. > > However, importing ABCs (which are defined in Python) from C code > (especially such fundamental C code as the I/O library) is really > subtle and best avoided. > > In io.py I solved t

Re: [Python-Dev] Shared ABCs for the IO implementation

Guido van Rossum python.org> writes: > > However that's hardly an ABC. You need to provide a path for someone > who wants to implement the ABC without inheriting your implementation. I may missing something, but it's exactly the same as today's io.py: if you derive the ABC, you inherit the imple

Re: [Python-Dev] draft 3.1 release schedule

Benjamin, > > You might also want to collect a list of serious changes that you want > > in this release; I know I/O in C is on the list (and without it I > > wouldn't consider it worth releasing) but there may be others. The > > developers of such features ought to be on board with delivering the

Re: [Python-Dev] Googlebot and the mail.python.org pyth on-dev archive

Georg Brandl gmx.net> writes: > > Guido van Rossum schrieb: > > I think the better syntax would be to add site:mail.python.org to the > > query, but you're right, that doesn't seem to find recent messages. > > Maybe the absence of a robots.txt file on mail.python.org could be a > > partial explan

Re: [Python-Dev] Googlebot and the mail.python.org pyth on-dev archive

Nick Coghlan gmail.com> writes: > > > > > which explicitly instructs Web spiders *not* to index contents nor follow links. > > That's not quite true - that meta tag says not to index the current > page, but *do* follow the links to other pages. The archive page and the > monthly summary pa

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement

Raymond Hettinger rcn.com> writes: > > Guido, I'm recommending this PEP for acceptance. Given you were bitten by it in your own unit tests (the "eval(repr()) does not maintain ordering" problem pointed by Georg), I think it would be better to reconsider the current __eq__ behaviour, and make it

Re: [Python-Dev] PEP 372 -- Adding an ordered directory t o collectionsready for pronouncement

Raymond Hettinger rcn.com> writes: > Completely unrelated. The original test passed because the arbitrarily > ordered data in the regular dict happened to match the order added in > a regular dict because I didn't shuffle the keys. Well, I may be mistaken, but it seems your test_copying (in od5.

<    16   17   18   19   20   21   22   23   24   25   >