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

On Thu, May 07, 2020 at 11:12:28PM +0900, Stephen J. Turnbull wrote: [...] > So of course zip can be said to be used like a class. Its instances > are constructed by calling it, the most common (only in practice?) > method call is .__iter__, it's invariably called implicitly in a for > statement

[Python-ideas] islice with actual slices

Here's an idea I've had. How about instead of this: itertools.islice(iterable, 7, 20) We'll just have: itertools.islice(iterable)[7:20] Advantages: 1. More familiar slicing syntax. 2. No need to awkwardly use None when you're interested in just specifying the end of the slice without specifyin

[Python-ideas] Re: islice with actual slices

On Sat, May 9, 2020 at 11:15 AM Ram Rachum wrote: > Here's an idea I've had. How about instead of this: > > itertools.islice(iterable, 7, 20) > > We'll just have: > > itertools.islice(iterable)[7:20] > > > Advantages: > 1. More familiar slicing syntax. > 2. No need to awkwardly use None when you'

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

On 08.05.20 19:01, Steven D'Aprano wrote: All this proposal adds is *duck-typing* to the comparison, for when it doesn't matter what the container type is, you care only about the values in the container. Why be forced to do a possibly expensive (and maybe very expensive!) manual coercion to a c

[Python-ideas] Re: islice with actual slices

On Sat, 9 May 2020 at 10:13, Ram Rachum wrote: > > Here's an idea I've had. How about instead of this: > > itertools.islice(iterable, 7, 20) > > We'll just have: > > itertools.islice(iterable)[7:20] > > > Advantages: > 1. More familiar slicing syntax. > 2. No need to awkwardly use None when you're

[Python-ideas] Re: islice with actual slices

On Sat, May 9, 2020 at 12:58 PM Paul Moore wrote: > > Why would you use islice(x, None, 10)? islice(x, 10) does the same... > I guess you might occasionally do islice(x, None, end, step), but that > seems fairly rare. > My mistake, I meant islice(x, 10, None) where you're doing the slice [10:].

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

