On Wed, May 20, 2020 at 7:56 AM Guido van Rossum wrote:
> No, it's because the message speaks English, not Python, and in English we
> count starting from one. Users would be very confused you counted from zero
> here,
>
And we can tell users that speak Geek more fluently that English that it's
Guido van Rossum wrote:
> No, it's because the message speaks English, not Python, and in English we
> count starting from one.
Yep. For precedent, try passing invalid arguments to `isinstance` and
`issubclass`.
___
Python-ideas mailing list --
On Wed, 20 May 2020 07:52:22 -0700
Guido van Rossum wrote:
> No, it's because the message speaks English, not Python, and in English we
> count starting from one. Users would be very confused you counted from zero
> here,
Agreed. I would be confused myself.
Regards
Antoine.
No, it's because the message speaks English, not Python, and in English we
count starting from one. Users would be very confused you counted from zero
here,
On Wed, May 20, 2020 at 02:24 Paul Moore wrote:
> I suspect it's because zip() is actually a class constructor, so
> argument zero is
I suspect it's because zip() is actually a class constructor, so
argument zero is self...
Paul
On Wed, 20 May 2020 at 10:10, Neil Girdhar wrote:
>
> I'm just curious, but is it usual for errors to be one-based rather than
> zero-based? If I do zip(*iterables, strict=True), then "argument 1 is
I'm just curious, but is it usual for errors to be one-based rather than
zero-based? If I do zip(*iterables, strict=True), then "argument 1 is too
long" refers to iterables[0]?
On Friday, May 1, 2020 at 2:20:12 PM UTC-4, Brandt Bucher wrote:
>
> I have pushed a first draft of PEP 618:
>
>
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
On Thu, May 7, 2020 at 4:42 AM Kirill Balunov
wrote:
> `chain(*iterable)` converts iterable into a tuple, concretizing it in
>> memory. chain.from_iterable(iterable) is lazy and goes through the elements
>> one a time, meaning iterable can be infinite.
>>
>
> "meaning iterable can be infinite"
On Wed, May 06, 2020 at 09:17:15PM -0400, Eric V. Smith wrote:
> I think David is right: itertools.chain.from_iterable() is the only
> place I know of with an attribute on a function that's another function.
Functions decorated with `functools.wrap` have an attribute that gives
the original
On Thu, May 7, 2020 at 10:56 AM Alex Hall wrote:
> On Thu, May 7, 2020 at 9:48 AM Kirill Balunov
> wrote:
>
>> Sorry for off topic. Isn't this chain.from_iterable just a historical
>> legacy... now we have PEP 448 and I see no differences* between
>> chain(*iterable) vs
On Thu, May 7, 2020 at 9:48 AM Kirill Balunov
wrote:
> Sorry for off topic. Isn't this chain.from_iterable just a historical
> legacy... now we have PEP 448 and I see no differences* between
> chain(*iterable) vs chain.from_iterable(iterable). Are there?
>
> * chain.from_iterable is a little bit
Sorry for off topic. Isn't this chain.from_iterable just a historical
legacy... now we have PEP 448 and I see no differences* between
chain(*iterable) vs chain.from_iterable(iterable). Are there?
* chain.from_iterable is a little bit faster for small iterables, but if at
that time we had PEP 448,
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
>>
> 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
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,
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
>
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
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
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
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
>> 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
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
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
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
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:
>
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
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
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,
Thanks to everyone who provided useful feedback. I'm working now to incorporate
many of your suggestions into the next draft, which should be pushed soon.
Brandt
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On 04.05.20 16:14, Steven D'Aprano wrote:
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
map(func, x, y, strict=True) # ?
Admittedly the word "strict" in the context of `map` would be rather
confusing.
This
ich could suggest that once an iterator is
exhausted it just continues to yield tuples of reduced length, i.e.
`list(zip('ab', range(3), exact=False))` could result in `[('a', 0),
('b', 1), (2,)]`.
-Original Message-
From: MRAB
Sent: 04 May 2020 17:55
To: python-ideas@python.org
Subject: [P
There could be other modes, such as `mode="repeat"` which reuses the
last value of each iterator as a fillvalue, or `mode="wrap"` which is
similar to `zip(*(it.cycle(x) for x in its))`.
So indeed a binary flag protects from additional requests to further
overload that function. This can be a
used to extend the exhausted iterator(s). I think that this would also work
well for map as well.
Steve Barnes (sorry for top posting - Outlook)
-Original Message-
From: MRAB
Sent: 04 May 2020 17:55
To: python-ideas@python.org
Subject: [Python-ideas] Re: PEP 618: Add Optional Le
On 2020-05-04 13:17, Dominik Vilsmeier wrote:
"strict" doesn't say what it's being strict about. That information has
to be inferred by the reader.
[snip]
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
On Sun, 3 May 2020 21:57:42 -0700
Guido van Rossum wrote:
> I should really stay out of this (hundreds of messages and still
> bickering^Wbikeshedding :-), but I personally find strict=True *less*
> confusing than equal=True, both for zip() and for map(). If I didn't know
> what was going on,
On Mon, May 4, 2020, 10:55 AM Ricky Teachey wrote:
> I'm wondering if a `mode` (or similar) keyword argument, with multiple
> possible options, should be included in the "rejected" section of the PEP.
>
> zip(*args, mode="longest") <-- default
> zip(*args, mode="equal") <-- or "even"
>
Whoops
On 04/05/2020 15:02, Alex Hall wrote:
...top-posted stuff in response to jdve...@gmail.com, who had bottom posted.
Guys, I know I'm not going to persuade either of you of the fundamental
truth that posting interleaved replies is best, but if you're going to
post at opposite ends of the chain
I'm wondering if a `mode` (or similar) keyword argument, with multiple
possible options, should be included in the "rejected" section of the PEP.
zip(*args, mode="longest") <-- default
zip(*args, mode="equal") <-- or "even"
An advantage of this way is if the option to zip in different ways
On Mon, May 04, 2020 at 02:18:15PM -, jdve...@gmail.com wrote:
> Ok,`even`is one of those scarce polysemic words in English ;-)
>
> Meaning depends on context and message receiver's expectations, of course.
>
> But... "add an even mixture of milk and cream" and "the curtain rod
> and the
Alex Hall wrote:
> If you use the word 'even' and tell me it has to do with lengths (or any
> number) I'm going to think of multiples of 2, not equality.
> On Mon, May 4, 2020 at 3:52 PM jdve...@gmail.com
> wrote:
> > Guido van Rossum wrote:
> > I should really stay out of this (hundreds of
> >
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
> On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
>
> > > > map(func, x, y, strict=True) # ?
> > > >
> > > > Admittedly the word "strict" in the context of `map` would be rather
> > > > confusing.
> > > >
> > >
> > >
If you use the word 'even' and tell me it has to do with lengths (or any
number) I'm going to think of multiples of 2, not equality.
On Mon, May 4, 2020 at 3:52 PM wrote:
> Guido van Rossum wrote:
> > I should really stay out of this (hundreds of messages and still
> > bickering^Wbikeshedding
Guido van Rossum wrote:
> I should really stay out of this (hundreds of messages and still
> bickering^Wbikeshedding :-), but I personally find strict=True less
> confusing than equal=True, both for zip() and for map(). If I didn't know
> what was going on, seeing equal=True would make me wonder
"strict" doesn't say what it's being strict about. That information has
to be inferred by the reader. As a keyword argument I'd expect it to
relate to the function's main purpose, so for `zip` I can understand how
this refers to the arguments (since their items end up in the resulting
tuples).
I should really stay out of this (hundreds of messages and still
bickering^Wbikeshedding :-), but I personally find strict=True *less*
confusing than equal=True, both for zip() and for map(). If I didn't know
what was going on, seeing equal=True would make me wonder about whether
equality between
On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
> > > map(func, x, y, strict=True) # ?
> > >
> > > Admittedly the word "strict" in the context of `map` would be rather
> > > confusing.
> > >
> >
> > This a really good argument for "equal" rather than "strict".
>
> Sorry, I'm not
On Sun, May 03, 2020 at 04:09:21PM -0700, Christopher Barker wrote:
> > map(func, x, y, strict=True) # ?
> >
> > Admittedly the word "strict" in the context of `map` would be rather
> > confusing.
> >
>
> This a really good argument for "equal" rather than "strict".
Sorry, I'm not seeing
On Sun, May 3, 2020 at 3:39 PM Dominik Vilsmeier
wrote:
> If `zip` gets a `strict` keyword-only parameter, a slightly related
> question is whether `map` should also receive one?
>
This did come up in the conversion. Brandt: you may want to address this in
the PEP.
map(func, x, y,
If `zip` gets a `strict` keyword-only parameter, a slightly related
question is whether `map` should also receive one?
`map` can be used as zip + transform:
map(func, x, y)
(func(a, b) for a, b in zip(x, y)) # similar
Now if I'm using the first option and I want to enable the strict
Hi
I've read some posts on this topic, but this is my first contribution.Thank
you Brandt for writing the PEP. I like it's clarity. And thank you Ram for
making the suggestion that started the discussion. I fully agree, that we
have here a problem worth solving. And many thanks for the many other
I'm +1 obviously :)
On Fri, May 1, 2020 at 9:19 PM Brandt Bucher wrote:
> I have pushed a first draft of PEP 618:
>
> https://www.python.org/dev/peps/pep-0618
>
> Please let me know what you think – I'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP!
>
> Brandt
>
I think you misunderstood me - otherwise I don't know what this email is
meant to accomplish. The conversation as I see it went:
Brandt in the PEP: X is an antipattern.
Andrew to Brandt: A strict flag would require us to do Y which you said is
an antipattern.
Me to Andrew: Y is fine, it's not an
On Fri, May 01, 2020 at 11:30:17PM +0200, Alex Hall wrote:
> Specifically the PEP says:
>
> > Another proposed idiom, per-module shadowing of the built-in zip with some
> > subtly different variant from itertools, is an anti-pattern that shouldn't
> > be encouraged.
> >
>
> I think the PEP is
On Fri, May 01, 2020 at 05:16:00PM -0300, Soni L. wrote:
> >I say again, YAGNI. Give an actual use-case for the excessive
> >generality of your proposal - namely, the ability to provide a custom
> >function. And show that it's better with zip than just with a custom
> >generator function.
>
> we
On Fri, May 1, 2020 at 10:58 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> A separate function can be used in third-party libraries immediately, as
> long as there’s an available backport (whether that’s more-iterools, or a
> trivial zip39 or whatever) that they can
On Fri, May 1, 2020 at 5:55 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On May 1, 2020, at 11:19, Brandt Bucher wrote:
> >
> > I have pushed a first draft of PEP 618:
> >
> > https://www.python.org/dev/peps/pep-0618
>
> The document says “… with nobody challenging the
> but the main
> benefit is, again, being able to get the iterated values which were
> silently swallowed by zip when the iteration stopped.
I don't think the call back idea is terrible, however, it doesn't really
seem to have a usecase that isn't
covered by zip_longest with a sentinel. Now as
On May 1, 2020, at 11:19, Brandt Bucher wrote:
>
> I have pushed a first draft of PEP 618:
>
> https://www.python.org/dev/peps/pep-0618
The document says “… with nobody challenging the use of the word ‘strict’”, but
people did challenge it, and even more people just called it “equal” instead
On 2020-05-01 4:43 p.m., Chris Angelico wrote:
On Sat, May 2, 2020 at 5:21 AM Soni L. wrote:
>
>
>
> On 2020-05-01 3:41 p.m., Chris Angelico wrote:
> > On Sat, May 2, 2020 at 4:38 AM Soni L. wrote:
> > >
> > >
> > >
> > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
> > > > I have pushed a
On Sat, May 2, 2020 at 5:21 AM Soni L. wrote:
>
>
>
> On 2020-05-01 3:41 p.m., Chris Angelico wrote:
> > On Sat, May 2, 2020 at 4:38 AM Soni L. wrote:
> > >
> > >
> > >
> > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
> > > > I have pushed a first draft of PEP 618:
> > > >
> > > >
On 2020-05-01 3:41 p.m., Chris Angelico wrote:
On Sat, May 2, 2020 at 4:38 AM Soni L. wrote:
>
>
>
> On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
> > I have pushed a first draft of PEP 618:
> >
> > https://www.python.org/dev/peps/pep-0618
> >
> > Please let me know what you think – I'd love
On 01/05/2020 19:10, Brandt Bucher wrote:
I have pushed a first draft of PEP 618:
https://www.python.org/dev/peps/pep-0618
Please let me know what you think – I'd love to hear any *new* feedback that
hasn't yet been addressed in the PEP!
Not sure whether you class this as new, but I think
On Sat, May 2, 2020 at 4:38 AM Soni L. wrote:
>
>
>
> On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
> > I have pushed a first draft of PEP 618:
> >
> > https://www.python.org/dev/peps/pep-0618
> >
> > Please let me know what you think – I'd love to hear any *new* feedback
> > that hasn't yet
On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
I have pushed a first draft of PEP 618:
https://www.python.org/dev/peps/pep-0618
Please let me know what you think – I'd love to hear any *new* feedback that
hasn't yet been addressed in the PEP!
What about using an optional kwarg for a
64 matches
Mail list logo
