[Python-Dev] Re: Resurrecting PEP-472

Leaving out the complication of needing a new sponsor, I would think the best course of action would be to create a new PEP. I think keeping the original rejected PEP is a net positive, and especially so if one of the original authors isn't available. At the very least, you'd want to remove

[Python-Dev] Re: PEP 515: Non-empty return statement

> https://mail.python.org/archives/list/python-dev@python.org/message/IYF6QKMNSTZEVEXBDIJH7NO2VNDJNUZJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev

[Python-Dev] Re: PR stuck in Travis

Hi, Facundo. You could try closing the PR and then re-opening it. Eric On 8/21/2020 2:18 PM, Facundo Batista wrote: Hello! I want to land this PR: https://github.com/python/cpython/pull/21466 It's doc only, so it only run the docs part in GH actions. All fine, except Travis, which is

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

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

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

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

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

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

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

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

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

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

[Python-Dev] Re: Problems with python and Geany?

This list is for the development of Python the language. For end-user help, you're better off using python-list, whose details are here: https://mail.python.org/mailman/listinfo/python-list Eric On 7/16/2020 8:00 AM, arajg...@sevenmentor.com wrote: So I have recently purchased a rapsberry pi

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

On 7/11/2020 7:54 PM, Greg Ewing wrote: I can see that being a reasonable choice if you're using 8-space indents, but I don't see that done much in Python. Also, directly translating this into Python leads to something that looks like a mistake:     match x:     case 1:     ...     case

[Python-Dev] Re: ML help

This list if for developing the next version of Python, not for providing help with using Python. I suggest you use a Sift-specific mailing list for help with Sift. Eric On 7/6/2020 4:54 AM, hamza naeem wrote: Hi , I am making a classifier which basically scans the historical places and

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

On 7/2/2020 6:49 PM, Rémi Lapeyre wrote: Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> a écrit : Athttps://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge, they say that the argument of whether to allow overwriting history in VCSes

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

On 7/2/2020 11:36 AM, Stefan Behnel wrote: Victor Stinner schrieb am 02.07.20 um 00:07: Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit : On 7/1/2020 3:43 PM, Stefan Behnel wrote: Petr Viktorin schrieb am 30.06.20 um 14:51: For example, could we only deprecate the bad parts

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

On 7/1/2020 3:43 PM, Stefan Behnel wrote: Petr Viktorin schrieb am 30.06.20 um 14:51: For example, could we only deprecate the bad parts, but not remove them until the experiments actually show that they are preventing a beneficial change? Big nod on this one. At one of the core sprints

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

, and you can do your own work if you care to. But let's let this thread die here. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail

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

nity [1]. -n [1] https://en.wikipedia.org/wiki/White_defensiveness -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailma

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

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

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

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

[Python-Dev] Re: The Anti-PEP

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

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

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

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

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

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

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

[Python-Dev] Re: New optional dependency

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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/17/2020 6:03 PM, Jeff Allen wrote: On 17/06/2020 19:28, Eric V. Smith wrote: On 6/17/2020 12:07 PM, Jeff Allen wrote: If (1) interpreters manage the life-cycle of objects, and (2) a race condition arises when the life-cycle or state of an object is accessed by the interpreter that did

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/17/2020 12:07 PM, Jeff Allen wrote: On 12/06/2020 12:55, Eric V. Smith wrote: On 6/11/2020 6:59 AM, Mark Shannon wrote: Different interpreters need to operate in their own isolated address space, or there will be horrible race conditions. Regardless of whether that separation is done

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/11/2020 6:59 AM, Mark Shannon wrote: Hi Riccardo, On 10/06/2020 5:51 pm, Riccardo Ghetta wrote: Hi, as an user, the "lua use case" is right what I need at work. I realize that for python this is a niche case, and most users don't need any of this, but I hope it will useful to understand

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/10/2020 8:33 AM, Mark Shannon wrote: Hi Petr, On 09/06/2020 2:24 pm, Petr Viktorin wrote: On 2020-06-05 16:32, Mark Shannon wrote: Whether Python interpreters run sequentially or in parallel, having them work will enable a use case I would like to see: allowing me to call Python code

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 6/5/2020 11:11 AM, Edwin Zimmerman wrote: Advantages of the one-to-one model -- 1. It's less bug prone. It is much easier to reason about code working in a single address space. Most code assumes I'm curious where reasoning about address spaces comes into

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

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: Can we stop adding to the C API, please?

