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

On Thu, May 7, 2020 at 1:26 AM Christopher Barker wrote: > > But wait a minute, zip isn't just a "callable", it's a class, and adding > more methods to it seems perfectly natural, just like lots of other > built-in classes. > >> >> Zip is a class in CPython 3.8. it may or may not be in other >>

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

> But wait a minute, zip isn't just a "callable", it's a class, and adding more methods to it seems perfectly natural, just like lots of other built-in classes. > > Zip is a class in CPython 3.8. it may or may not be in other > implementations or versions. The API users are currently promised

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

On Wed, May 6, 2020 at 10:26 PM Oscar Benjamin wrote: > > That's the point though. For *most* functions, the substitution > principle is fine in Python. A whole lot of the time, numeric functions > can take either an int or a float that are equal to each other and produce > results that are

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

On Wed, May 6, 2020, 9:53 PM Eric Fahlgren wrote: > On Wed, May 6, 2020 at 6:27 PM David Mertz wrote: > >> I don't think being a function versus a classmethod is important here. >> Just that the underlying name is *callable*. >> > > But wait a minute, zip isn't just a "callable", it's a class,

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

On Wed, May 6, 2020 at 10:34 PM David Mertz wrote: > > >> zip.shortest(...) # same as zip(...) / zip.longest(...) / >> zip.checksame(...) > > This is a very good example. chain.from_iterator() feels a little weak to > me since there's just the one alternate constructor, whereas zip would >

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

On Wed, May 6, 2020, 9:46 PM Chris Angelico > >> zip.shortest(...) # same as zip(...) / zip.longest(...) / > zip.checksame(...) > > If it's a very common pattern, do you know of any in the standard > library beyond the one I mentioned? Not about bikeshedding the spelling of > the different

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

On Thu, 7 May 2020 at 02:07, David Mertz wrote: > > That's the point though. For *most* functions, the substitution principle is > fine in Python. A whole lot of the time, numeric functions can take either > an int or a float that are equal to each other and produce results that are > equal

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

On Thu, May 7, 2020 at 11:56 AM Eric Fahlgren wrote: > > On Wed, May 6, 2020 at 6:27 PM David Mertz wrote: >> >> I don't think being a function versus a classmethod is important here. Just >> that the underlying name is *callable*. > > > But wait a minute, zip isn't just a "callable", it's a

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

On Wed, May 6, 2020 at 6:27 PM David Mertz wrote: > I don't think being a function versus a classmethod is important here. > Just that the underlying name is *callable*. > But wait a minute, zip isn't just a "callable", it's a class, and adding more methods to it seems perfectly natural, just

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

On Thu, May 7, 2020 at 11:16 AM David Mertz wrote: > > On Wed, May 6, 2020 at 8:37 PM Chris Angelico wrote: >> >> > The only precedent that jumps out for me is itertools.chain() and >> > itertools.chain.from_iterable(). It's quite likely that something I don't >> > use much has used the same

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

>> The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something >> I don't use much has used the same pattern though. I think David is right: itertools.chain.from_iterable() is the only > place I know of with an attribute on a

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

