On Tue, May 15, 2012 at 3:27 PM, Ian Kelly ian.g.ke...@gmail.com 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
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 they
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
On Tue, May 15, 2012 at 3:25 AM, Christian Heimes li...@cheimes.de 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
On Sun, May 13, 2012 at 12:11 PM, Bob Grommes bob.grom...@gmail.com 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
On Sun, May 13, 2012 at 12:11 PM, Bob Grommes bob.grom...@gmail.com 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
On 05/14/2012 07:38 PM, Chris Kaynor wrote:
On Sun, May 13, 2012 at 12:11 PM, Bob Grommes bob.grom...@gmail.com wrote:
SNIP
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
On May 14, 5:11 am, Bob Grommes bob.grom...@gmail.com 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
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 Mon, May 14, 2012 at 7:50 PM, Christian Heimes li...@cheimes.de 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
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't
On Aug 12, 3:32 pm, James Stroud nospamjstroudmap...@mbi.ucla.edu
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
2009/8/11 Asun Friere afri...@yahoo.co.uk:
On Aug 12, 12:15 pm, James Stroud jstr...@mbi.ucla.edu 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
On Wed, Aug 12, 2009 at 2:25 AM, Chris Rebertc...@rebertia.com wrote:
2009/8/11 Asun Friere afri...@yahoo.co.uk:
On Aug 12, 12:15 pm, James Stroud jstr...@mbi.ucla.edu wrote:
Apologies for the possible repeated post. Gmail failed to mark the
draft as sent for some reason.
- Chris
--
On Aug 12, 3:52 pm, Chris Rebert ch...@rebertia.com 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
On Wed, Aug 12, 2009 at 2:18 AM, Asun Friereafri...@yahoo.co.uk wrote:
On Aug 12, 3:32 pm, James Stroud nospamjstroudmap...@mbi.ucla.edu
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
Asun Friere wrote:
On Aug 12, 3:32 pm, James Stroud nospamjstroudmap...@mbi.ucla.edu
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
On Aug 12, 4:52 pm, James Stroud nospamjstroudmap...@mbi.ucla.edu
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
On Aug 12, 5:14 pm, Dennis Lee Bieber wlfr...@ix.netcom.com 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
Dennis Lee Bieber wrote:
On Tue, 11 Aug 2009 17:54:36 -0700, James Stroud jstr...@mbi.ucla.edu
declaimed the following in gmane.comp.python.general:
...
py {C():4}[C()]
Traceback (most recent call last):
File ipython
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
successfully
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 Wed, Aug 12, 2009 at 1:37 PM, James Stroudjstr...@mbi.ucla.edu 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
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 help,
On Aug 12, 10:37 am, James Stroud jstr...@mbi.ucla.edu 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 Aug 11, 5:54 pm, James Stroud jstr...@mbi.ucla.edu 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
On Aug 12, 10:54 am, James Stroud jstr...@mbi.ucla.edu 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()
Carl Banks wrote:
On Aug 11, 5:54 pm, James Stroud jstr...@mbi.ucla.edu 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
On Aug 12, 12:15 pm, James Stroud jstr...@mbi.ucla.edu 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
Asun Friere wrote:
On Aug 12, 12:15 pm, James Stroud jstr...@mbi.ucla.edu 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
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
2009/8/11 Asun Friere afri...@yahoo.co.uk:
On Aug 12, 12:15 pm, James Stroud jstr...@mbi.ucla.edu 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
32 matches
Mail list logo
