Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

:05AM -0700, Steve Dower wrote: > On 23May2019 2355, Steven D'Aprano wrote: > >I don't know if this is a good idea or a terrible idea or somewhere in > >between, so I'm throwing it out to see if anyone likes it. > > > >Let's add a third option to PEP 594 between "k

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

On Wed, Jun 05, 2019 at 11:08:13AM +0200, Victor Stinner wrote: > Hi, > > Our kind postmasters Mark Sapiro and Abhilash Raj migrated > python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3 > (running on Python 3 ;-))! Great! But email footers are currently broken: > Python-Dev

Re: [Python-Dev] Overloading comparison operator for lists

Hi Montana, As Cameron Simpson already pointed out, your query is off-topic for the Python-Dev mailing list and should be taken to the Python-Ideas mailing list, which is for speculative discussion of new designs. Like Cameron, I've CCed Python-Ideas. Please send any follow-ups to that list

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Tue, May 28, 2019 at 08:37:17AM +0100, Paul Moore wrote: > Of course, all of this is only if we have decided to formalise the > semantics and change CPython to conform. I've never personally been > affected by any of the edge cases with locals(), so on a purely > personal basis, I'm equally

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

On Wed, Jun 05, 2019 at 11:08:13AM +0200, Victor Stinner wrote: > Enhancements: > * More reliable "permalink" URLs to emails This is excellent... but the old pipermail URLs were typically something like 70-80 characters, which means they fit nicely into emails (and comments in source code).

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote: > Armin Rigo wrote: > >You have the occasional big function that benefits a lot from being > >JIT-compiled but which contains ``.format(**locals())``. > > There should be a lot less need for that now that we have f-strings. I think

[Python-Dev] Re: Enum and annotations

On Mon, Jun 10, 2019 at 02:29:56PM -0700, Ethan Furman wrote: > Greetings! > > I saw my first annotation mix-up with regards to Enum today: [...] I don't think this is particular to Enums. I think this is going to be a stumbling block for any class. py> class X: ... a: 1 ... b: 2 ...

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