On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier wrote: > So as a practical step forward, what about providing a wrapper type > which performs all operations elementwise on the operands. So for example: > > if all(elementwise(chars) == string): > ... > > Here the `elementwise(chars

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

On Sat, May 9, 2020 at 7:10 PM Steven D'Aprano wrote: > > On Thu, May 07, 2020 at 11:12:28PM +0900, Stephen J. Turnbull wrote: > > [...] > > So of course zip can be said to be used like a class. Its instances > > are constructed by calling it, the most common (only in practice?) > > method call i

[Python-ideas] Re: islice with actual slices

On Sat, May 9, 2020 at 8:00 PM Alex Hall wrote: > > On Sat, May 9, 2020 at 11:15 AM Ram Rachum wrote: >> >> Here's an idea I've had. How about instead of this: >> >> itertools.islice(iterable, 7, 20) >> >> We'll just have: >> >> itertools.islice(iterable)[7:20] >> >> >> Advantages: >> 1. More fam

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

On Fri, May 8, 2020 at 8:38 PM 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 dunde

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

On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > Trying to make it a flag (which will always be passed a constant value) is > a clever way to try to get the best of both worlds—and so is the > chain.from_iterable style. At this point it sounds l

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

On 09.05.20 12:18, Alex Hall wrote: On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier mailto:dominik.vilsme...@gmx.de>> wrote: So as a practical step forward, what about providing a wrapper type which performs all operations elementwise on the operands. So for example: if

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

On 09.05.20 14:16, Dominik Vilsmeier wrote: On 09.05.20 12:18, Alex Hall wrote: On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier mailto:dominik.vilsme...@gmx.de>> wrote: So as a practical step forward, what about providing a wrapper type which performs all operations elementwise on t

[Python-ideas] Re: Introduce 100 more built-in exceptions

Hey, I just found a good example for the unpacking errors I suggested: def topological_sort(graph: networkx.DiGraph) -> tuple: try: (zero_node,) = (node for node in graph if not graph.neighbors(node)) except TooFewToUnpackError: raise OverdefinedOrderi

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 9, 2020 at 7:02 PM Ram Rachum wrote: > Hey, > > I just found a good example for the unpacking errors I suggested: > > > def topological_sort(graph: networkx.DiGraph) -> tuple: > try: > (zero_node,) = (node for node in graph if not > graph.neighbors(node)) >

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 9, 2020 at 8:09 PM Alex Hall wrote: > On Sat, May 9, 2020 at 7:02 PM Ram Rachum wrote: > >> >> Besides elegance, the above code can be optimized with short-circuit >> logic for the TooManyToUnpackError, assuming that doesn't break backward >> compatibility. >> > > The elegance argume

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

> On May 9, 2020, at 04:30, Alex Hall wrote: >  >> On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas >> wrote: > >> Trying to make it a flag (which will always be passed a constant value) is a >> clever way to try to get the best of both worlds—and so is the >> chain.from_itera

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

On May 9, 2020, at 03:46, Chris Angelico wrote: > > But ultimately, a generator function is very similar to a class with a > __next__ method. When you call it, you get back a state object that > you can ping for the next value. That's really all that matters. Well, it’s very similar to a class w

[Python-ideas] Adding slice Iterator to Sequences (was: islice with actual slices)

Funny you should bring this up. I've been meaning, for literally years, to propose not quite this, but adding a "slice iterator" to the sequence protocol. (though note that one alternative is adding slice syntax to itertools.islice) I even got so far as to write a draft PEP and prototype. NOTE

[Python-ideas] Re: islice with actual slices

On May 9, 2020, at 02:12, Ram Rachum wrote: > >  > Here's an idea I've had. How about instead of this: > > itertools.islice(iterable, 7, 20) > > We'll just have: > > itertools.islice(iterable)[7:20] I’ve actually built this.[1] From my experience, it feels clever at first, but it can get

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On May 9, 2020, at 12:38, Christopher Barker wrote: > > https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst I haven’t read the whole thing yet, but one thing immediately jumped out at me: > and methods on containers, such as dict.keys return iterators in Python 3, No they d

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

+1 I like this! I never considered this idea. It's a good combination of efficiency and elegance. On Sat, May 9, 2020 at 10:41 PM Christopher Barker wrote: > Funny you should bring this up. > > I've been meaning, for literally years, to propose not quite this, but > adding a "slice iterator" to

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

On May 9, 2020, at 02:58, Dominik Vilsmeier wrote: > > > Initially I assumed that the reason for this new functionality was > concerned with cases where the types of two objects are not precisely > known and hence instead of converting them to a common type such as > list, a direct elementwise c

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

On 09.05.20 22:16, Andrew Barnert wrote: On May 9, 2020, at 02:58, Dominik Vilsmeier wrote: Initially I assumed that the reason for this new functionality was concerned with cases where the types of two objects are not precisely known and hence instead of converting them to a common type such

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

On May 9, 2020, at 13:24, Dominik Vilsmeier wrote: > >  >> On 09.05.20 22:16, Andrew Barnert wrote: >>> >> There’s an obvious use for the .all, but do you ever have a use for the >> elementwise itself? When do you need to iterate all the individual >> comparisons? (In numpy, an array of bools

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sat, May 9, 2020 at 9:41 PM Christopher Barker wrote: > Funny you should bring this up. > > I've been meaning, for literally years, to propose not quite this, but > adding a "slice iterator" to the sequence protocol. > > (though note that one alternative is adding slice syntax to > itertools.i

[Python-ideas] Sanitize filename (path part)

I believe the Python standard library should include a means of sanitizing a filesystem entry, and this should not be something requiring a 3rd party package. One of reasons I think this should be in the standard lib is because that provides a common, simple means for code reviewers and static

[Python-ideas] Re: Sanitize filename (path part)

Steve Jorgensen wrote: > I believe the Python standard library should include a means of sanitizing a > filesystem > entry, and this should not be something requiring a 3rd party package. > One of reasons I think this should be in the standard lib is because that > provides a > common, simple mea

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sat, May 9, 2020 at 1:03 PM Andrew Barnert wrote: > https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst I haven’t read the whole thing yet, but one thing immediately jumped out at me: > and methods on

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sat, May 9, 2020 at 1:58 PM Alex Hall wrote: > I think this is a good idea. For sequences I'm not sure how big the > benefit is - I get that it's more efficient, but I rarely care that much, > because most lists are small. Why not extend the proposal to all iterators, > or at least common one

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On May 9, 2020, at 19:43, Christopher Barker wrote: > > On Sat, May 9, 2020 at 1:03 PM Andrew Barnert wrote: > > https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst > > I haven’t read the whole thing yet, but one thing immediately jumped out at > me: > > > and methods on co

[Python-ideas] Re: Sanitize filename (path part)

On May 9, 2020, at 17:35, Steve Jorgensen wrote: > > I believe the Python standard library should include a means of sanitizing a > filesystem entry, and this should not be something requiring a 3rd party > package. > > One of reasons I think this should be in the standard lib is because that