On Wed, 1 Jul 2020 at 05:36, Christopher Barker wrote:
>
> On Tue, Jun 30, 2020 at 11:55 AM Rhodri James wrote:
>>
>> Don't get me wrong, if it's not going to cause performance issues I
>> think being able to index views would be great, but I don't think this
>> is the right way to justify it.
>
On Tue, Jun 30, 2020 at 07:40:23PM +0100, Rhodri James wrote:
> Don't get me wrong, if it's not going to cause performance issues I
> think being able to index views would be great
What are your use-cases for indexing set-like views of a dict?
--
Steven
___
On Tue, Jun 30, 2020 at 09:33:25PM -0700, Christopher Barker wrote:
> I wasn't justifying it -- I was simply saying that no one ever specifically
> decided that we DIDN'T want to be able to index dict views -- when they
> were created, it simply wasn't an option. Now it is, so we need to rethink
>
On Wed, Jul 1, 2020 at 6:23 AM Christopher Barker
wrote:
> On Tue, Jun 30, 2020 at 8:55 PM David Lowry-Duda
> wrote:
>
>> On the other hand, it seems far more likely to miss keys in a dictionary
>> than it is to repeatedly mistake indices in a list.
>>
>
> exactly -- dict keys are arbitrary, and
On Mon, Jun 29, 2020 at 06:42:37PM +0100, Stestagg wrote:
> One simple example of where this is surprising is in the following:
>
> >>> random.choice({'a': 1,}.keys())
> TypeError: 'dict_keys' object is not subscriptable
I don't know why you think that is surprising. It doesn't surprise
On 30.06.20 05:08, Steven D'Aprano wrote:
On Tue, Jun 30, 2020 at 11:10:20AM +0900, Inada Naoki wrote:
On Mon, Jun 29, 2020 at 9:12 PM Hans Ginzel wrote:
What are the reasons, why object dict.items() is not subscriptable –
dict.items()[0]?
Because dict is optimized for random access by key
On 01/07/2020 11:24, Steven D'Aprano wrote:
On Tue, Jun 30, 2020 at 07:40:23PM +0100, Rhodri James wrote:
Don't get me wrong, if it's not going to cause performance issues I
think being able to index views would be great
What are your use-cases for indexing set-like views of a dict?
Persona
On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
> This property is nice, as .keys() (for example) can operate like a set and
> give lots of convenience features. However this doesn't really mean that
> these objects are trying to *be* sets in any meaning way,
Please read the PEP:
http
On Wed, Jul 01, 2020 at 01:07:34PM +0200, Dominik Vilsmeier wrote:
> What is the reason for `dict.items` to return a set-like object?
This is the third time I've linked to the PEP:
https://www.python.org/dev/peps/pep-3106/
More than that, you would have to ask Guido, or the designers of the
Ja
On Wed, Jul 01, 2020 at 12:10:12PM +0100, Rhodri James wrote:
> On 01/07/2020 11:24, Steven D'Aprano wrote:
> >On Tue, Jun 30, 2020 at 07:40:23PM +0100, Rhodri James wrote:
> >
> >>Don't get me wrong, if it's not going to cause performance issues I
> >>think being able to index views would be great
> One way to think about is that adding indexing to the views would NOT
make them Sequences, it would simply provide that one feature
As you can see in an e-mail from me in another thread yesterday - `__eq__`,
oddly enough, is not currently a Sequence method,
if we take Sequences to be what is co
On Wed, 1 Jul 2020 at 03:37, Random832 wrote:
> On Tue, Jun 30, 2020, at 10:57, Guido van Rossum wrote:
> > I don't recall why this was done. It seems somewhat odd, since Set and
> > Mapping in the same module do have __eq__. I don't care much for the
> > default implementation though.
> > >
> >
On Wed, Jul 1, 2020 at 12:18 PM Steven D'Aprano wrote:
> On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
>
> > This property is nice, as .keys() (for example) can operate like a set
> and
> > give lots of convenience features. However this doesn't really mean that
> > these objects are
On Wed, Jul 1, 2020 at 12:03 PM Steven D'Aprano wrote:
> On Mon, Jun 29, 2020 at 06:42:37PM +0100, Stestagg wrote:
>
> > One simple example of where this is surprising is in the following:
> >
> > >>> random.choice({'a': 1,}.keys())
> > TypeError: 'dict_keys' object is not subscriptable
>
On Wed, Jul 01, 2020 at 01:36:34PM +0100, Stestagg wrote:
> On Wed, Jul 1, 2020 at 12:18 PM Steven D'Aprano wrote:
>
> > On Tue, Jun 30, 2020 at 10:18:34AM +0100, Stestagg wrote:
> >
> > > This property is nice, as .keys() (for example) can operate like a
> > > set and give lots of convenience f
On Wed, Jul 01, 2020 at 02:12:35PM +0100, Stestagg wrote:
> > And you needed to be told several times before you learned that dicts,
> > and dict views, are not sequences?
>
> I've spent vastly more of my professional career developing in python
> environments where such code worked (python versi
I'll try to unwind the rabbit holes a bit and suggest that the differences
in opinion here boil down to:
Is it most useful to consider dict_keys/items/values as: (This doesn't mean
what isinstance() returns, or what a previous pep has stated, just how one
thinks about them):
1. ordered collection
On 01.07.20 13:32, Steven D'Aprano wrote:
On Wed, Jul 01, 2020 at 01:07:34PM +0200, Dominik Vilsmeier wrote:
What is the reason for `dict.items` to return a set-like object?
This is the third time I've linked to the PEP:
https://www.python.org/dev/peps/pep-3106/
Thanks for linking to the P
For what it's worth, I've attached a patch that implements this as a
prototype.
It's definitely not mergeable right now. I'm not aware of any issues, but
the code needs more error checking, and the coding style doesn't match
cpython's.
Having said that, it's a 70-line change, so fixing that up s
PEP 501 has a very, very brief discussion of this. I'm pretty sure there
was a discussion at the time about user-defined string prefixes, but
since there's a lot of discussion about the inter-related PEPs 498, 501,
and 502, it's hard to find the exact discussion of custom string
prefixes in pyt
This new patch works for keys(), .items(), and .values() (as intended by
the original change)
On Wed, Jul 1, 2020 at 5:27 PM Stestagg wrote:
> For what it's worth, I've attached a patch that implements this as a
> prototype.
>
> It's definitely not mergeable right now. I'm not aware of any is
On Wed, Jul 01, 2020 at 06:07:40PM +0200, Dominik Vilsmeier wrote:
> > Because of the set behavior, it will be possible to check whether two
> > dicts have the same keys by simply testing:
> > if a.keys() == b.keys(): ...
>
> which makes perfectly sense. But then, immediately after that, it ment
22 matches
Mail list logo
