I am gonna think about that, but all of these operators (though I think you are
calling it "confusing") are basically the equivalent of `iter(dict_object)[x]`.
So they're fast, and can also extract something from the middle of a 'dict'
object.
___
Pyth
On Fri, Oct 15, 2021 at 12:16 AM Steven D'Aprano wrote:
>
> On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> > On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> > wrote:
> > >
> > > Results are in (tested
> > > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and
On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> wrote:
> >
> > Results are in (tested
> > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> > `next(reverse())` counterparts):
> > `*` / `/` implemented i
On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
wrote:
>
> Results are in (tested
> `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> `next(reverse())` counterparts):
> `*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
> `+` / `-` implemented i
Results are in (tested
`next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
`next(reverse())` counterparts):
`*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
`+` / `-` implemented is approximately 3x faster than
`next(iter(d.values()))`/`next(revers
> I implemented these functions as operators in a downloaded source of CPython
And Chris is probably right, but I can't test it now at the time of writing
this reply.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email t
On Thu, Oct 14, 2021 at 08:36:37AM -, Jeremiah Vivian wrote:
> So I implemented these functions as operators in a downloaded source
> of CPython... the differences are insane! (Sorry if this produces
> nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
d
On Thu, Oct 14, 2021 at 7:37 PM Jeremiah Vivian
wrote:
>
> So I implemented these functions as operators in a downloaded source of
> CPython... the differences are insane! (Sorry if this produces nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
> > >>> timeit
Fixed reply:
So I implemented these functions as operators in CPython... the differences are
insane!
> \>\>\> import timeit
>
> # d + 1 vs list(d.values())[0]: 2133x speedup
> \>\>\> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
> 200 loops, best of 5: 165 nsec per loop
>
So I implemented these functions as operators in a downloaded source of
CPython... the differences are insane! (Sorry if this produces nested quotes)
> >>> import timeit
> # d + 1 vs list(d.values())[0]: 2133x speedup
> >>> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
> 2
On Thu, Oct 14, 2021 at 8:04 AM Oscar Benjamin
wrote:
>
> On Wed, 13 Oct 2021 at 18:30, Chris Angelico wrote:
> >
> > On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
> > wrote:
> > > Your suggestion is that this is a bug in map() which is a fair
> > > alternative view. Following through to its co
On Wed, 13 Oct 2021 at 18:30, Chris Angelico wrote:
>
> On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
> wrote:
> > Your suggestion is that this is a bug in map() which is a fair
> > alternative view. Following through to its conclusion your suggestion
> > is that every possible function like map
On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
wrote:
> Your suggestion is that this is a bug in map() which is a fair
> alternative view. Following through to its conclusion your suggestion
> is that every possible function like map, filter, and all the iterator
> implementations in itertools and
On Tue, 12 Oct 2021 at 12:50, Chris Angelico wrote:
>
> On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
> wrote:
> >
> > On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
> >>
> >> ValueError is no safer. The first() function would have, as its API,
> >> "returns the first element or raises Va
>
> If one DID write a first() function, it maybe or maybe not should raise a
> different exception, but it should certainly provide a better error message
For reference, the more-itertools package on PyPI has `first()` and
`last()` functions:
https://more-itertools.readthedocs.io/en/stable/_modu
On Mon, Oct 11, 2021 at 8:08 PM Steven D'Aprano wrote:
> I assume you're not just extracting the first value for the LOLs, you
> must have some reason for it. It is *that reason* which counts as a
> use-case.
>
I dug through our application code base (500k lines) and found just one use
case of t
On Wed, Oct 13, 2021 at 2:39 AM Christopher Barker wrote:
>
> On Tue, Oct 12, 2021 at 4:51 AM Chris Angelico wrote:
>>
>> > Exactly: simple usage of next is often a bug. We need to be careful about
>> > this every time someone suggests that it's straight-forward to do
>> > next(iter(obj)).
>
>
On Tue, Oct 12, 2021 at 4:51 AM Chris Angelico wrote:
> > Exactly: simple usage of next is often a bug. We need to be careful
> about this every time someone suggests that it's straight-forward to do
> next(iter(obj)).
>
> Please give a real example of where calling first() and getting
> ValueE
On Tue, Oct 12, 2021 at 11:47 PM Steven D'Aprano wrote:
>
> Shouldn't your safe_map raise RuntimeError rather than ValueError?
> That's what PEP 479 does *wink*
>
> https://www.python.org/dev/peps/pep-0479/
>
If I'm explicitly choosing the exception to raise, ValueError seems
better, although I'd
Shouldn't your safe_map raise RuntimeError rather than ValueError?
That's what PEP 479 does *wink*
https://www.python.org/dev/peps/pep-0479/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pyt
On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
wrote:
>
>
> On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
>>
>> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
>> wrote:
>> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
>> > attempted to solve this by turning S
On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
> wrote:
> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it
> gets caught in a generator but t
On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
wrote:
> A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it gets
> caught in a generator but that PEP (which was rushed through very quickly
> IIRC) mi
On Sun, 10 Oct 2021 at 04:56, Steven D'Aprano wrote:
> On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
>
> > Anyway, I do see the benefit of adding first() to itertools -- there
> really
> > is a key problem with:
> >
> > next(iter(an_iterable))
> >
> > for newbies -- you can
Please do go back and read that previous thread, there was a LOT of
discussion and much detail.
"I want to use first on dicts" is not really a use-case.
quite true -- what IS the use case(s) here? But honestly, I'm even more
confused by the desire for the last item -- what's the use case for tha
On Mon, Oct 11, 2021 at 06:59:14PM -0400, Erik Demaine wrote:
> In the end, I feel like the main case I want to use a `first` and `last`
> functions on are `dict`s;
"I want to use first on dicts" is not really a use-case. Presumably
you're not just doing:
d = {key: value, ...}
who_care
There seems to be a growing list of issues with adding `itertools.first(x)` as
shorthand for `next(iter(x))`:
* If `x` is an iterator, it modifies the iterator, which is counterintuitive
from the name `first`.
* It'll still be difficult for new users to find/figure out.
In the end, I feel li
Chris Angelico writes:
> Using popitem mutates the underlying dict. That's a tad more likely
> to affect other parts of the code.
Granted. The context is opposition to itertools.first. "Advocating"
popitem is tongue-in-cheek, with the serious point is that it's
obvious that it alters state fr
>
> here is the thread from the last time that this was brought up:
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/#S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ
Thanks, that's very helpful. Sounds like Guido is right, and the short
answer is "while t
here is the thread from the last time that this was brought up:
https://mail.python.org/archives/list/python-ideas@python.org/thread/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/#S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ
It was very thoroughly discussed then.
-CHB
On Sun, Oct 10, 2021 at 8:33 AM Guido van Rossum
You have to check the C code to be sure, but IIRC the latest dict
implementation has a dense array of the values in insert order, and the
hash table (which has gaps) contains indexes into the values array. So you
could easily index into the values array (which I believe also has the
keys) in O(1) t
> Should `dict.items()` be indexable now that dicts are ordered? I say yes. Why
> shouldn't it?
Would there be a way to ensure that this had the same time complexity as
indexing of sequences? If "yes", I would support this — I think it would be
useful in some situations, and it would be more e
> The problem is that first() does not return the first item of the
> iterator, but the *next item still available*.
>
>a = list('12345')
>b = iter('12345')
>
>first(a) == first(a) # True
>first(b) == first(b) # False
This is an excellent point, and something I hadn't considere
On Mon, Oct 11, 2021 at 12:17 AM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
> > On Sun, Oct 10, 2021 at 01:51:52AM +0900, Stephen J. Turnbull wrote:
> > > Christopher Barker writes:
> > >
> > > > But last time, one of the use cases was "get [an arbitrary] item
> > > > from a dic
Steven D'Aprano writes:
> On Sun, Oct 10, 2021 at 01:51:52AM +0900, Stephen J. Turnbull wrote:
> > Christopher Barker writes:
> >
> > > But last time, one of the use cases was "get [an arbitrary] item
> > > from a dict", and there really is not a terribly easy (and
> > > efficient) way to
On Sun, 10 Oct 2021 at 05:06, Finn Mason wrote:
>
> Let's get back to the original topic. Should `dict.items()` be indexable now
> that dicts are ordered? I say yes. Why shouldn't it?
I say no.
"Why shouldn't it?" isn't sufficient justification for a change.
Because it costs someone time and ef
On Sun, Oct 10, 2021 at 3:05 PM Finn Mason wrote:
>
> On Sat, Oct 9, 2021, 9:56 PM Steven D'Aprano wrote:
>>
>> [Snip...]
>
>
>> Newbies won't know first() lives in itertools, and those experienced
>> enough to know it is there probably won't bother to use it.
>
>
> A very good point.
>
> Let's g
On Wed, Oct 06, 2021 at 03:42:28PM +0100, Alex Waygood wrote:
> > Whether they are added to dict or itertools, there are still nine of
> > them
>
> No, the suggestion was to add two functions to itertools (first() and
> last(), which would work with any iterable, not just dicts), rather
> than
On Sat, Oct 9, 2021, 9:56 PM Steven D'Aprano wrote:
> [Snip...]
Newbies won't know first() lives in itertools, and those experienced
> enough to know it is there probably won't bother to use it.
>
A very good point.
Let's get back to the original topic. Should `dict.items()` be indexable
now
On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
> Anyway, I do see the benefit of adding first() to itertools -- there really
> is a key problem with:
>
> next(iter(an_iterable))
>
> for newbies -- you can get really really far in Python without ever having
> to call either
On Sun, Oct 10, 2021 at 01:51:52AM +0900, Stephen J. Turnbull wrote:
> Christopher Barker writes:
>
> > But last time, one of the use cases was "get [an arbitrary] item
> > from a dict", and there really is not a terribly easy (and
> > efficient) way to do that now.
>
> What's wrong with thedi
Christopher Barker writes:
> But last time, one of the use cases was "get [an arbitrary] item
> from a dict", and there really is not a terribly easy (and
> efficient) way to do that now.
What's wrong with thedict.popitem()? Works in Python 2.7, BTW.
Granted, this doesn't help for a random i
It really ius frustrating how often we repeat entire conversations on this
list :-(
But last time, one of the use cases was "get a random item from a dict",
and there really is not a terribly easy (and efficient) way to do that now.
Anyway, I do see the benefit of adding first() to itertools -- t
Finn Mason writes:
> We don't need people writing `next(iter(iterable))` just to get the
> first item.
We already don't need that. `sequence[0]` and `next(iterator)` do the
trick.
You only need `next(iter(iterable))` if you need all three of
- an expression (`for first in iterable: break` gi
Alex Waygood writes:
> the suggestion was to add two functions to itertools (first() and
> last(), which would work with any iterable,
OK, that wasn't obvious to me either, but good enough.
I see the analogy to str's startswith and endswith, but I'm still -0
on these. The names suggest indexi
On 2021-10-06 at 08:52:22 -0600,
Finn Mason wrote:
> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
> people use that feature. I honestly still think of them as unordered
> ;)
+1 on still think of mappings as unordered (but finding myself screaming
Get Off My Lawn more an
> On Oct 6, 2021, at 10:53 AM, Finn Mason wrote:
>
>
> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many people
> use that feature. I honestly still think of them as unordered ;)
>
There’s tons of code that relies on dicts being ordered. Some just don’t know
it. For exa
On Wed, Oct 06, 2021 at 11:17:07AM -0400, Eric V. Smith wrote:
> I think we can rely on dicts being ordered as a language guarantee for
> the rest of time.
Indeed. That's official and documented.
"Changed in version 3.7: Dictionary order is guaranteed to be insertion
order. This behavior was a
On Wed, Oct 6, 2021, 9:23 AM Ricky Teachey wrote:
> On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote:
>
>> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
>> people use that feature. I honestly still think of them as unordered ;)
>>
>
> I've seen several people say this so
On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote:
> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
> people use that feature. I honestly still think of them as unordered ;)
>
I've seen several people say this so I'll be a voice on the other side: I
am not a pro developer
I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
people use that feature. I honestly still think of them as unordered ;)
Let's talk code clarity. After all, to quote GvR, "Code is more often read
than written." (I may have gotten the wording wrong, I just wrote it off
the to
+1. These would be handy for any iterable. It'll works on dict keys and
values; bonus.
On Wed, 2021-10-06 at 15:42 +0100, Alex Waygood wrote:
> > Whether they are added to dict or itertools, there are still nine
> > of
> > them
>
> No, the suggestion was to add two functions to itertools (first(
> Whether they are added to dict or itertools, there are still nine of
> them
No, the suggestion was to add two functions to itertools (first() and last(),
which would work with any iterable, not just dicts), rather than adding nine
methods to the dict interface. This was precisely why I was sa
On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote:
> > The temptation to insist "see, YAGNI!" at this point I shall resist.
>
> *You* might not need it, but I've seen it come up a lot on Stack
> Overflow, and all too often people end up going for the much less
> efficient solution. I
On Tue, Oct 05, 2021 at 08:45:55AM +0100, Alex Waygood wrote:
> I think there definitely should be a more obvious way to do this
> (specifically the first and last keys/values/items of a dictionary
What's your use-case for caring what the first and last key in a dict
is?
> An anti-pattern yo
> The temptation to insist "see, YAGNI!" at this point I shall resist.
*You* might not need it, but I've seen it come up a lot on Stack Overflow, and
all too often people end up going for the much less efficient solution. I
personally have also written code with practical applications using
`ne
Alex Waygood writes:
> Whereas obviously,
The temptation to insist "see, YAGNI!" at this point I shall resist.
> a much better way (especially if it's a very large dictionary) is
> to do:
>
> first_key = next(iter(mydict))
> [Inada Naoki]
> > I think we can add `itertools.first(
> Except many iterables don’t have a last item. And many more can’t give
you the last item efficiently.
That's manageable - reversed won't work either unless the object either
implements either __reversed__, or __len__ and __getitem__. last could
simply fail under the same conditions, in which cas
>
>- dict.first_key = lambda self: next(iter(self))
>- dict.first_val = lambda self: next(iter(self.values()))
>- dict.first_item = lambda self: next(iter(self.items()))
>- dict.last_key = lambda self: next(reversed(self))
>- dict.last_val = lambda self: next(reversed(self.value
I think there definitely should be a more obvious way to do this
(specifically the first and last keys/values/items of a dictionary — I'm
ambivalent about the others, since they won't always be fast, as discussed). An
anti-pattern you see quite often on Stack Overflow to get the first key of a
On Mon, Oct 4, 2021 at 5:46 PM Erik Demaine wrote:
> Have folks thought about allowing indexing dictionary views as in the
> following code, where d is a dict object?
>
> d.keys()[0]
> d.keys()[-1]
> d.values()[0]
> d.values()[-1]
> d.items()[0]
> d.items()[-1] # item that would be returned by d
On Tue, Oct 5, 2021 at 9:46 AM Erik Demaine wrote:
> Of course, the universal way to get the
> first item from an iterable x is
>
> item = next(iter(x))
>
> I can't say this is particularly readable, but it is functional and fast.
I think we can add `itertools.first()` for this idiom, and
`iterto
62 matches
Mail list logo