Let me be clear: I do not oppose the removal of modules where necessary, but I do not like this PEP as it stands. But full credit to Christian for graciously accepting feedback; I also acknowledge that if this PEP is accepted, we still have at least two releases to change our minds about

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 01:59:59PM +0900, Stephen J. Turnbull wrote: > This looks to me like an opening to a special class of supply chain > attacks. [...] > One thing we *could* do that would require moderate effort would be to > put them up on PyPI ourselves, and require that would-be

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue, May 21, 2019 at 01:59:56PM -0400, Terry Reedy wrote: > On 5/21/2019 9:01 AM, Steven D'Aprano wrote: > ... > >Many Python users don't have the privilege of being able to install > >arbitrary, unvetted packages from PyPI. They get to use only packages > >from app

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 10:07:31AM +0200, Christian Heimes wrote: > On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > > It is possible to have a modern Linux desktop system with PAM not > > installed at all, and therefore not used. [...] Christian wrote: > Thanks for bringing

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue, May 21, 2019 at 01:13:30PM -0400, Edwin Zimmerman wrote: [...] [-- Attachment #2: winmail.dat --] [-- Type: application/ms-tnef, Encoding: base64, Size: 8.4K --] Wow! I haven't see one of those for *years* -- I haven't noticed one for about 15 years, and I thought it was an obsolete

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: > On 22/05/2019 12.19, Steven D'Aprano wrote: > > I don't think this PEP should become a document about "Why you should > > use PAM". I appreciate that from your perspective as a Red Hat security > >

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote: > On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch < > sean.wallit...@dreamworks.com> wrote: > > > My apologies for that oversight. My understanding is that many of the > > methods present in aifc depend heavily on audioop for reading

[Python-Dev] PEP 594 - a proposal for unmaintained modules

I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained. Unmaintained modules: - will raise a warning when

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

The PEP title is prejudicial and inaccurate. These aren't "dead batteries", these are *working batteries* that you want to remove. If you want a fair and open debate on this, please change the title to something less prejudicial. If this were my PEP, I'd call it "Removing unloved batteries

Re: [Python-Dev] Parser module in the stdlib

On Mon, May 20, 2019 at 08:55:59AM -0700, Guido van Rossum wrote: > I am interested in switching CPython's parsing strategy to something else > (what exactly remains to be seen) Are you re-thinking the restriction to LL(1) grammars? -- Steven ___

Re: [Python-Dev] Adding a toml module to the standard lib?

On Wed, May 15, 2019 at 09:35:16PM +1000, Steven D'Aprano wrote: > It isn't very long (only about a dozen or so quite short posts) but you > probably ought to be at least familiar with it, and if possibly respond > to any opposing comments. Sorry, to clarify, I don't mean respond on t

Re: [Python-Dev] Adding a toml module to the standard lib?

On Wed, May 15, 2019 at 10:44:35AM +0200, Bastian Venthur wrote: > Hi, > > I'd like to discuss the idea to add a module to parse TOML [toml-lang] > to Python's standard library. You ought to read this thread here: https://mail.python.org/pipermail/python-ideas/2018-October/054101.html It

Re: [Python-Dev] Definition of equality check behavior

On Tue, May 07, 2019 at 05:05:57PM -0400, Jordan Adler wrote: [...] > Specifically, a comparison between a primitive (int, str, float were > tested) and an object of a different type always return False, instead of > raising a NotImplementedError. Consider `1 == '1'` as a test case. I think you

Re: [Python-Dev] Definition of equality check behavior

On Wed, May 08, 2019 at 12:05:07AM +0200, Max Vogler wrote: > Thanks for starting this discussion and addressing my issue, Jordan. > > I would like to clarify the intentions behind my original issue > : It does not > concern coercion in

Re: [Python-Dev] Easier debugging with f-strings

Disclaimer: this topic seems to have been split over at least two issues on the bug tracker, a Python-Ideas thread from 2018, Discourse (I think...) and who knows what else. I haven't read it all, so excuse me if I'm raising something already discussed. On Mon, May 06, 2019 at 08:39:41PM

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

On Fri, May 03, 2019 at 10:46:03PM -0400, Eric V. Smith wrote: > Is there a policy against using Unicode identifiers in test files? [...] > I could work around this with exec-ing some strings, but that seems like > added confusion that I'd avoid with a real Unicode identifier. "Look, that's why

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On Fri, Jun 28, 2019 at 01:08:45AM +1000, Chris Angelico wrote: > Help on built-in function lstrip: [...] > This does NOT remove a leading substring. It removes a set of characters. This is a re-occurring painpoint and gotcha. I've fallen for it myself. I really think it's long past time we

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

On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > You have missed at least one: the minimum technology requirement for > > using Github is a lot more stringent than for Roundup. Github's minimum > > system requirements are higher, and it doesn't degrade as well, so > > moving to

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On Mon, Apr 22, 2019 at 10:06:20AM -0700, Chris Barker via Python-Dev wrote: > maybe a new dict mapping type -- "shared_dict" -- it would be used in > places like the csv reader where it makes sense, but wouldn't impact the > regular dict at all. > > you could get really clever an have it

Re: [Python-Dev] (no subject)

Hi Robert, This mailing list is for the development of the Python interpreter, not a general help desk. There are many other forums where you can ask for help, such as the comp.lang.python newsgroup, Stackoverflow, /r/python on Reddit, the IRC channel, and more. Perhaps you can help us

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

On Fri, Jun 28, 2019 at 09:56:26AM -0700, Mariatta wrote: > Hi, > > I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section. > > https://www.python.org/dev/peps/pep-0581/#downsides-of-github You have missed at least one: the minimum technology requirement for using Github is

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

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 here>"c:\directory\" > > And that brings me to the thought that if   \e  wants to become an > escape for escape, that maybe

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

On Wed, Sep 11, 2019 at 09:34:07AM -0400, Daniel Holth wrote: > I didn't realize you could override __builtins__.str. That's interesting. Don't touch __builtins__ that's a CPython implementation detail. The public API is to ``import builtins`` and use that. This override technique is called

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

On Tue, Aug 06, 2019 at 07:58:12PM -0700, Nathaniel Smith wrote: > For example, all my projects run tests with deprecation warnings > enabled and warnings turned into errors, but I never saw any of these > warnings. What happens is: the warning is issued when the .py file is > byte-compiled; but

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

On Wed, Aug 07, 2019 at 10:14:08AM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote: > > - Keep the SyntaxWarning silent by default for 3.8. That gives us > > another year or more to gently pressure third-party libraries to fix > > their c

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

On Wed, Aug 07, 2019 at 02:33:51PM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote: > > Don't think of this as a failure. Think of it as an opportunity: we've > > identified a weakness in our deprecation process. Let's fix that > &g

[Python-Dev] Re: Comparing dict.values()

On Sun, Jul 28, 2019 at 10:18:56PM +0200, Antoine Pitrou wrote: > On Fri, 26 Jul 2019 20:28:05 +1000 > Steven D'Aprano wrote: > > So there are no conceptual problems in defining equality for value > > views. Putting aside efficiency, this is easy to solve. > > R

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

On Tue, Aug 06, 2019 at 08:14:35AM +0200, Michael wrote: > For "filenames" you could, perhaps, make an exception in the calls that > use them. e.g., when they are hard-coded in something such as > open("..\training\new_memo.doc"). Functions such as open cannot tell whether their argument was

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

This really is a hairy one. The current behaviour encourages people to use a single backslash when they should be using a double, but that works only sometimes. Should you include an escape or not? Sometimes the backslash stays and sometimes it disappears: py> "abc \d \' xyz" "abc \\d ' xyz"

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

On Wed, Aug 07, 2019 at 10:41:25AM +1200, Greg Ewing wrote: > Rob Cliffe via Python-Dev wrote: > > > >Sorry, that won't work. Strings are parsed at compile time, open() is > >executed at run-time. > > It could check for control characters, which are probably the result > of a backslash

[Python-Dev] Re: PEP 572 TargetScopeError

On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote: > "The two invalid cases listed above raise TargetScopeError, a new > subclass of SyntaxError (with the same signature).” > > The PEP doesn’t really go into the rationale for why a new exception > is being defined, and in the issue

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

On Wed, Aug 07, 2019 at 07:47:45PM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote: > > What's the rush? Let's be objective here: what benefit are we going to > > get from this change? Is there anyone hanging out desperately for "\d&quo

[Python-Dev] Re: PEP 572 TargetScopeError

On Thu, Aug 08, 2019 at 04:28:28PM -0700, 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 > > *s

[Python-Dev] Re: PEP 572 TargetScopeError

On Fri, Aug 09, 2019 at 01:16:16AM +0100, Rob Cliffe via Python-Dev wrote: > >The name is perfectly self-descriptive: TargetScopeError means that > >there's an error with the scope of the target. What else could it mean? > That's easy for an experienced programmer to say. Correct. Why should we

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

On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote: > The reason I never use raw strings is in the documentation, it is > because \ still has a special meaning, and the first several times I > felt the need for raw strings, it was for directory names that wanted to > end with \

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

On Fri, Aug 09, 2019 at 02:28:13PM -0400, Jonathan Goble wrote: > I am perplexed at the opinion, seemingly espoused by multiple people > in this thread, that because a major part of the problem is that the > warnings were not visible enough, somehow the proposed solution is > making them not

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

I'm not trying to be confrontational, I'm trying to understand your use-case(s) and see if it would be broken by the planned change to string escapes. On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote: > On 8/9/2019 2:53 PM, Steven D'Aprano wrote: > >On Fri, Aug 09, 2019

[Python-Dev] Re: What is a public API?

On Sat, Jul 20, 2019 at 06:03:39AM -, Kyle Stanley wrote: > Rather than it being on a case-by-case basis, would it be reasonable > to establish a universal standard across stdlib for defining modules > as public to apply to older modules as well? No, I don't think so. That would require

[Python-Dev] Re: What is a public API?

On Mon, Jul 22, 2019 at 10:02:12PM -, Kyle Stanley wrote about renaming non-public names with a leading underscore: > Good point, this would probably have to be a gradual change if it did > happen, rather than being at all once. If it were to happen with a > proper deprecation cycle and

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

Hi Karl, Email should not have a latency of "several hours" unless there is something seriously wrong, perhaps your mail server (your ISP?) is broken. Or possibly you're still being moderated: we recently changed to moderating newcomers, in response to a flurry of spam. As a newcomer to this

[Python-Dev] Re: Comparing dict.values()

On Tue, Jul 23, 2019 at 08:59:09PM -, Kristian Klette wrote: > Hi! > > During the sprints after EuroPython, I made an attempt at adding support for > comparing the results from `.values()` of two dicts. > > Currently the following works as expected: > > ``` > d = {'a': 1234} > > d.keys()

[Python-Dev] Re: Comparing dict.values()

On Tue, Jul 23, 2019 at 10:02:34PM -0400, Terry Reedy wrote: [...] > If one has not learned the default meaning of '==' in Python. Perhaps > this should be given more emphasis in beginner courses. "What does it > mean for two object to be 'equal'?" It is not a trivial question. No, it is

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 05:30:19PM -, Brett Cannon wrote: > When I saw this I thought, "it should be like `set(d1.values()) == > set(d2.values())`", but has been pointed out there's no guarantee that > all values will be hashable. The hashability requirement for sets is, in a sense, an

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019 at 12:57:42AM -0400, Random832 wrote: > On Fri, Jul 26, 2019, at 00:22, Ivan Pozdeev via Python-Dev wrote: > > Since a hash table is an unordered container and keys(), items() and > > values() are iterators over it, *I would expect the results of any of > > the comparisons

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 08:25:31PM -0400, David Mertz wrote: > Exactly! that was my thought that the exception message could hint at > likely approaches. The NumPy example seems to have a good pattern: > > arr1 == arr2 > > ValueError: The truth value of an array with more than one element is >

[Python-Dev] Re: Comparing dict.values()

On Thu, Jul 25, 2019 at 05:53:47PM +0200, Antoine Pitrou wrote: > On Wed, 24 Jul 2019 19:09:37 -0400 > David Mertz wrote: > > > > There are various possible behaviors that might make sense, but having > > `d.values() != d.values()` is about the only one I can see no sense in. > > Why? Does the

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 12:36:29PM +0200, Ronald Oussoren wrote: > > > Op 24 jul. 2019 om 02:27 heeft Steven D'Aprano het > volgende geschreven: > > > But I can suggest at least one useful invariant. If a, b are two dicts: > > > >a.items() == b.items(

[Python-Dev] Re: Comparing dict.values()

On Thu, Jul 25, 2019 at 10:15:15AM +1200, Greg Ewing wrote: > What I'm getting from this thread is that there are a variety of > possible behaviours for dict values comparison, any of which could > be considered "correct" depending on what the programmer is trying > to do. Can you elaborate on

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019 at 08:41:40PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > The hashability requirement for sets is, in a sense, an implementation > > detail. It might be a requirement for sets in Python the language, > > but its not a requir

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

On Fri, Dec 06, 2019 at 11:10:49AM +, Paul Moore wrote: [...] > > They might end up with a million dynamically created classes, each with > > a single instance, when what they wanted was a single class with a > > million instances. > > But isn't that the point here? A limit would catch this

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

On Mon, Dec 09, 2019 at 11:27:56PM -0500, Kyle Stanley wrote: > I agree, I think that sys would likely be the most reasonable place to read > these limits from. Also, it seems like a good location for setting of the > limits, if that becomes an option. This would go along well with the > existing

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

On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote: > > > On 09/12/2019 2:15 pm, Chris Angelico wrote: > > You: "We should limit things. Stuff will be faster." > > Others: "Really? Because bit masking is work. It'll be slower." I'm not an expert, but the impression I've got from

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

On Sat, Dec 07, 2019 at 07:37:58PM +, Oscar Benjamin wrote: > I recently hit on a situation that created a one million line code file: > https://github.com/pytest-dev/pytest/issues/4406#issuecomment-439629715 > > The original file (which is included in SymPy) has 3000 lines > averaging 500

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

On Wed, Dec 11, 2019 at 10:30:15PM -0500, Richard Damon wrote: > I will way that in my many years of > programming experience I can't think of any great cases where a language > as part of the language definition limited to 'size' of a program to > good effect, Good thing that's not what the PEP

[Python-Dev] Documenting sorted/min/max prerequisites

The list.sort method is documented to only use less than: https://docs.python.org/3/library/stdtypes.html#list.sort but I don't think that is correct, it seems to use greater than if it exists and less than doesn't. My understanding is that items need to define one of l.t. or g.t. to make it

[Python-Dev] Re: Documenting sorted/min/max prerequisites

On Sat, Dec 14, 2019 at 02:40:04PM +0200, Serhiy Storchaka wrote: > 14.12.19 12:45, Steven D'Aprano пише: > >The list.sort method is documented to only use less than: > > > >https://docs.python.org/3/library/stdtypes.html#list.sort > > > >but I don't think that is

[Python-Dev] Re: Documenting sorted/min/max prerequisites

On Sat, Dec 14, 2019 at 04:20:43PM +0200, Serhiy Storchaka wrote: > 14.12.19 15:29, Steven D'Aprano пише: > >I might be misinterpreting the evidence, but sorting works on objects > >that define `__gt__` without `__lt__`. [...] > The `<` operator try to use `__lt__`, but if it

[Python-Dev] Re: Should set objects maintain insertion order too?

On Sun, Dec 15, 2019 at 09:00:31PM -0800, Larry Hastings wrote: > I think we should decide the question "should set > objects maintain insertion order?" literally without any consideration > about performance implications. In your opening post: > I also want FAST lookup because I soemtimes

[Python-Dev] Re: More feedback on PEP 611, please

On Wed, Dec 11, 2019 at 11:12:59AM +, Mark Shannon wrote: > Another thing I would like feedback on this: > My justification for a single limit of one million across the board is > to ease memorization and learning. > Is that sufficient justification, or would differing limits be better? Why

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

Although I am cautiously and tentatively in favour of setting limits if the benefits Mark suggests are correct, I have thought of at least one case where a million classes may not be enough. I've seen people write code like this: for attributes in list_of_attributes: obj =

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

I'm going to second Chris' comment about efficiency. The purposes of this PEP (as I read it) are: (1) Security (less chance of code intentionally or accidentally exceeding low-level machine limits that allow a security exploit); (2) Improved memory use; (3) And such improved memory use will

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

On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote: > Integer sizes are a classic example of this. Is it acceptable to limit > your integers to 2^16? 2^32? 2^64? Python made the choice to NOT limit > its integers, and I haven't heard of any non-toy examples where an > attacker causes

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote: > On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote: > > > > The only thing I'm unsure of here is whether direct use of the `==` and > > `!=` operators are included as "implicit calls" to the dund

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote: > On 1/24/2020 3:36 AM, Victor Stinner wrote: > >CPython current behavior rely on the fact that it's possible to get > >the memory address of an object. > > No, this behavior relies on the language specification that all objects >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Thu, Jan 23, 2020 at 07:29:58PM -0600, Tim Peters wrote: > PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x > and y are the same object, then equality comparison returns True and > inequality False. No attempt is made to execute __eq__ or __ne__ > methods in those cases. >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote: > >I'm tempted to declare this implementation-defined behavior -- *implicit* > >calls to __eq__ and __ne__ *may* be skipped if both sides are the same > >object depending on the whim of the implementation. > > This

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Mon, Feb 03, 2020 at 05:26:38PM -0800, Sebastian Berg wrote: > 1. `==` has of course the logic `NaN == NaN -> False` > 2. `PyObject_RichCompareBool(a, b, Py_EQ)` was argued to have a useful >logic of `a is b or a == b`. And I argued that you could define: > >def

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote: [Sebastian Berg] > > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental > > operation (and in a sense it seems to me that it is), is there a point > > in explicitly defining it? > > > > That would mean adding

[Python-Dev] Re: PEP 584: Add Union Operators To dict

Thank you to everyone for your patience while I dragged my feet responding to this. It's not because of a lack of interest, just a lack of uninterrupted time to focus on this :-) I believe that the final sticking points are the behaviour with subclasses and whether or not the union operator

[Python-Dev] Re: PEP 584: Add Union Operators To dict

On Sun, Feb 16, 2020 at 02:12:48PM -0800, Guido van Rossum wrote: > So can we just finish PEP 584 without the .copy() call? Fine by me. Thanks to everyone! -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote: > > I am accepting this PEP. Congratulations Steven and Brandt! > > Thank you for your guidance, especially the suggestions late last > year. And thanks Steven for taking me on as a co-author and shaping > the bulk of the proposal.

[Python-Dev] Re: Differences in what lint (e.g., mypy, flake8, etc) require from new code and what Cpython uses/returns - e.g., strings with single/double quotes.

Hi Michael, and welcome! On Thu, Jan 09, 2020 at 11:37:33AM +0100, Michael wrote: > I am not questioning the demands of the lint checker - rather - I am > offering my services (aka time) to work through core to make CPython > pass it's own (I assume) PEP recommendations or guidelines. That

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

On Mon, Jan 20, 2020 at 09:59:07PM -0600, Karl O. Pinc wrote: > It would be nice if the output format for float was documented, to the > extent this is possible. I don't think we should make any promises about the repr() of floats. We've already changed the format at least twice: - once to

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

On Tue, Jan 21, 2020 at 09:01:29AM -0600, Karl O. Pinc wrote: > Understood. But you still might want to document, or even define in the > language, that you're outputting the shortest unambiguous > representation. I'm not even sure I would want to do that. That would make it a language

[Python-Dev] Re: PEP 587

Hi Zak, and welcome! This list is for discussing the current and future development of the CPython interpreter, not a general help-desk for Python beginners. When you signed up to this email list, the signup page says: Do not post general Python questions to this list. For help with

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

On Mon, Apr 06, 2020 at 10:43:11AM -0700, Guido van Rossum wrote: > I've been toying with the idea of introducing a "match" statement > similar to Scala's match expression by making "match" a keyword only when > followed by an expression and a colon.) Didn't we conclude from `as` that having

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

On Mon, Apr 06, 2020 at 07:03:30PM -0700, Guido van Rossum wrote: > After 30 years am I not allowed to take new information into account and > consider a change of heart? :-) Of course :-) -- Steven ___ Python-Dev mailing list --

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

On Mon, Apr 06, 2020 at 11:54:54AM -0700, Guido van Rossum wrote: > (In an early version of the PEG parser, all keywords were > context-sensitive, and there were only very few places in the grammar where > this required us to insert negative lookaheads to make edge cases parse > correctly. The

[Python-Dev] Re: Python2 as 푣 → 푒

On Sat, Apr 11, 2020 at 03:17:07PM -0700, Mike Miller wrote: > Python as 푣 → 푒 > Python ≈ 푒 For anyone else who had trouble seeing those glyphs, the ASCII equivalent is: Python as v --> e Python ~= e with the v and e in italics and the ~= meaning "approximately equal". --

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

On Tue, Mar 24, 2020 at 07:14:16PM +0100, Victor Stinner wrote: > I would prefer to raise ValueError("empty separator") to avoid any > risk of confusion. I'm not sure that str.cutprefix("") or > str.cutsuffix("") does make any sense. They make as much sense as any other null-operation, such as

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

On Sat, Mar 28, 2020 at 01:20:11PM +0200, Serhiy Storchaka wrote: > 2. In many case it is more convenient to have a repr in the form > Color.RED or even just RED instead of . +1 -- Steven ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Re: reversed enumerate

Hi Ilya, I'm not sure that this mailing list (Python-Dev) is the right place for this discussion, I think that Python-Ideas (CCed) is the correct place. For the benefit of Python-Ideas, I have left your entire post below, to establish context. [Ilya] > I needed reversed(enumerate(x: list)) in

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

On Tue, Mar 24, 2020 at 04:53:55PM +0100, Walter Dörwald wrote: > But for `cutprefix()` (or whatever it's going to be called). I'm +1 on > supporting multiple prefixes. For ambiguous cases, IMHO the most > straight forward option would be to chop off the first prefix found. The Zen of Python

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

On Fri, May 15, 2020 at 08:17:12AM +0100, Paul Moore wrote: > 1. Why do we want to "tempt" people to error when handling mismatched > lengths? Certainly letting people catch errors easily is worthwhile, > but rejecting arguments of different lengths may well *not* be an > error ("be lenient in

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

On Fri, May 15, 2020 at 09:56:03AM -0400, Paul Ganssle wrote: > I'm on the fence about using a separate function vs. a keyword argument > (I think there is merit to both), but one thing to note about the > separate function suggestion is that it makes it easier to write > backwards compatible code

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

On Wed, May 13, 2020 at 03:04:02PM +0200, 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 > > the flag is False? > > Why would it? Is that based on a rational analysis of how

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

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 to > >decide when it is OK to return self or

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

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 > > ``cutsuffix``, to the APIs of Python's various string objects. > > The names should use "start" and

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

On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev wrote: > Does it need to be separate methods? Yes. Overloading a single method to do two dissimilar things is poor design. > As written in the PEP preface, the very reason for the PEP is that people > are continuously

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

On Sun, Mar 22, 2020 at 10:25:28PM -, Dennis Sweeney wrote: > Changes: > - More complete Python implementation to match what the type checking in > the C implementation would be > - Clarified that returning ``self`` is an optimization > - Added links to past discussions on

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

On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote: > I think my confusion is about just how precise this sort of "reference > implementation" should be. Should it behave with ``str`` and ``tuple`` > subclasses exactly how it would when implemented? If so, I would expect the >

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

On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote: > I think then maybe it would be preferred to > use the something like the following in the PEP: > > def cutprefix(self, prefix, /): > if isinstance(prefix, str): > if self.startswith(prefix): >

[Python-Dev] Re: Resurrecting PEP-472

Okay, thanks everyone who answered. In hindsight you are all correct, writing a new PEP is the best solution and I was being over-optimistic (and a little lazy) to think otherwise. I think that, technically, I still have core dev permissions, even though I haven't used them for quite some

<    8   9   10   11   12   13   14   15   16   >