[Python-Dev] Re: Restrict the type of __slots__

On 3/18/2022 10:01 AM, Ronald Oussoren via Python-Dev wrote: On 18 Mar 2022, at 14:37, Joao S. O. Bueno wrote: IMO this is a purism that have little, if any place in language restrictions. I see that not allowing. "run once" iterables could indeed void attempts to write "deliberatly non co

[Python-Dev] Re: Restrict the type of __slots__

On 3/18/2022 4:58 PM, Guido van Rossum wrote: On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan wrote: On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote: The motivation has been explained already. In this thread? Yes, Eric's message. What on earth did your test do that g

[Python-Dev] Re: Changing unittest verbose output.

On 3/27/2022 10:51 AM, Jelle Zijlstra wrote: El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () escribió: Any thoughts on the mentioned solutions? This is a bit more out there, but can anyone explain why we show the docstring at all? As far as I can tell it causes a bunch of confusion

[Python-Dev] Re: Changing unittest verbose output.

> On Mar 27, 2022, at 11:20 AM, Eric V. Smith wrote: > >  > On 3/27/2022 10:51 AM, Jelle Zijlstra wrote: >> >> >> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () >> escribió: >>> >>> Any thoughts on the mentioned solutions? >>

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 3/29/2022 4:55 PM, Skip Montanaro wrote: I was trying to think through how a "remote" stdlib might work. In the process, I got to wondering if there are known "specialists" for various current modules. Every now and then I still get assigned (or at least made nosy) about something to do with

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

On 4/9/2022 4:28 PM, Terry Reedy wrote: On 4/9/2022 5:09 AM, Arfrever Frehtes Taifersar Arahesis wrote: Not only deletion, but also random assignments: Ok.  Change "Manual deletion of entries from sys.modules" to "Direct manipulation of sys.modules" I'm not sure it's worth the hassle to do

[Python-Dev] Re: Updating inspect APIs

