On Wed, Dec 11, 2019 at 5:14 PM Steven D'Aprano wrote:
>
> On Tue, Dec 10, 2019 at 07:21:13PM -0600, Tim Peters wrote:
> > While the meaning of `first()` is clear for any iterable argument.
>
> Sorry Tim, I have to disagree. The meaning of `first` is:
>
> return the first element of a
On Tue, Dec 10, 2019 at 07:21:13PM -0600, Tim Peters wrote:
> [Tim]
> >> For me, most of the time, it's to have an obvious, uniform way to
> >> spell "non-destructively pick an object from a container (set, dict,
> >> list, deque, heap, tuple, custom tree class, ...)". I don't even have
> >>
On Tue, Dec 10, 2019 at 09:47:08PM -0500, Kyle Stanley wrote:
> I think itertools.first() is a good example of something that would be
> useful and general-purpose enough to be included as a function in
> itertools.
And I think that this discussion demonstrates why it is so hard to
decide which
For the record, more than 80 messages into this thread, I am no longer
interested in pursuing this. In any case, this is not the kind of thing
Raymond would ever want to see added to itertools. Let's add a recipe for
first() to the list of recipes in the itertools docs.
If people want to change
On Dec 10, 2019, at 17:12, Tim Peters wrote:
>
> [Andrew Barnert ]
>> ...
>> I think you’re arguing that the philosophy of itertools is just wrong, at
>> least for
>> the kind of code you usually write with it and the kind of people who usually
>> write that code. Is that fair, or am I
Tim Peters wrote:
> It's fair enough, although rather than "wrong" I'd say more that it's
> inappropriately applying design principles that work well in most of
> Python's libraries to an area where they don't. The very fact that
> half the itertools docs are devoted to "recipes" kinda suggests
[Tim]
>> For me, most of the time, it's to have an obvious, uniform way to
>> spell "non-destructively pick an object from a container (set, dict,
>> list, deque, heap, tuple, custom tree class, ...)". I don't even have
>> iterators in mind then, except as an implementation detail.
[Steven]
>
[Andrew Barnert ]
> ...
> I think you’re arguing that the philosophy of itertools is just wrong, at
> least for
> the kind of code you usually write with it and the kind of people who usually
> write that code. Is that fair, or am I misrepresenting you here?
It's fair enough, although rather
On Tue, Dec 10, 2019 at 03:50:19PM -0600, Tim Peters wrote:
> For me, most of the time, it's to have an obvious, uniform way to
> spell "non-destructively pick an object from a container (set, dict,
> list, deque, heap, tuple, custom tree class, ...)". I don't even have
> iterators in mind then,
On Dec 10, 2019, at 13:50, Tim Peters wrote:
>
> Talking about "needed" is treating this like an axiomatic system where
> redundancy is in Very Bad Taste. But, to the contrary, in functional
> languages the _implementers_ think very hard about creating a minimal
> core, but the user interface
On Mon, Dec 09, 2019 at 07:12:20PM -0600, Tim Peters wrote:
> Part of it, but I believe it's more following prior art, like Haskell's take:
>
> http://zvon.org/other/haskell/Outputprelude/take_f.html
>
> In that language, the case for putting the count first is
> overwhelming: all functions in
On Mon, Dec 09, 2019 at 10:19:43PM -0400, Juancarlo Añez wrote:
> And knowing that you must use *iter()* for 2-arg *next()* to (maybe) work
> right is idiosyncratic.
If you think that knowing to use `iter` before calling `next` is somehow
advanced or difficult knowledge, I think that you have
[Brett Cannon ]
> Thinking out loud here...
>
> What idiom are we trying to replace with one that's more obviously and whose
> semantics are easy to grasp?
For me, most of the time, it's to have an obvious, uniform way to
spell "non-destructively pick an object from a container (set, dict,
list,
On Mon, Dec 9, 2019 at 9:43 PM Tim Peters wrote:
> [Guido]
> > The argument that first(it) and next(it) "look the same" doesn't convince
> > me;
>
> I'm sorry - I guess then I have absolutely no idea what you were
> trying to say, and read it completely wrong.
>
> > if these look the same then
> It also interns many ints, and they can't be used as names at all.
To clarify on "many ints", integers in the range of -5 to 256 (inclusive)
are interned. This can be demonstrated with the following:
```py
>>> a = 256
>>> b = 256
>>> a is b
True
>>> a = 257
>>> b = 257
>>> a is b
False
>>> a =
15 matches
Mail list logo
