On 2019-12-11 7:40 a.m., Jonathan Fine wrote:
Consider these two examples:
>>> {0} == {0.0} == {False}
True
>>> hash(0) == hash(0.0) == hash(False)
True
>>> 0.0 in {False}
True
>>> class mystr(str): pass
>>> 'hi' in {mystr('hi')}
True
The original poster want a way to obtain the actual
Consider these two examples:
>>> {0} == {0.0} == {False}
True
>>> hash(0) == hash(0.0) == hash(False)
True
>>> 0.0 in {False}
True
>>> class mystr(str): pass
>>> 'hi' in {mystr('hi')}
True
The original poster want a way to obtain the actual object that is in the
set, rather than just a truth
> 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 =
On Wed, Dec 04, 2019 at 07:11:39PM +1300, Greg Ewing wrote:
> On 4/12/19 12:53 pm, Soni L. wrote:
> >Okay, sometimes it's also used for that. But the main use-case is for
> >lowering RAM usage for immutable objects.
>
> Citation needed. If that's true, why does Python intern
> names used in
On Dec 3, 2019, at 20:45, Steven D'Aprano wrote:
>
> 1. A lot of collections define element equality using an identity test
> first as an optimization (even if that means that they do the wrong
> thing when NANs are involved). So that's prima facie evidence that using
> `is` will be faster.
On 4/12/19 12:53 pm, Soni L. wrote:
Okay, sometimes it's also used for that. But the main use-case is for
lowering RAM usage for immutable objects.
Citation needed. If that's true, why does Python intern
names used in code, but not strings in general? I'd say
because looking names up in dicts
On Tue, Dec 03, 2019 at 10:26:35AM -0800, Andrew Barnert wrote:
> If you’re using interning for functionality, to distinguish two equal
> strings that came from different inputs or processes, your code is
> probably broken.
That's not how interning works. The purpose of interning is to
On Dec 3, 2019, at 15:45, Greg Ewing wrote:
>
> On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote:
>> If you’re using interning for functionality, to distinguish two equal
>> strings that came from different inputs or processes, your code is probably
>> broken.
>
> That's not what
On 2019-12-03 8:44 p.m., Greg Ewing wrote:
On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote:
If you’re using interning for functionality, to distinguish two equal
strings that came from different inputs or processes, your code is
probably broken.
That's not what interning is
On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote:
If you’re using interning for functionality, to distinguish two equal strings
that came from different inputs or processes, your code is probably broken.
That's not what interning is normally used for. Usually it's
to allow test for
On Wed, Dec 4, 2019 at 5:27 AM Andrew Barnert via Python-ideas
wrote:
>
> By the way, intern was still there until 2.7, but in that list of “we can’t
> deprecate these but please never use them” functions at the end of builtins,
> so you didn’t actually need 1.5 to test it. But I understand;
> On Dec 3, 2019, at 03:41, Steven D'Aprano wrote:
> On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas
> wrote:
> On Dec 2, 2019, at 16:27, Soni L. wrote:
Even use-cases where you have different objects whose differences are
ignored for __eq__ and
On 2019-12-03 8:34 a.m., Steven D'Aprano wrote:
On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas wrote:
> On Dec 2, 2019, at 16:27, Soni L. wrote:
> >
> > Even use-cases where you have different objects whose differences are ignored for __eq__ and __hash__ and you
On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas wrote:
> On Dec 2, 2019, at 16:27, Soni L. wrote:
> >
> > Even use-cases where you have different objects whose differences are
> > ignored for __eq__ and __hash__ and you want to grab the one from the set
> > ignoring
On Dec 2, 2019, at 16:27, Soni L. wrote:
>
> Even use-cases where you have different objects whose differences are ignored
> for __eq__ and __hash__ and you want to grab the one from the set ignoring
> their differences would benefit from this.
A more concrete use case might help make the
On Dec 2, 2019, at 22:40, Random832 wrote:
>
> The OP wanted to return the object that was in the set. I don't think there's
> currently a way to get it in O(1) time
Yeah, intersection is basically just {key for key in smaller_set if key in
larger_set}, so it’s always going to return the
03.12.19 02:25, Soni L. пише:
This is an odd request but it'd be nice if, given a set s = {"foo"},
s["foo"] returned the "foo" object that is actually in the set, or
KeyError if the object is not present.
Even use-cases where you have different objects whose differences are
ignored for
On Tue, Dec 3, 2019, at 01:02, Kyle Stanley wrote:
> However, if the OP wants to personally implement this behavior for
> their own subclass of sets (instead of adding it to the language), that
> could be done rather easily:
The OP wanted to return the object that was in the set. I don't think
> FWIW, you can do it with dict already.
> o = memo.setdefault(o, o)
I don't think this has quite the same behavior as the OP is looking for,
since dict.setdefault() will insert the key and return the default when
it's not present, instead the OP wanted to raise "KeyError if the object is
not
FWIW, you can do it with dict already.
o = memo.setdefault(o, o)
On Tue, Dec 3, 2019 at 9:29 AM Soni L. wrote:
>
> This is an odd request but it'd be nice if, given a set s = {"foo"},
> s["foo"] returned the "foo" object that is actually in the set, or
> KeyError if the object is not present.
>
20 matches
Mail list logo