https://github.com/pycurl/pycurl/pull/636 I'm not saying you're wrong to do so, I'm just confused about whether your plan is to break stuff or not and on which timescale. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- pyth

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

n psutil I have "TimeoutExpired", also providing a "seconds" attribute. Also I've probably never seen ETIME / ETIMEDOUT happening, whereas AFAIU the point PEP 3151 was to create mappings for the most common errnos. On Sun, May 24, 2020 at 6:48 PM Eric V. Smith <mailto:e...@

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

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 ETIMEDOUT. http://man7.org/linux/man-pages/man3/errno.3.html says

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

On Mon, May 25, 2020 at 1: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 ETIMEDOUT. > > > > http:/

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

o know how this might affect try/except setups, particularly ones like the above which expect to catch a class of error and differentiate amongst them. I am not against the issue suggest though. Cheers, Cameron Simpson On 24May2020 14:59, Gregory P. Smith wrote: Sounds like a natural fit, I

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

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. > > http://man7.org/linux/ma

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

Does anyone have an opinion on https://bugs.python.org/issue39673? It maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT. http://man7.org/linux/man-pages/man3/errno.3.html says: *ETIME *Timer expired (POSIX.1 (XSI STREAMS option)). (POSIX.1

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

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

I fear that my comment on some text in the PEP was lost amidst the voting, so I'm repeating it here. This will probably screw up some threading, but this is the oldest message I have to reply to. The PEP says "At most one additional item may be consumed from one of the iterators when compared

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

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: PEP 618: Add Optional Length-Checking To zip

On 5/15/2020 11:56 AM, Chris Angelico wrote: On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: 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,

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

rtup sequence, re-import all modules from scratch, etc. Subinterpreters do get to skip the OS process spawn overhead, but most of the startup costs are the same. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@py

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

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: Issues with import_fresh_module

s.html But yeah, convincing your test framework to jump through the necessary hoops might be tricky. (Last time I did this I was using pytest-cov, which automatically takes care of all the details, so I'm not sure how tough it is.) -n -- Nathaniel J. Smith -- https://vorp

[Python-Dev] Re: Issues with import_fresh_module

the thing or they don't. But, I don't know how awkward that would be to fit into Python's unittest system, if you have lots of tests you need to run this way. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@p

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

On Wed, May 6, 2020 at 10:03 AM Antoine Pitrou wrote: > > 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! > > > > >

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

On Wed, May 6, 2020 at 5:41 AM Victor Stinner wrote: > > Hi Nathaniel, > > Le mer. 6 mai 2020 à 04:00, Nathaniel Smith a écrit : > > As far as I understand it, the subinterpreter folks have given up on > > optimized passing of objects, and are only hoping to do optimized

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

ey haven't found one yet. -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Me

[Python-Dev] Re: Remove ctypes from uuid

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?

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: [RELEASE] Python 3.9.0a6 is now available for testing

Hi, ro...@reportlab.com. That looks like a real error. Thanks for the detailed report. Can you open a ticket on bugs.python.org? Eric On 4/29/2020 10:34 AM, ro...@reportlab.com wrote: While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using

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

On 4/29/2020 3:55 AM, Tom Forbes wrote: Hey Raymond, Thanks for your input here! A new method wouldn’t be worth adding purely for performance reasons then, but there is still an issue around semantics and locking. One thing I don't understand about the proposed @call_once (or whatever it's

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

rd would be for me to write up a PEP for removing subinterpreter support, so we can all look at the different options and make an informed decision? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.

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

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

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?

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: PEP 554 for 3.9 or 3.10?

On Mon, Apr 20, 2020 at 5:36 PM Edwin Zimmerman wrote: > > On 4/20/2020 7:33 PM, Nathaniel Smith wrote: > > On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman > > wrote: > >> On 4/20/2020 6:30 PM, Nathaniel Smith wrote: > >>> We already have robus

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

On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman wrote: > > On 4/20/2020 6:30 PM, Nathaniel Smith wrote: > > We already have robust support for threads for low-isolation and > > subprocesses for high-isolation. Can you name some use cases where > > neither of these are app

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

On Fri, Apr 17, 2020 at 3:57 PM Eric Snow wrote: > > On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote: > > I think some perspective might be useful here :-). > > > > The last time we merged a new concurrency model in the stdlib, it was > > asyncio. >

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

