Veek M writes:
> Jussi Piitulainen wrote:
>
>> Veek M writes:
>>
>> [snip]
>>
>>> Also if one can do x.a = 10 or 20 or whatever, and the class instance
>>> is mutable, then why do books keep stating that keys need to be
>>> immutable? After all, __hash__ is the guy doing all the work and
>>> ma
On Sunday, November 27, 2016 at 4:53:20 AM UTC-5, Veek M wrote:
> I was reading this:
> http://stackoverflow.com/questions/4418741/im-able-to-use-a-mutable-object-as-a-dictionary-key-in-python-is-this-not-disa
>
> In a User Defined Type, one can provide __hash__ that returns a integer
> as a key
Veek M wrote:
> Jussi Piitulainen wrote:
>
>> Veek M writes:
>>
>> [snip]
>>
>>> Also if one can do x.a = 10 or 20 or whatever, and the class
>>> instance is mutable, then why do books keep stating that keys need
>>> to be
>>> immutable? After all, __hash__ is the guy doing all the work and
>>
Jussi Piitulainen wrote:
> Veek M writes:
>
> [snip]
>
>> Also if one can do x.a = 10 or 20 or whatever, and the class instance
>> is mutable, then why do books keep stating that keys need to be
>> immutable? After all, __hash__ is the guy doing all the work and
>> maintaining consistency for u
Veek M writes:
[snip]
> Also if one can do x.a = 10 or 20 or whatever, and the class instance
> is mutable, then why do books keep stating that keys need to be
> immutable? After all, __hash__ is the guy doing all the work and
> maintaining consistency for us. One could do:
>
> class Fruit:
>
I was reading this:
http://stackoverflow.com/questions/4418741/im-able-to-use-a-mutable-object-as-a-dictionary-key-in-python-is-this-not-disa
In a User Defined Type, one can provide __hash__ that returns a integer
as a key to a dictionary.
so: d = { key : value }
What is the significance of __
On Tue, May 15, 2012 at 3:25 AM, Christian Heimes wrote:
> Code explains more than words. I've created two examples that some issues.
>
> Mutable values break dicts as you won't be able to retrieve the same
> object again:
Sure, you'll get no argument from me on that. I was more interested
in th
On Monday, May 14, 2012 8:35:36 PM UTC-5, alex23 wrote:
> It looks like this has changed between Python 2 and 3:
>
> "If a class does not define an __eq__() method it should not define a
> __hash__() operation either; if it defines __eq__() but not
> __hash__(), its instances will not be usable as
Am 15.05.2012 07:27, schrieb Ian Kelly:
> Why? I can't see any purpose in implementing __eq__ this way, but I
> don't see how it's "broken" (assuming that __hash__ is actually
> implemented somehow and doesn't just raise TypeError). The
> requirement is that if two objects compare equal, then the
On Tue, May 15, 2012 at 3:27 PM, Ian Kelly wrote:
> Why? I can't see any purpose in implementing __eq__ this way, but I
> don't see how it's "broken" (assuming that __hash__ is actually
> implemented somehow and doesn't just raise TypeError). The
> requirement is that if two objects compare equa
On Mon, May 14, 2012 at 7:50 PM, Christian Heimes wrote:
> Am 13.05.2012 21:11, schrieb Bob Grommes:
>> Noob alert: writing my first Python class library.
>>
>> I have a straightforward class called Utility that lives in Utility.py.
>>
>> I'm trying to get a handle on best practices for fleshing o
Am 13.05.2012 21:11, schrieb Bob Grommes:
> Noob alert: writing my first Python class library.
>
> I have a straightforward class called Utility that lives in Utility.py.
>
> I'm trying to get a handle on best practices for fleshing out a library. As
> such, I've done the following for starters
On May 14, 5:11 am, Bob Grommes wrote:
> Obviously there is some sort of default implementation of __hash__()
> at work and my implementation of _eq_() has somehow broken it.
> Can anyone explain what's going on?
It looks like this has changed between Python 2 and 3:
"If a class does not define
On 05/14/2012 07:38 PM, Chris Kaynor wrote:
> On Sun, May 13, 2012 at 12:11 PM, Bob Grommes wrote:
>>
>>
>> The rule is that, if two objects return different results from
>> __hash__, they should never compare equal. The opposite rule also
>> holds true: if two objects compare equal, they should
On Sun, May 13, 2012 at 12:11 PM, Bob Grommes wrote:
> Noob alert: writing my first Python class library.
>
> I have a straightforward class called Utility that lives in Utility.py.
>
> I'm trying to get a handle on best practices for fleshing out a library. As
> such, I've done the following fo
On Sun, May 13, 2012 at 12:11 PM, Bob Grommes wrote:
> Noob alert: writing my first Python class library.
>
> I have a straightforward class called Utility that lives in Utility.py.
>
> I'm trying to get a handle on best practices for fleshing out a library. As
> such, I've done the following fo
Noob alert: writing my first Python class library.
I have a straightforward class called Utility that lives in Utility.py.
I'm trying to get a handle on best practices for fleshing out a library. As
such, I've done the following for starters:
def __str__(self):
return str(type(self))
#
On Thu, Oct 7, 2010 at 2:28 PM, Christian Heimes wrote:
> Am 07.10.2010 22:02, schrieb Chris Rebert:
>> On Thu, Oct 7, 2010 at 12:13 PM, kj wrote:
>>
>>> It would facilitate the implementation of t() to have a simple test
>>> for mutability. Is there one?
&g
Am 07.10.2010 22:02, schrieb Chris Rebert:
> On Thu, Oct 7, 2010 at 12:13 PM, kj wrote:
>
>> It would facilitate the implementation of t() to have a simple test
>> for mutability. Is there one?
>
> Non-default hashability is an approximate heuristic:
Except that eve
Chris Rebert writes:
> On Thu, Oct 7, 2010 at 1:46 PM, Arnaud Delobelle wrote:
[...]
>> I think defining mutability is subject to opinion, but here is a first
>> approximation.
>>
>>
>> def mutable(obj):
>> return obj.__hash__ is None or type(obj).__hash__ == object.__hash__
>
> Corner case (
On Thu, Oct 7, 2010 at 1:46 PM, Arnaud Delobelle wrote:
> kj writes:
>> I want to implement a test t() that will return True if its two
>> arguments are "completely" different. By this I mean that they
>> don't share any "non-atomic" component. E.g., if
>>
>> a = [0, 1]
>> b = [0, 1]
>> c = [2,
kj writes:
> I want to implement a test t() that will return True if its two
> arguments are "completely" different. By this I mean that they
> don't share any "non-atomic" component. E.g., if
>
> a = [0, 1]
> b = [0, 1]
> c = [2, 3]
> d = [2, 3]
>
> A = (a, c, 0)
> B = (a, d, 1)
> C = (b, d, 0
On Thu, Oct 7, 2010 at 12:13 PM, kj wrote:
> It would facilitate the implementation of t() to have a simple test
> for mutability. Is there one?
Non-default hashability is an approximate heuristic:
def is_immutable(x):
try:
hash(x)
except TypeError:
return
I want to implement a test t() that will return True if its two
arguments are "completely" different. By this I mean that they
don't share any "non-atomic" component. E.g., if
a = [0, 1]
b = [0, 1]
c = [2, 3]
d = [2, 3]
A = (a, c, 0)
B = (a, d, 1)
C = (b, d, 0)
The desired test t() would y
On Wed, 12 Aug 2009 00:33:01 -0700, James Stroud wrote:
> Tell that to two different machines on two different days. Then bet the
> life of yourself and your nearest and dearest family on that fact and
> see whether you really want to take a hash value for granted.
As far as I know, Python doesn
On Aug 12, 10:37 am, James Stroud wrote:
> Steven D'Aprano wrote:
> > Well there you go -- why on earth would you prohibit None as a dictionary
> > key??? That's a serious failure.
>
> roentgen 1% python
> Python 2.5 (r25:51908, Sep 20 2006, 17:36:21)
> [GCC 3.4.2] on linux2
> Type "help", "copyri
On Wed, 12 Aug 2009 10:37:45 -0700, James Stroud wrote:
> Steven D'Aprano wrote:
>> Well there you go -- why on earth would you prohibit None as a
>> dictionary key??? That's a serious failure.
>
>
> roentgen 1% python
> Python 2.5 (r25:51908, Sep 20 2006, 17:36:21) [GCC 3.4.2] on linux2
> Type
On Wed, Aug 12, 2009 at 1:37 PM, James Stroud wrote:
> Steven D'Aprano wrote:
>>
>> Well there you go -- why on earth would you prohibit None as a dictionary
>> key??? That's a serious failure.
>
>
> roentgen 1% python
> Python 2.5 (r25:51908, Sep 20 2006, 17:36:21) [GCC 3.4.2] on linux2
> Type "he
Steven D'Aprano wrote:
Well there you go -- why on earth would you prohibit None as a dictionary
key??? That's a serious failure.
roentgen 1% python
Python 2.5 (r25:51908, Sep 20 2006, 17:36:21)
[GCC 3.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py>
On Tue, 11 Aug 2009 17:54:36 -0700, James Stroud wrote:
> Hello All,
>
> I wrote the function to test hashability of arbitrary objects. My reason
> is that the built-in python (2.5) hashing is too permissive for some
> uses. A symptom of this permissiveness comes from
Dennis Lee Bieber wrote:
On Tue, 11 Aug 2009 17:54:36 -0700, James Stroud
declaimed the following in gmane.comp.python.general:
...
py> {C():4}[C()]
Traceback (most recent call last):
File "", line 1, in
: <__mai
On Aug 12, 5:14 pm, Dennis Lee Bieber wrote:
> c1 = C()
> c2 = C()
>
> {c1:4}[c2]
>
> to behave? That IS the equivalent of your statement -- two instances are
> two distinctly different entities...
>
Thankyou, that is EXACTLY the mistake I made that sent me off into
lunacy.
At the risk of furth
On Aug 12, 4:52 pm, James Stroud
wrote:
> Sorry for being a twit.
Don't be ridiculous. You haven't been a twit, I have!
I've just had a complete "blonde" moment here (with apologies to any
real blondes out there. My only excuse is that I've been up to 02:30
for the last three nights running (
Asun Friere wrote:
On Aug 12, 3:32 pm, James Stroud
wrote:
You should be more imaginative.
I'm by no means discounting that there might be some actual problem
you're trying to solve here, but I honestly can't see it.
There really is no need to get personal about this, so rather than
asking
On Wed, Aug 12, 2009 at 2:18 AM, Asun Friere wrote:
> On Aug 12, 3:32 pm, James Stroud
> wrote:
>
>> You should be more imaginative.
>
> I'm by no means discounting that there might be some actual problem
> you're trying to solve here, but I honestly can't see it.
How about a cache? Hashing by id
On Aug 12, 3:52 pm, Chris Rebert wrote:
> Thought Experiment:
> Consider, for each dict, the case of pickling it twice to 2 separate files.
> When loaded from both files into the same program, the spam-ham dicts
> will work as expected between each other.
> The dicts with C()s will not. For examp
On Wed, Aug 12, 2009 at 2:25 AM, Chris Rebert wrote:
> 2009/8/11 Asun Friere :
>> On Aug 12, 12:15 pm, James Stroud wrote:
Apologies for the possible repeated post. Gmail failed to mark the
draft as sent for some reason.
- Chris
--
http://mail.python.org/mailman/listinfo/python-list
2009/8/11 Asun Friere :
> On Aug 12, 12:15 pm, James Stroud wrote:
>
>> I realize I left out my use. The intent of the function is to flag
>> objects that will make useful keys for a persistent dictionary. The
>> {C():4}[C()] example demonstrates why I want to avoid certain types of
>> keys--I don
On Aug 12, 3:32 pm, James Stroud
wrote:
> You should be more imaginative.
I'm by no means discounting that there might be some actual problem
you're trying to solve here, but I honestly can't see it.
There really is no need to get personal about this, so rather than
asking for a level of imagin
2009/8/11 Asun Friere :
> On Aug 12, 12:15 pm, James Stroud wrote:
>
>> I realize I left out my use. The intent of the function is to flag
>> objects that will make useful keys for a persistent dictionary. The
>> {C():4}[C()] example demonstrates why I want to avoid certain types of
>> keys--I don
Asun Friere wrote:
Perhaps the best solution would be for the unitiated to correct their
misaprehensions
Can you come give a class to my users?
--
http://mail.python.org/mailman/listinfo/python-list
Asun Friere wrote:
On Aug 12, 12:15 pm, James Stroud wrote:
I realize I left out my use. The intent of the function is to flag
objects that will make useful keys for a persistent dictionary. The
{C():4}[C()] example demonstrates why I want to avoid certain types of
keys--I don't want users to
On Aug 12, 12:15 pm, James Stroud wrote:
> I realize I left out my use. The intent of the function is to flag
> objects that will make useful keys for a persistent dictionary. The
> {C():4}[C()] example demonstrates why I want to avoid certain types of
> keys--I don't want users to do things like
Carl Banks wrote:
On Aug 11, 5:54 pm, James Stroud wrote:
To prevent users of one of my libraries from falling into this and
similar traps (which have potentially problematic consequences),
Even so, I would consider whether some of your users might, like me,
also find this terribly useful, a
On Aug 12, 10:54 am, James Stroud wrote:
> I wrote the function to test hashability of arbitrary objects. My reason
> is that the built-in python (2.5) hashing is too permissive for some
> uses. A symptom of this permissiveness comes from the ability to
> successfully hash() arbit
On Aug 11, 5:54 pm, James Stroud wrote:
> Hello All,
>
> I wrote the function to test hashability of arbitrary objects. My reason
> is that the built-in python (2.5) hashing is too permissive for some
> uses. A symptom of this permissiveness comes from the ability to
>
Hello All,
I wrote the function to test hashability of arbitrary objects. My reason
is that the built-in python (2.5) hashing is too permissive for some
uses. A symptom of this permissiveness comes from the ability to
successfully hash() arbitrary objects:
py> class C(object): p
47 matches
Mail list logo
