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
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 the ability to
> successfull
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() arbitrary objects:
A
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
> successfully hash() arbitrar
32 matches
Mail list logo