Congratulations, Dennis! Not 10 minutes ago I was writing code that could have used this functionality. And I got it wrong on my first attempt! I'm looking forward to it in 3.9. Eric On 4/20/2020 2:26 PM, Victor Stinner wrote: Hi, The Python Steering Council accepts the PEP 616 "String

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

g is more complex, it should get *more* scrutiny, not less. But it's very hard to effectively reason about the whole conglomeration and formulate feedback. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org

[Python-Dev] Re: Improvement to SimpleNamespace

ot;a"]["b.c"][2], but OTOH you get better error message on failed lookups, null-coalescing support by using default=, etc. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubs

[Python-Dev] Re: Improvement to SimpleNamespace

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

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: Improvement to SimpleNamespace

, default=None)'. Like anything there are probably trade-offs and situations where something like AttributeDict is better, but figured I'd throw that out there as another option to consider. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev maili

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

On 4/12/2020 4:08 PM, Barry Scott wrote: On 11 Apr 2020, at 16:28, Barry Scott > wrote: modulefinder.py does not open source files in "rb" which prevents compile() from applying the encoding rules. snip *I have created the bpo, the pr and have the checks

[Python-Dev] Re: Need help with test_ctypes failing on Windows (test_load_dll_with_flags)

(Trusty assistant reporting in) I should also note that further up the output there is a FileNotFoundError for sqlite3.dll, perhaps it isn't built or is in the wrong place? Ethan On Mon, Apr 6, 2020, 7:19 PM Guido van Rossum wrote: > I have a large PR

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

d confirm that they match? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.o

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

On 3/26/2020 9:10 PM, Ethan Furman wrote: First off, thank you for being so patient -- trying to champion a PEP can be exhausting. On 03/26/2020 05:22 PM, Dennis Sweeney wrote: So now if I understand the dilemma up to this point we have: Benefits of writing ``return self`` in the PEP:     a

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

On 3/25/2020 1:36 PM, Dennis Sweeney wrote: I'm removing the tuple feature from this PEP. So now, if I understand correctly, I don't think there's disagreement about behavior, just about how that behavior should be summarized in Python code. I think that's right. Ethan Furman wrote: It

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

On 3/24/2020 7:21 PM, Dennis Sweeney wrote: It seems that there is a consensus on the names ``removeprefix`` and ``removesuffix``. I will update the PEP accordingly. I'll also simplify sample Python implementation to primarily reflect *intent* over strict type-checking correctness, and I'll

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

On 3/24/2020 3:30 PM, Steve Dower wrote: On 24Mar2020 1849, 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

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

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

On 3/23/2020 12:02 PM, Rhodri James wrote: On 23/03/2020 14:50, Dan Stromberg wrote: I tend to be mistrustful of code that tries to guess the best thing to do, when something expected isn't found. How about: def cutprefix(self: str, pre: str, raise_on_no_match: bool=False, /) -> str:

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

On 3/22/2020 12:25 PM, Paul Ganssle wrote: Sorry, I think I accidentally left out a clause here - I meant that the rationale for /always returning a 'str'/ (as opposed to returning a subclass) is missing, it just says in the PEP: The only difference between the real implementation and the

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