Things like os.stat_result use PyStructSequence_NewType, which is the C equivalent of a namedtuple. But a Struct Sequence has the extension of being able to have more named fields than the tuple length. It was designed, so I understand, just for cases like this. I don't know if it would be poss

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/2022 3:28 AM, Tobias HT wrote: On the other hand, there's something I've been seeing around. I don't know if it was introduced by Mypy or something, but its the use of declaration files. I think they are saved as pyi files. They just have the declaration of a python object, be it cla

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/2022 9:55 AM, Jelle Zijlstra wrote: However, it doesn't solve the problem for base classes. For example, str is conceptually defined as `class str(Sequence["str"]):`. A forward reference can't make `str` defined when the bases are evaluated, because bases are resolved at the `forward

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote: What's the use case for arbitrary expressions vs. a (possibly qualified) name? A class factory that produces forward declarations? Do you have a use case in mind? It's: x.py: --8< forward class A() --8< x_impl.py

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/25/2022 1:10 PM, Jim J. Jewett wrote: (That said, my personal opinion is that this is pretty heavyweight for very little gain; why not just create a placeholder class that static analysis tools are supposed to recognize as likely-to-be-replaced later? And why not just use strings giving

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/25/2022 9:13 PM, Mehdi2277 wrote: We could have forward part include all of method signatures/attributes which is what a type checker needs. In theory we could do, forward class Foo: x: int y: list[str] def __init__(self, ...) def process(self, data: list[float]) -> float

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

How would runtime consumers of annotations use this? -- Eric > On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg wrote: > > If the problem is mostly type annotations, then another potential > solution would be to make use of .pyi files, which are not hamstrung by > circular definitions. The ide

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

> On Apr 26, 2022, at 3:05 PM, Thomas Kehrenberg wrote: > >  > Apr 26, 2022 20:32:55 Eric V. Smith : > >> How would runtime consumers of annotations use this? >> >> -- >> Eric >> >>>> On Apr 26, 2022, at 12:05 PM, Thomas K

[Python-Dev] Re: Raw strings ending with a backslash

On 5/28/2022 7:57 AM, Damian Shaw wrote: That PR seems to make \' and \" not special in general right? I think this is a more limited proposal, to only change the behavior when \ is at the end of a string, so the only behavior difference would never receiving the error "SyntaxError: EOL while

[Python-Dev] Re: Is it possible to view tokenizer output?

python -m tokenize < file-to-parse.py See the comment at the top of tokenize.py. IIRC, it re-implements the tokenizer, it does not call the one used for python code. Eric On 5/29/2022 6:59 PM, Jack wrote: Hi, I'm just getting into the CPython codebase just for fun, and I've just started mess

[Python-Dev] Re: PEP 572 TargetScopeError

On 8/8/2019 7:28 PM, Barry Warsaw wrote: On Aug 8, 2019, at 14:58, Steven D'Aprano wrote: It's not a syntax error. There's nothing wrong with the syntax per-say: we still have ``target := expression``. There's a problem with the *semantics* not the syntax. I’m not sure that distinction is me

[Python-Dev] Re: PEP 572 TargetScopeError

On 8/9/2019 11:41 AM, Tim Peters wrote: [Guido] I don't see how this debate can avoid a vote in the Steering Council. FWIW, I found Nick's last post wholly persuasive: back off to SyntaxError for now, and think about adding a more specific exception later for _all_ cases (not just walrus) in

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

On 8/9/2019 2:28 PM, Jonathan Goble wrote: On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: I find the "Our deprecation warnings were even less visible than normal" argument for extending the deprecation period compelling. Outsider's 2 cents from reading this discussion (with no personal ex

[Python-Dev] Re: An f-string issue [Was: Re: Re: What to do about invalid escape sequences]

n 8/10/2019 7:46 PM, Glenn Linderman wrote: Because of the "invalid escape sequence" and "raw string" discussion, when looking at the documentation, I also noticed the following description for f-strings: Escape sequences are decoded like in ordinary string literals (except when a literal is

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

On 8/10/2019 10:30 PM, Rob Cliffe via Python-Dev wrote: On 10/08/2019 23:30:18, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that f

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

On 8/11/2019 4:18 PM, Glenn Linderman wrote: On 8/11/2019 2:50 AM, Steven D'Aprano wrote: On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: Or invent "really raw" in some spelling, such as rr"c:\directory\" or e for exact, or x for exact, or "c:\directory\" And that brings me t

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

On 8/12/2019 2:52 AM, Greg Ewing wrote: Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple prefixes combine in the way you wo

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

On 8/14/2019 11:02 AM, Random832 wrote: On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: Please no more combinations. The presence of both legal and illegal combinations is already a mild nightmare for processing and testing. idlelib.colorizer has the following re to detest legal combination

[Python-Dev] Re: python3 -bb and hash collisions

On 9/10/2019 2:12 PM, Chris Angelico wrote: On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth wrote: On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka wrote: 22.06.19 01:08, Daniel Holth пише: Thanks. I think I might like an option to disable str(bytes) without disabling str != bytes. Unless th

[Python-Dev] Re: The Python 2 death march

I think Ned's concerns are real, and the sunset-python-2 page could use some wordsmithing to explain that even though support ends on Jan 1, there will be a wrap-up release some time after that, but it won't incorporate any changes made or proposed after Jan 1. Another place where that documen

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 9/29/2019 5:13 PM, Victor Stinner wrote: It seems simpler to me to pass the structure size rather than the Python version. It avoids the risk of updating the structure without update the Python version. I also avoids to have to change the Python version immediately when PyConfig is modified.

[Python-Dev] Re: Migrate typing in builtin

Ivan (who you cc'd) is a good start! Eric On 10/8/2019 8:35 AM, Philippe Prados wrote: Glups. I am not an expert of Pyhton source code. May be after this patch ;-) I think I should discuss with the authors of the module typing, to identify the best strategy. Who is he ? Philippe Le mar.

[Python-Dev] Re: Pass the Python thread state to internal C functions

On 11/12/2019 5:03 PM, Victor Stinner wrote: Hi, Are you ok to modify internal C functions to pass explicitly tstate? The last time we discussed this, there was pushback due to performance concerns. I don't recall if that was actually measured, or just a vague unease. I've long advocated (

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/2019 3:35 PM, Christian Heimes wrote: On 03/12/2019 21.04, Ethan Furman wrote: On 12/03/2019 09:31 AM, Guido van Rossum wrote: I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated. I'm happy to go wit

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

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

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

[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. https://docs.python.org/3/library/stdtypes

[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, '.

[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 ==&#x

[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 (2020-01-0

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

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

[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: https://mail.python.org/archives/list/python-id...@py

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

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

7;s no way to tell if the strip/cut/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 Fa

[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

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 implemento

[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

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 ab

[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/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 consensu

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

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

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

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

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

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

[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, s

[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] 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: Map errno==ETIME to TimeoutError

nds 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/man-page

[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

ty. E.g. in 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 &

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

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

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

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

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

[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, but not

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

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

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

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

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

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

Search for “Larry Hastings gilectomy”. For example, there’s this: https://speakerdeck.com/pycon2017/larry-hastings-the-gilectomy-hows-it-going -- Eric V. Smith (301) 502-0945 cell > On Sep 1, 2020, at 12:21 PM, Raihan Rasheed Apurbo wrote: > > Before experimenting can't I ask s

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

On 9/2/2020 1:23 PM, Raihan Rasheed Apurbo wrote: Thank you, sir. Guido already mentioned it so I was going to search google about it. Thanks for your direct link as well. I really appreciate it. I will surely look into that. :) No problem. It would also help if you included a little contex

[Python-Dev] Re: Farewell, Python 3.5

Thanks for all of your work, Larry. I really think it was the stability of these releases that helped push 3.x into dominance over 2.7. 3  version control systems. Insane! Eric On 10/1/2020 1:49 PM, Larry Hastings wrote: At last!  Python 3.5 has now officially reached its end-of-life.  Sin

[Python-Dev] Shutting down Import-SIG mailing list?

Would anyone care if Import-SIG was shut down? It gets a few spam emails per day that need to be cleaned up. It hasn't had any real messages for a couple of years. I think if the discussions were moved to python-dev it wouldn't be a noticeable increase in traffic. We'd want to keep it around f

[Python-Dev] Re: Shutting down Import-SIG mailing list?

the list down, retaining the archives read-only for posterity. -Barry > On Oct 13, 2020, at 09:26, Eric V. Smith mailto:e...@trueblade.com>> wrote: > > Would anyone care if Import-SIG was shut down? It gets a few spam emails per day that need to be cleaned u

[Python-Dev] datetime's strftime implementation: by design or bug

[I hope this belongs on python-dev, since it's about the design of something. But if not, let me know and I'll post to c.l.py.] I'm willing to file a bug report and patch on this, but I'd like to know if it's by design or not. In datetimemodule.c, the function wrap_strftime() insists that the

Re: [Python-Dev] datetime's strftime implementation: by design or bug

Anthony Baxter wrote: > Please log a bug - this is probably something suitable for fixing in 2.5.1. > At > the very least, if it's going to be limited to 127 characters, it should > check that and raise a more suitable exception. [First time sent from wrong address, sorry if this is a dupe.]

[Python-Dev] Access to bits for a PyLongObject

I'm working on PEP 3101, Advanced String Formatting. About the only built-in numeric formatting I have left to do is for converting a PyLongOjbect to binary. I need to know how to access the bits in a PyLong. After reading longobject.c, I can figure it out. But I'm looking for something that

Re: [Python-Dev] Access to bits for a PyLongObject

Martin v. Löwis wrote: > Eric V. Smith schrieb: >> I'm working on PEP 3101, Advanced String Formatting. About the only >> built-in numeric formatting I have left to do is for converting a >> PyLongOjbect to binary. >> >> I need to know how to access the bit

Re: [Python-Dev] Access to bits for a PyLongObject

Martin v. Löwis wrote: > Ah, I had missed the point that it's just binary formatting that > you are concerned with (and then I missed that binary is "base 2", > rather than "sequence of bits") Apologies for not being clear. It's easy to forget that others don't share the context of something you

Re: [Python-Dev] About SSL tests

[sorry if you see 2 copies of this] Facundo Batista wrote: > The problem of TerminateProcess is that I need the handle of the > process. > > I don't like the idea of rely on the private _handle and do: > > process = subprocess.Popen(...) > ... > subprocess.TerminateProcess(int(process._han

Re: [Python-Dev] About SSL tests

Facundo Batista wrote: > Eric V. Smith wrote: > >> Would it not be better to put a platform-independent version of this >> into subprocess, so that this code doesn't have to be duplicated all >> over the place? Maybe a method on a Popen object called terminate()?

Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing

Jim Jewett wrote: > Rationale for Removing Implicit String Concatenation > > Implicit String concatentation can lead to confusing, or even > silent, errors. [1] > > def f(arg1, arg2=None): pass > > f("abc" "def") # forgot the comma, no warning ... >

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On 07/20/2011 08:57 AM, P.J. Eby wrote: > At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote: >> On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote: >> > So, without further ado, here it is: >> >> I pushed this version up to the PEPs repo, so it now has a number >> (402) and can be read in prettier HTML

Re: [Python-Dev] cpython (3.2): NUL -> NULL

On 08/18/2011 02:19 PM, Antoine Pitrou wrote: > On Thu, 18 Aug 2011 17:49:28 +0200 > benjamin.peterson wrote: >> -PyErr_SetString(PyExc_TypeError, "embedded NUL character"); >> +PyErr_SetString(PyExc_TypeError, "embedded NULL character"); > > Are you sure? IIRC, NUL is the little

Re: [Python-Dev] [Python-checkins] cpython: Implement PEP 393.

Is there some reason str.format had such major surgery done to it? It appears parts of it were removed from stringlib. I had not even thought to look at the code before it was merged, as it never occurred to me anyone would do that. I left it in stringlib even in 3.x because there's the occasional

Re: [Python-Dev] [Python-checkins] cpython: Implement PEP 393.

On 10/1/2011 9:26 AM, "Martin v. Löwis" wrote: > Am 29.09.2011 01:21, schrieb Eric V. Smith: >> Is there some reason str.format had such major surgery done to it? > > Yes: I couldn't figure out how to do it any other way. The formatting > code had a few basic as

Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit

What's the logic for adding some braces, but removing others? On 10/19/2011 4:58 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9c79a25f4a8b > changeset: 73010:9c79a25f4a8b > branch: 3.2 > parent: 72998:99a9f0251924 > user:Benjamin Peterson > date:Wed

Re: [Python-Dev] Packaging and binary distributions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 5:14 PM, Tres Seaver wrote: > On 10/30/2011 02:04 PM, Ned Deily wrote: >> In article >> , > >> > > Paul Moore wrote: > >>> I'd like to reopen the discussions on how the new packaging >>> module will handle/support binary distributio

Re: [Python-Dev] [Python-checkins] cpython (2.7): Inline the advisory text on how to use the shelve module.

On 11/4/2011 4:08 PM, raymond.hettinger wrote: > - .. note:: > + Like file objects, shelve objects should closed explicitly to assure > + that the peristent data is flushed to disk. Missing "be" there, I think: "should be closed". Eric. ___ Pytho

Re: [Python-Dev] [Python-checkins] cpython (2.7): Inline the advisory text on how to use the shelve module.

On 11/4/2011 4:25 PM, Ezio Melotti wrote: > On 04/11/2011 22.21, Eric V. Smith wrote: >> On 11/4/2011 4:08 PM, raymond.hettinger wrote: >> >>> - .. note:: >>> + Like file objects, shelve objects should closed explicitly to assure >>> + that the per

Re: [Python-Dev] str.format implementation

On 12/12/2011 10:56 PM, Ben Wolfson wrote: > Hi, > > I'm hoping to get some kind of consensus about the divergences between > the implementation and documentation of str.format > (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and > the linked bug report contain examples of the

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

On 1/28/2012 2:10 AM, Nick Coghlan wrote: > On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull > wrote: >> Executive summary: >> >> If the promise to remove the module from __preview__ is credible (ie, >> strictly kept), then __preview__ will have a specific audience in >> those who want the st

Re: [Python-Dev] PEP 409 - final?

On 2/1/2012 7:49 PM, Nick Coghlan wrote: > On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney > wrote: >>> 3) Should it be an exception, or just inherit from object? >>> Is it worth worrying about somebody trying to raise it, or >>> raise from it? >> >> If it's not actually an exception, we get prev

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On 2/25/2012 11:18 AM, Zachary Ware wrote: > Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I > agree that the extra versioning info could get pretty awkward. > Therefore, why not just make stdlib upgrades part of the regular > maintenance releases? As long as there is absolutel

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On 2/25/2012 11:50 AM, Antoine Pitrou wrote: >> The problem is that you can't say "my code works on Python 3.3". You now >> have to specify the micro version number as well: "my code works on >> Python 3.3.1+". We've made this mistake before; I can't see it happening >> again. > > I don't see how

<    1   2   3   4   5   6   >