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

On Tue, 2020-02-04 at 13:44 +1100, Steven D'Aprano wrote: > On Mon, Feb 03, 2020 at 05:26:38PM -0800, Sebastian Berg wrote: > > If you want to argue that "identical or equal" is such a fundamental > and > important operation in Python code that we ought to offer it ready- > made > in the opera

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

On 2/3/2020 6:21 PM, Chris Angelico wrote: Hmm, true, although that's equivalent only in one specific situation. In mathematics, "congruent" means that two things are functionally equivalent (eg triangles with the same length sides; in programming terms we'd probably say that two such triangles

[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 operator.identical(a

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

On Tue, Feb 4, 2020 at 1:08 PM Steven D'Aprano wrote: > > 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 > >

[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 `operato

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

On Tue, Feb 4, 2020 at 10:12 AM Sebastian Berg wrote: > > Now, probably this has been rejected a hundred times before, and there > are some very good reason why it is a horrible thought... > > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental > operation (and in a sense it seems

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

On Mon, 2020-02-03 at 16:43 -0800, Larry Hastings wrote: > On 2/3/20 3:07 PM, Sebastian Berg wrote: > > That would mean adding `operator.equivalent(a, b) -> bool` which > > would > > allow float to override the result and let > > `operator.equivalent_value(float("NaN"), float("NaN))` return True; >

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

Ethan Furman wrote: > On 2020-01-23 07:20, Victor Stinner wrote: > > Python 3.9 introduces many small incompatible changes > > which broke tons > > On 2020-01-31 19:47, Mike Miller wrote: > > There's a well-known and established way of signaling > > breaking changes in software platforms—it is to i

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

On 2/3/20 3:07 PM, Sebastian Berg wrote: That would mean adding `operator.equivalent(a, b) -> bool` which would allow float to override the result and let `operator.equivalent_value(float("NaN"), float("NaN))` return True; luckily very few types would actually override the operation. You misund

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

Now, probably this has been rejected a hundred times before, and there are some very good reason why it is a horrible thought... 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? Th

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

On 2020-01-23 07:20, Victor Stinner wrote: Python 3.9 introduces many small incompatible changes which broke tons On 2020-01-31 19:47, Mike Miller wrote: There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number.

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

On 2020-02-03 01:50, Petr Viktorin wrote: When the changes are rolled out gradually across minor releases, those that cause unforeseen trouble in real-world code can be identified in the alphas/betas, and rethought/reverted if necessary. To be clear, my suggestion was to maintain gradual de

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

[Tim] >> 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. >> ... >> If it's intended that Python-the-language req

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

+1 on everything Raymond says here (and in his second message). I don't see a need for more classes or ABCs. On Mon, Feb 3, 2020 at 00:36 Raymond Hettinger wrote: > > PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x and > y are the same object, then equality comparison return

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

On Mon, 3 Feb 2020 13:18:46 +0100 Petr Viktorin wrote: > > > > I agree with the sentiment that gradual deprecations are more easily > > managed, this statement about Python 3.0 is not true. The unicode > > transition was never thought to be small, and that's *why* 3.0 was such > > a big change

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

We could introduce parallel kinds of collections: ValueList/IdentityList, ValueDict/IdentityDict, etc. Ones would use comparison by value and do not preserve identity (so we could use more efficient storage for homogeneous collections, for example a list of small ints could spend 1 byte/item).

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

On 2020-02-03 12:55, Thomas Wouters wrote: On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin > wrote: On 2020-01-31 19:47, Mike Miller wrote: > > On 2020-01-23 07:20, Victor Stinner wrote: >  > Python 3.9 introduces many small incompatible changes whic

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

On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin wrote: > On 2020-01-31 19:47, Mike Miller wrote: > > > > On 2020-01-23 07:20, Victor Stinner wrote: > > > Python 3.9 introduces many small incompatible changes which broke tons > > > > > > There's a well-known and established way of signaling breakin

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

On 2020-01-31 19:47, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: > Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version number

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

I forget to mention that list.index() also uses PyObject_RichCompareBool(). Given a non-empty list *s*: s[0] = x assert s.index(x) == 0 # We want this to always work or: s = [x] assert s.index(x) == 0# Should not raise a ValueError If those two assertions aren't r

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

> We propose to revert 5 changes: > > • Removed tostring/fromstring methods in array.array and base64 modules > • Removed collections aliases to ABC classes > • Removed fractions.gcd() function (which is similar to math.gcd()) > • Remove "U" mode of open(): having to use io

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

> 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. > > This has visible consequences all over the place, but they d

[Python-Dev] Re: Azure Pipelines PR: Spurious failure of 3.8 branch

This seems the best thread to follow up on, just had a spurious failure backporting a patch to 3.8 from master: https://dev.azure.com/Python/cpython/_build/results?buildId=57386&view=logs&j=c83831cd-3752-5cc7-2f01-8276919eb334&t=5a421c4a-0933-53d5-26b9-04b36ad165eb