On 3/22/2020 1:42 AM, Nick Coghlan wrote: On Sun, 22 Mar 2020 at 15:13, Cameron Simpson wrote: On 21Mar2020 12:45, Eric V. Smith wrote: On 3/21/2020 12:39 PM, Victor Stinner wrote: Well, if CPython is modified to implement tagged pointers and supports storing a short strings (a few latin1

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

adability wouldn't make up for the headache IMO. >> >> On Sun, Mar 22, 2020 at 12:13 AM Ivan Pozdeev via Python-Dev < >> python-dev@python.org> wrote: >> >>> On 22.03.2020 6:38, Guido van Rossum wrote: >>> >>> On Sat, Mar 21, 2020 at 6:46 PM Nick

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

On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote: > > On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote: > > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney > > wrote: > > > This is a proposal to add two new methods, ``cutprefix`` and >

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

On 3/21/2020 2:09 PM, Steven D'Aprano wrote: On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote: On 3/21/2020 11:20 AM, Ned Batchelder wrote: Why be so prescriptive? The semantics of these functions should be about what the resulting string contains.  Leave it to implementors

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

shorter than the whole string. Agreed (except the string passed to startswith should be the same as the one used in cutprefix!). Eric Victor Le sam. 21 mars 2020 à 17:45, Eric V. Smith a écrit : On 3/21/2020 12:39 PM, Victor Stinner wrote: Well, if CPython is modified to implement tagged point

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

t/whatever took place, other than comparing via equality, not identity. Eric Victor Le sam. 21 mars 2020 à 17:23, Eric V. Smith a écrit : On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 202

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

On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney wrote: If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then ``s.cutprefix(pre)`` returns a

[Python-Dev] Re: Proliferation of tstate arguments.

and then let the main thread set its own eval_breaker etc. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/list

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

quot;suffix", to reduce the jargon factor and for consistency with startswith/endswith. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: Looking for a sponsor and feedback on PEP 616: string methods for removing prefixes and suffixes

I'll sponsor it. Eric On 3/20/2020 11:29 AM, Dennis Sweeney wrote: Hello all! I'm a relatively new contributor looking for a Core Dev sponsor for the following PEP: https://github.com/python/peps/pull/1332 Related: - Python-Ideas Thread:

[Python-Dev] Re: How to respond to repeated bad ideas

On 3/3/2020 2:18 AM, Serhiy Storchaka wrote: 03.03.20 01:03, Skip Montanaro пише: Atm we don't have an index of ideas, apart from pep 3099, and I'm not sure we can make one (can we?), so I do not see a way to prevent this from happening. Maybe an informational PEP which briefly lists

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

The discussion on the name change came from Łukasz https://github.com/python/cpython/pull/18239#discussion_r380996908 I suggested "GenericType" to be in line with other things in types.py. On Mon, Feb 24, 2020 at 8:39 PM Guido van Rossum wrote: > I can't find it right now, but IIRC somebody

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

While working on the implementation with Guido I made a list of things that inherit from typing.Generic in typeshed that haven't been listed/implemented yet. https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121 On Sat, Feb 22, 2020, 3:50 PM Nick Coghlan wrote: > This looks

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 9:14 AM, Miro Hrončok wrote: On 24. 01. 20 14:02, Eric V. Smith wrote: I think the concern is that with removing so many deprecated features, we're effectively telling libraries that if they want to support 3.9, they'll have stop supporting 2.7. And many library authors aren't

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 2:02 PM, Serhiy Storchaka wrote: 21.01.20 12:37, Eric V. Smith пише: Yes (I wrote a lot of that), but '.17g' doesn't mean to always show 17 digits. See https://github.com/python/cpython/blob/master/Python/pystrtod.c#L825 where the repr (which is format_code =='r') is translated

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 1:32 PM, Chris Angelico wrote: On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote: The reason repr adds the '.0' that 'g' does not is to avoid this problem: >>> type(eval(repr(17.0))) == type(17.0) True >>> type(eval(format(17.0, '.17g'))) == type(17.0) Fal

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 11:52 AM, Steven D'Aprano wrote: I don't really care whether there's documentation for __str__() or __repr__() or something else. I'm just thinking that there should be some way to guarantee a well defined "useful" float output formatting.

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 4:32 AM, Serhiy Storchaka wrote: 21.01.20 10:37, Eric V. Smith пише: For what it's worth, float's repr internally uses a format of '.17g'. So, format(value, '.17g') will be equal to repr(f), where f is any float. It was in Python 2, but since Python 3.1 it returns the shortest

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/20/2020 10:59 PM, Karl O. Pinc wrote: Hello, There appears to be extremely minimal documentation on how floats are formatted on output. All I really see is that float.__str__() is float.__repr__(). So that means that float->str->float does not result in a different value. It would be

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

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)

+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__?

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

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)

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: Parameters of str(), bytes() and bytearray()

On 12/16/2019 3:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable form of this > object" and "decode

<    1   2   3   4   5   6   7   8   9   10   >