On 5/6/2020 8:33 PM, Chris Angelico wrote: On Thu, May 7, 2020 at 10:27 AM David Mertz wrote: The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though. (Please don't

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

On Wed, May 6, 2020 at 8:37 PM Chris Angelico wrote: > > The only precedent that jumps out for me is itertools.chain() and > itertools.chain.from_iterable(). It's quite likely that something I don't > use much has used the same pattern though. > > That's an example of a very common pattern of

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

I'm afraid, Oscar, that you seem to have painted yourself into a reductio ad absurdum. We need a healthy dose of "practicality beats purity" thrown in here. What the substitution principle essentially says is >if x == y then f(x) == f(y) > for any function f such that f(x) is well defined.

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

On Thu, May 7, 2020 at 10:33 AM Oscar Benjamin wrote: > > I've come to the seemingly obvious conclusion that if there is *any* > difference between x and y then it's always better to say that x != y. > And having worked in languages where floats and integers are fundamentally different beasts, I

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

On Thu, May 7, 2020 at 10:27 AM David Mertz wrote: > > The only precedent that jumps out for me is itertools.chain() and > itertools.chain.from_iterable(). It's quite likely that something I don't use > much has used the same pattern though. > (Please don't top-post - you're making it hard to

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

On Sat, 2 May 2020 at 20:50, Serhiy Storchaka wrote: > > 02.05.20 21:34, Ahmed Amr пише: > > I see there are ways to compare them item-wise, I'm suggesting to bake > > that functionality inside the core implementation of such indexed > > structures. > > Also those solutions are direct with tuples

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

The only precedent that jumps out for me is itertools.chain() and itertools.chain.from_iterable(). It's quite likely that something I don't use much has used the same pattern though. On Wed, May 6, 2020, 8:17 PM Christopher Barker wrote: > On Wed, May 6, 2020 at 10:31 AM Alex Hall wrote: >

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

On Wed, May 6, 2020 at 10:31 AM Alex Hall wrote: zip.shortest(...) # same as zip(...) zip.longest(...) zip.checksame(...) I presume that zip() would keep its current behavior, yes? I kind of like this -- is there any precedent for it in the standard library? The PEP seems to reject this

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

On Wed, May 6, 2020 at 1:42 PM Kirill Balunov wrote: > I'm totally agree with everything you said here. From my perspective, > comparing three main cases: > 1. zip(*iters, strict= (False | True)) > 2. zip(*iters, mode = ('shortest' | 'equal' | 'longest')) > 3. zip_equal(*iters) > Thanks for

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

Joao S. O. Bueno wrote: > Here - with the current inspect.Signature, it is straightforward > to get a decorator that can do that covering most, if not all, > corner cases, and even adding some extra functionality: > https://gist.github.com/jsbueno/f689a181d50384f627b43b9b2aabe4f2 > > from

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

On Wed, May 6, 2020 at 6:49 PM Christopher Barker wrote: > On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano > wrote: > >> Christopher's quoting is kinda messed up and I can't be bothered fixing >> it, sorry, so you'll just have to guess who said what :-) >> > > Ideally, we are evaluating ideas

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

> In the example above, self.b is assigned the value of b, not Enum(b). And even if you called-- or gave the option to call-- func(*args, **kwargs) first, autoassign still wouldn't know that you want to modify the supplied parameter value. >>> >>> But you could just write

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

On Wed, May 6, 2020 at 8:49 PM Ricky Teachey wrote: > >>> In the example above, self.b is assigned the value of b, not Enum(b). >>> And even if you called-- or gave the option to call-- func(*args, **kwargs) >>> first, autoassign still wouldn't know that you want to modify the supplied >>>

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

> > >> In the example above, self.b is assigned the value of b, not Enum(b). And >> even if you called-- or gave the option to call-- func(*args, **kwargs) >> first, autoassign still wouldn't know that you want to modify the supplied >> parameter value. >> > > But you could just write `self.b =

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

On Wed, May 6, 2020 at 8:08 PM 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

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

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 it does cover the majority of corner cases, I think this is a

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

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? On Wed, May 6, 2020 at 4:55 PM Joao S. O. Bueno wrote: > Here - with the current inspect.Signature, it is straightforward >

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

On Wed, May 6, 2020 at 7:15 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Dominik Vilsmeier writes: > > > Or simply "samelength". > > If we're going to do this to the builtin (I'm still -1 on changing the > builtin FWIW), I'm persuaded by Chris Barkley's (somewhat

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

Dominik Vilsmeier writes: > Or simply "samelength". If we're going to do this to the builtin (I'm still -1 on changing the builtin FWIW), I'm persuaded by Chris Barkley's (somewhat different) argument that we may as well combine all the functionality in the builtin. How about zip(*iterables,

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

On Mon, 27 Apr 2020 13:39:19 -0700 Christopher Barker wrote: > There is one "downside" to this in that it potentially leaves the > iterators passed in in a undetermined state -- partially exhausted, > and with a longer one having had one more item removed than was > used. But that exists with

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

On 2020-05-06 12:48 p.m., Christopher Barker wrote: On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano > wrote: Christopher's quoting is kinda messed up and I can't be bothered fixing it, sorry, so you'll just have to guess who said what :-) Ideally, we

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

On Tue, May 5, 2020 at 7:20 AM Steven D'Aprano wrote: > On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote: > > > Can you think of a single case where a zip_equal() (either pre-exisiting > or > > roll your own) would not work, but the concretizing version would? > > That's

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

On Tue, May 5, 2020 at 5:43 PM Steven D'Aprano wrote: > Christopher's quoting is kinda messed up and I can't be bothered fixing > it, sorry, so you'll just have to guess who said what :-) > Ideally, we are evaluating ideas independently of who expressed them, so I'll pretend I did that on

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

Here - with the current inspect.Signature, it is straightforward to get a decorator that can do that covering most, if not all, corner cases, and even adding some extra functionality: https://gist.github.com/jsbueno/f689a181d50384f627b43b9b2aabe4f2 ``` from inspect import signature, Parameter

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

On Mon, 4 May 2020 at 19:13, Lewis Ball wrote: > > I had a similar solution with a decorator using inspect.getfullargspec but it > is pretty fiddly and it is pretty easy to miss > some of the edge cases. Having a standard implementation would definitely > take care of this. And I imagine >

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

On Sat, 2 May 2020 at 15:06, Ahmed Amr wrote: > > I'd like to take your opinion on modifying some of the indexed collections > like tuples, lists, arrays to evaluate its equality to True when having the > same items in the same indexes. > Currently, when comparing a list of items to an array of

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

On Mon, 4 May 2020 at 12:41, Steven D'Aprano wrote: > > On Sun, May 03, 2020 at 11:13:58PM -0400, David Mertz wrote: > > > It seems to me that a Python implementation of zip_equals() shouldn't do > > the check in a loop like a version shows (I guess from more-itertools). > > More obvious is the

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

On 5/6/20 3:04 AM, Greg Ewing wrote: > On 6/05/20 1:58 pm, Henk-Jaap Wagenaar wrote: >> I'd say the difference is just one of semantics and as a >> mathematician I would consider tuples and sequences as "isomorphic", >> in fact, the set-theoretical construction of tuples as functions is >>

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

Greg Ewing wrote: > On 6/05/20 7:45 pm, Henk-Jaap Wagenaar wrote: > > So... say you are solving a problem in 1d, you do > > that on a real number > > x, right? Now you solve it in 2d, so you do your work on a pair (x, y), > > then you might solve it in 3d and do your work on a triplet (x, y, z).

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

On Wed, May 06, 2020 at 07:15:22PM +1200, Greg Ewing wrote: > On 6/05/20 6:12 pm, Steven D'Aprano wrote: > > >https://mathworld.wolfram.com/n-Tuple.html > >https://mathworld.wolfram.com/List.html > >https://mathworld.wolfram.com/Sequence.html > > I get the feeling those definitions are a result

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

On 6/05/20 7:45 pm, Henk-Jaap Wagenaar wrote: So... say you are solving a problem in 1d, you do that on a real number x, right? Now you solve it in 2d, so you do your work on a pair (x, y), then you might solve it in 3d and do your work on a triplet (x, y, z). A few days later you generalize

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

TL;DR: the maths does not matter. Programming language (design)/computer science/data structures should lead this discussion! Also, -1 on this proposal, -1000 on having it apply to strings. Feel free to read on if you want to hear some ramblings of somebody who does not get to use their academic

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

On 6/05/20 6:12 pm, Steven D'Aprano wrote: https://mathworld.wolfram.com/n-Tuple.html https://mathworld.wolfram.com/List.html https://mathworld.wolfram.com/Sequence.html I get the feeling those definitions are a result of seeing things through Mathematica-tinted glasses. -- Greg

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

On 6/05/20 1:58 pm, Henk-Jaap Wagenaar wrote: I'd say the difference is just one of semantics and as a mathematician I would consider tuples and sequences as "isomorphic", in fact, the set-theoretical construction of tuples as functions is *identical* to the usual definition of sequences: i.e.

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

On Tue, May 05, 2020 at 12:49:05PM -0700, Christopher Barker wrote: > Agreed, but discoverability is still something to be considered in the API. > ANd it seems that there are folks arguing that we specifically want this to > be less discoveble due to concerns of overuse. Which does not seem like

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

On Wed, May 06, 2020 at 02:58:01AM +0100, Henk-Jaap Wagenaar wrote: > I don't think that is accurate to represent as a representation of "a > mathematician". The top voted answer here disagrees: > https://math.stackexchange.com/questions/122595/whats-the-difference-between-tuples-and-sequences >