[Python-ideas] Re: Equality between some of the indexed collections

Thanks Andrew for the excellent analysis quoted below. Further comments interleaved with yours. On Fri, May 08, 2020 at 05:40:31PM -0700, Andrew Barnert via Python-ideas wrote: > If someone wants this proposal, it’s because they believe it’s _not_ a > misuse to use a tuple as a frozen list (or

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 11:39 PM Steven D'Aprano wrote: > "More important" according to whose needs? > I dunno. To mine? To "beginner programmers"? To numeric computation? I can weaken my 'note' to 'purport' if that helps. (3) Whereas the proposed duck-typing sequence equality relies on >

[Python-ideas] Re: Equality between some of the indexed collections

On May 8, 2020, at 20:36, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On Fri, 8 May 2020 17:40:31 -0700 > Andrew Barnert via Python-ideas wrote: > >> So, the OP is right that (1,2,3)==[1,2,3] would sometimes be handy, >> the opponents are right that it would often be misleading

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 04:51:04PM +0100, Henk-Jaap Wagenaar wrote: > FYI, it does show in my version on gmail and on the mailman version. > > > BTW, I think strings do showcase some problems

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 03:12:10PM -0400, Dan Sommers wrote: > On Sat, 9 May 2020 03:39:53 +1000 > Steven D'Aprano wrote: > > > This proposal is a narrow one: its the same as list or tuple equality, > > but duck-typed so that the container type doesn't matter. > > Okay. Good. > > "Container,"

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 07:24:43PM -0400, David Mertz wrote: > On Fri, May 8, 2020, 6:39 PM Steven D'Aprano > > > So what? Why is this relevant? This is not a proposal for a generalised > > equivalence relation. If you want one of those feel free to propose a > > competing idea. > > > > The OP, w

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, 8 May 2020 17:40:31 -0700 Andrew Barnert via Python-ideas wrote: > So, the OP is right that (1,2,3)==[1,2,3] would sometimes be handy, > the opponents are right that it would often be misleading, and the > question isn’t which one is right ... That's a good summary. Thank you. :-) > [

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

On May 4, 2020, at 10:44, Steve Barnes wrote: > And "equal" doesn't say what it's equal. > > What we need is a word that means "same length", much as "shorter" and > "longer" are about length. > > There's "coextensive", but that'll probably get a -1. If “equal” is bad, “coextensive” is much wo

[Python-ideas] Re: General methods

On May 8, 2020, at 15:44, Steven D'Aprano wrote: > > On Fri, May 08, 2020 at 10:46:45PM +0300, Serhiy Storchaka wrote: > >> I propose to add the METH_GENERAL flag, which is applicable to methods >> as METH_CLASS and METH_STATIC (and is mutually incompatible with them). >> If it is set, the ch

[Python-ideas] Re: Equality between some of the indexed collections

On May 6, 2020, at 05:22, Richard Damon wrote: > > In my mind, tuples and lists seem very different concepts, that just > happen to work similarly at a low level (and because of that, are > sometimes 'misused' as each other because it happens to 'work'). I think this thread has gotten off track,

[Python-ideas] Re: General methods

On 09May2020 08:38, Steven D'Aprano wrote: On Fri, May 08, 2020 at 10:46:45PM +0300, Serhiy Storchaka wrote: I propose to add the METH_GENERAL flag, which is applicable to methods as METH_CLASS and METH_STATIC (and is mutually incompatible with them). If it is set, the check for the type of se

[Python-ideas] Re: General methods

On Fri, May 8, 2020 at 3:47 PM Steven D'Aprano wrote: > On Fri, May 08, 2020 at 10:46:45PM +0300, Serhiy Storchaka wrote: > > > I propose to add the METH_GENERAL flag, which is applicable to methods > > as METH_CLASS and METH_STATIC (and is mutually incompatible with them). > > If it is set, the

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020, 6:39 PM Steven D'Aprano > So what? Why is this relevant? This is not a proposal for a generalised > equivalence relation. If you want one of those feel free to propose a > competing idea. > The OP, with a certain degree of support from you, is asking for changing the meaning

[Python-ideas] Re: General methods

On Fri, May 08, 2020 at 10:46:45PM +0300, Serhiy Storchaka wrote: > I propose to add the METH_GENERAL flag, which is applicable to methods > as METH_CLASS and METH_STATIC (and is mutually incompatible with them). > If it is set, the check for the type of self will be omitted, and you > can pass

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 03:16:48PM -0400, David Mertz wrote: > On Fri, May 8, 2020 at 1:47 PM Steven D'Aprano wrote: > > > All of which are red herrings that are completely off-topic for this > > proposal. This proposal has nothing to do with: > > > > > case_insensitive_eq(a, b) > > > same_json_r

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On May 4, 2020, at 17:26, Steven D'Aprano wrote: > > Proposal: > > We should have a mechanism that collects the current function or > method's parameters into a dict, similar to the way locals() returns all > local variables. > > This mechanism could be a new function,or it could even be a ma

[Python-ideas] Re: zip(x, y, z, strict=True)

On May 5, 2020, at 12:50, Christopher Barker wrote: > > Another key point is that if you want zip_longest() functionality, you simply > can not get it with the builtin zip() -- you are forced to look elsewhere. > Whereas most code that might want "strict" behavior will still work, albeit > les

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 9, 2020 at 4:43 AM Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On Sat, 9 May 2020 03:01:15 +1000 > Steven D'Aprano wrote: > > > On Thu, May 07, 2020 at 11:04:16AM -0400, Dan Sommers wrote: > > > On Thu, 7 May 2020 21:18:16 +1000 > > > Steven D'Aprano wrote: > > > > > >

[Python-ideas] General methods

Methods in Python are defined as functions in the class namespace. When call the method of the object, the function will be called with the object as the first argument. And furthermore, unbound methods can be called with passing self as the first argument. For example, str.upper('abc') returns

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, 9 May 2020 03:39:53 +1000 Steven D'Aprano wrote: > This proposal is a narrow one: its the same as list or tuple equality, > but duck-typed so that the container type doesn't matter. Okay. Good. "Container," however, is a dangerous word in this context. According to https://docs.pytho

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 1:47 PM Steven D'Aprano wrote: > All of which are red herrings that are completely off-topic for this > proposal. This proposal has nothing to do with: > > > case_insensitive_eq(a, b) > > same_json_representation(a, b) > > allclose(a, b) # A version of this is in NumPy > >

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, 9 May 2020 04:29:46 +1000 Steven D'Aprano wrote: > On Fri, May 08, 2020 at 07:52:10PM +0200, Alex Hall wrote: > > > Would the proposal come with a new magic dunder method which can be > > overridden, or would it be like `is`? > > An excellent question! I don't think there needs to be a

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 9, 2020 at 4:17 AM Alex Hall wrote: > > On Fri, May 8, 2020 at 7:52 PM David Mertz wrote: >>> >>> Me: For non-singleton immutables, identity is not really a meaningful >>> thing. I mean, other than in a debugger or code profiler, or something >>> special like that. I honestly do no

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, 9 May 2020 03:01:15 +1000 Steven D'Aprano wrote: > On Thu, May 07, 2020 at 11:04:16AM -0400, Dan Sommers wrote: > > On Thu, 7 May 2020 21:18:16 +1000 > > Steven D'Aprano wrote: > > > > > > The strongest equality is the "is" operator > > > > > > Please don't encourage the conceptual err

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 07:52:10PM +0200, Alex Hall wrote: > Would the proposal come with a new magic dunder method which can be > overridden, or would it be like `is`? An excellent question! I don't think there needs to be a dunder. Calling this "sequence-equal": Two sequences are "sequence-eq

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 01:26:05PM -0400, David Mertz wrote: > The distinction you make seems both pedantic and factually wrong. Which distinction are you referring to? The one between `is` and `==`? And in what way is it factually wrong? > More flat-footed still is "equal objects are ones who

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 7:52 PM David Mertz wrote: > Me: For non-singleton immutables, identity is not really a meaningful >> thing. I mean, other than in a debugger or code profiler, or something >> special like that. I honestly do not know whether, e.g. '(1, "a", 3.5) is >> (1, "a", 3.5)'. I'l

[Python-ideas] Re: Equality between some of the indexed collections

On 05/08/2020 09:36 AM, Alex Hall wrote: On Fri, May 8, 2020 at 5:51 PM Henk-Jaap Wagenaar wrote: FYI, it does show in my version on gmail and on the mailman version. Weird, did Ethan's

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 7:48 PM Steven D'Aprano wrote: > On Fri, May 08, 2020 at 01:00:48PM -0400, David Mertz wrote: > > > All the discussion following Steven's hypothetical .EQ. operator (yes, > not > > a possible spelling) just seems to drive home to me that what everyone > > wants is simply a

[Python-ideas] Re: Equality between some of the indexed collections

> > Me: For non-singleton immutables, identity is not really a meaningful > thing. I mean, other than in a debugger or code profiler, or something > special like that. I honestly do not know whether, e.g. '(1, "a", 3.5) is > (1, "a", 3.5)'. I'll go try it, but I won't be sure the answer for every

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 08, 2020 at 01:00:48PM -0400, David Mertz wrote: > All the discussion following Steven's hypothetical .EQ. operator (yes, not > a possible spelling) just seems to drive home to me that what everyone > wants is simply a function. > > Many different notions of "equivalence for a particu

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 1:06 PM Steven D'Aprano wrote: > Whatever we might feel about equality and identity in the wider > philosophical sense, in the *Python programming sense* the semantic > meaning of the two operators are orthogonal: > > * some equal objects are not identical; > * and some ide

[Python-ideas] Re: Equality between some of the indexed collections

On Thu, May 07, 2020 at 11:04:16AM -0400, Dan Sommers wrote: > On Thu, 7 May 2020 21:18:16 +1000 > Steven D'Aprano wrote: > > > > The strongest equality is the "is" operator > > > > Please don't encourage the conceptual error of thinking of `is` as > > *equality*, not even a kind of equality. I

[Python-ideas] Re: Equality between some of the indexed collections

All the discussion following Steven's hypothetical .EQ. operator (yes, not a possible spelling) just seems to drive home to me that what everyone wants is simply a function. Many different notions of "equivalence for a particular purpose" have been mentioned. We're not going to get a dozen differ

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Wed, 6 May 2020 at 15:08, Ricky Teachey wrote: > > On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote: >> >> I think this looks great, I can't think of anything wrong with it. >> >> Could we put this into the standard library, so that IDEs and linters are >> programmed to recognise it? > > > If i

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 5:51 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > FYI, it does show in my version on gmail and on the mailman version. > > Weird, did Ethan's client cut

[Python-ideas] Re: Equality between some of the indexed collections

FYI, it does show in my version on gmail and on the mailman version. BTW, I think strings do showcase some problems with this idea, .EQ. (as defined by Steven) is not recursive, which I think

[Python-ideas] Re: Equality between some of the indexed collections

Here's an example you might want to consider: >>> from collections import namedtuple >>> Point = namedtuple('Point', ['x', 'y']) >>> Point(1, 2) Point(x=1, y=2) >>> Point(1, 2) == (1, 2) True >>> Polar = namedtuple('Polar', ['r', 'theta']) >>> Polar(1, 2) Pola

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 5:11 PM Ethan Furman wrote: > On 05/08/2020 07:50 AM, Alex Hall wrote: > > On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote: > >> On Fri, 8 May 2020 at 14:16, Steven D'Aprano > wrote: > >> > >>> If you have ever written something like any

[Python-ideas] Re: Equality between some of the indexed collections

On 05/08/2020 07:50 AM, Alex Hall wrote: On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote: On Fri, 8 May 2020 at 14:16, Steven D'Aprano mailto:st...@pearwood.info>> wrote: If you have ever written something like any of these:     all(x==y for x,y in zip(a, b)) That looks like a zip

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > On Fri, 8 May 2020 at 14:16, Steven D'Aprano wrote: > >> If you have ever written something like any of these: >> >> list(a) == list(b) >> tuple(a) == b >> ''.join(chars) == mystring >> all(x=

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, 8 May 2020 at 14:16, Steven D'Aprano wrote: > On Thu, May 07, 2020 at 03:43:23PM +0200, Dominik Vilsmeier wrote: > > > >We could define this .EQ. operate as *sequence equality*, defined very > > >roughly as: > > > > > > def .EQ. (a, b): > > > return len(a) == len(b) and all(x=

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, 8 May 2020 23:10:05 +1000 Steven D'Aprano wrote: > On Thu, May 07, 2020 at 03:43:23PM +0200, Dominik Vilsmeier wrote: > > How common is it to compare two objects where you cannot determine > > whether one or the other is a tuple or a list already from the > > surrounding context? In the

[Python-ideas] Re: Equality between some of the indexed collections

On Thu, May 07, 2020 at 03:43:23PM +0200, Dominik Vilsmeier wrote: > >We could define this .EQ. operate as *sequence equality*, defined very > >roughly as: > > > > def .EQ. (a, b): > > return len(a) == len(b) and all(x==y for x, y in zip(a, b)) > > > But why do we even need a new opera

[Python-ideas] Re: Equality between some of the indexed collections

On Thu, May 07, 2020 at 04:42:22PM +0100, Rhodri James wrote: > On 07/05/2020 10:11, Steven D'Aprano wrote: > The biggest argument against a second "equals" operator, however it is > spelt, is confusion. Which of these two operators do I want to use for > this subtly different question of equal

[Python-ideas] Re: zip() as a class constructor (meta) [was: ... Length-Checking To zip]

Dominik Vilsmeier writes: > Maybe people start writing code like this: > >     if not zip.checksame(a, b): >     raise ValueError() >     for stuff in zip(a, b): At some point you just have to hope that people read documentation. Maybe there's a better name; that one was originally