On 8/11/17 6:37 AM, Python wrote:
> Marko Rauhamaa wrote:
>> Python :
>>
>>> Marko Rauhamaa wrote:
>>> I didn't disagree with any of these statements about __hash__, but only
>>> your statement about id and __eq__:
>>>
id() is actually an ideal return value of __hash__(). The only
criter
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
I didn't disagree with any of these statements about __hash__, but only
your statement about id and __eq__:
id() is actually an ideal return value of __hash__(). The only
criterion is that the returned number should be different if the
__e
Marko Rauhamaa wrote:
Of course, some algorithms can (and, we have learned, do) prefer some
bits over others, but that's inside the implementation black box. I
would think every bit should carry an approximately equal weight.
Ideally that would be true, but you need to consider the performance
Steve D'Aprano wrote:
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
which I think agrees with my comment: using the id() itself would put too many
objects in the same b
Python wrote:
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id()
nan is a clear, simple, undeniable counterexample to that claim.
It's a cou
Chris Angelico :
> On Fri, Aug 11, 2017 at 7:17 AM, Marko Rauhamaa wrote:
>> That's interesting, but suggests there's something weird (~ suboptimal)
>> going on with CPython's scrambling algorithm. Also, your performance
>> test might yield completely different results on other Python
>> implemen
On Fri, Aug 11, 2017 at 7:17 AM, Marko Rauhamaa wrote:
> That's interesting, but suggests there's something weird (~ suboptimal)
> going on with CPython's scrambling algorithm. Also, your performance
> test might yield completely different results on other Python
> implementations.
>
> Apart from
Chris Angelico :
> I'm aware of this. Doesn't change the fact that the *INITIAL INDEX* is
> based on exactly what I said.
>
> Yaknow?
What you're saying is that CPython heavily prefers the low-order bits to
be unique performance-wise. I don't know why that particular heuristic
bias was chosen.
Peter Otten <__pete...@web.de>:
> Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Let's see:
>
> $ cat hashperf.py
> class A(object):
> __slots__ = ["_hash"]
>
> def __hash__(self):
> return self._hash
>
> def no_magic():
> a = A()
> a._hash = id(a)
On Fri, Aug 11, 2017 at 6:56 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>>> I see no point in CPython's rotation magic.
>>
>> Have you ever implemented a hashtable? The most common way to pick a
>> bucket for an object is to use modulo
Chris Angelico :
> On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
>> I see no point in CPython's rotation magic.
>
> Have you ever implemented a hashtable? The most common way to pick a
> bucket for an object is to use modulo on the number of buckets.
Like I said earlier, CPython takes t
Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my comment: using the id() itsel
On Fri, Aug 11, 2017 at 6:03 AM, Marko Rauhamaa wrote:
> Peter Otten <__pete...@web.de>:
>
>> Steve D'Aprano wrote:
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive hash collisions for dicts and sets */
>>>
>>> which I think agrees with my
Peter Otten <__pete...@web.de>:
> Steve D'Aprano wrote:
>> The C code says:
>>
>>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees with my comment: using the id() itself would put
>> too many objects in
Steve D'Aprano wrote:
> The C code says:
>
>>/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too
> many objects in the same bucket (i.e. too many collision
Python :
> Marko Rauhamaa wrote:
> I didn't disagree with any of these statements about __hash__, but only
> your statement about id and __eq__:
>
>> id() is actually an ideal return value of __hash__(). The only
>> criterion is that the returned number should be different if the
>> __eq__() is Fa
On Fri, Aug 11, 2017 at 2:41 AM, Steve D'Aprano
wrote:
> On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
>
>> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
>> wrote:
>>
>>> The C code says:
>>>
/* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
excessive
On Fri, 11 Aug 2017 12:58 am, Chris Angelico wrote:
> On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
> wrote:
>
>> The C code says:
>>
>>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>>excessive hash collisions for dicts and sets */
>>
>> which I think agrees
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (
Python :
> Marko Rauhamaa wrote:
>> Python :
>>
>>> Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
>>>
>>> $ python
>>> Python
On Fri, Aug 11, 2017 at 12:45 AM, Steve D'Aprano
wrote:
> The C code says:
>
>> /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid
>>excessive hash collisions for dicts and sets */
>
> which I think agrees with my comment: using the id() itself would put too many
> objec
On Thu, 10 Aug 2017 07:00 pm, Peter Otten wrote:
> Steven D'Aprano wrote:
>
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Pytho
Marko Rauhamaa wrote:
Python :
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[G
Python :
> Marko Rauhamaa wrote:
>> id() is actually an ideal return value of __hash__(). The only criterion
>> is that the returned number should be different if the __eq__() is
>> False. That is definitely true for id().
>
> $ python
> Python 2.7.13 (default, Jan 19 2017, 14:48:08)
> [GCC 6.3.0
Marko Rauhamaa wrote:
id() is actually an ideal return value of __hash__(). The only criterion
is that the returned number should be different if the __eq__() is
False. That is definitely true for id().
$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type
Peter Otten <__pete...@web.de>:
> Steven D'Aprano wrote:
>> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>>
>>> Good point! A very good __hash__() implementation is:
>>>
>>> def __hash__(self):
>>> return id(self)
>>>
>>> In fact, I didn't know Python (kinda) did this by
Steven D'Aprano wrote:
> On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
>
>> Good point! A very good __hash__() implementation is:
>>
>> def __hash__(self):
>> return id(self)
>>
>> In fact, I didn't know Python (kinda) did this by default already. I
>> can't find that in
On Wed, 09 Aug 2017 20:07:48 +0300, Marko Rauhamaa wrote:
> Good point! A very good __hash__() implementation is:
>
> def __hash__(self):
> return id(self)
>
> In fact, I didn't know Python (kinda) did this by default already. I
> can't find that information in the definition of obje
Chris Angelico :
> On Wed, Aug 9, 2017 at 11:46 PM, Marko Rauhamaa wrote:
>> Really, the most obvious use case for hashed objects is their membership
>> in a set. For example:
>>
>> invitees = set(self.bff)
>> invitees |= self.classmates()
>> invitees |= self.relatives()
>
> Okay. So
On Wed, 9 Aug 2017 11:46 pm, Marko Rauhamaa wrote:
> Typically, an object's equality is simply the "is" relation.
"Typically"? I don't think so. Are you sure you've programmed in Python before?
*wink*
py> [1, 2] is [1, 2]
False
The most commonly used objects don't define equality as identity, e
On Wed, Aug 9, 2017 at 11:46 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
>>> Chris Angelico :
>>>
Which means that its value won't change. That's what I said. Two
things will be equal regardless of that metadata.
>>>
>>> In re
Chris Angelico :
> On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> Which means that its value won't change. That's what I said. Two
>>> things will be equal regardless of that metadata.
>>
>> In relational-database terms, your "value" is the primary key and
>> yo
On 8/9/2017 9:25 AM, Marko Rauhamaa wrote:
> r...@zedat.fu-berlin.de (Stefan Ram):
>
>> Steve D'Aprano writes:
>>> There's a word for frozen list: "tuple".
>> Yes, but one should not forget that a tuple
>> can contain mutable entries (such as lists).
> Not when used as keys:
>
> >>> hash
r...@zedat.fu-berlin.de (Stefan Ram):
> Steve D'Aprano writes:
>>There's a word for frozen list: "tuple".
>
> Yes, but one should not forget that a tuple
> can contain mutable entries (such as lists).
Not when used as keys:
>>> hash(([], []))
Traceback (most recent call last):
On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Which means that its value won't change. That's what I said. Two
>> things will be equal regardless of that metadata.
>
> In relational-database terms, your "value" is the primary key and your
> "metadata" is the rest o
On Wed, 9 Aug 2017 08:38 pm, Marko Rauhamaa wrote:
> sometimes you really would like an immutable
> (or rather, no-longer-mutable) list to act as a key.
There's a word for frozen list: "tuple".
:-)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, thi
On Wed, 9 Aug 2017 02:19 pm, Dennis Lee Bieber wrote:
> On Tue, 8 Aug 2017 15:38:42 + (UTC), Grant Edwards
> declaimed the following:
>
>>On 2017-08-08, Peter Heitzer wrote:
[...]
>>> The differences between blanks and tabs :-)
>>
>>You've misspelled "Tabs are evil and should never be used"
On Wed, 9 Aug 2017 07:51 pm, Marko Rauhamaa wrote:
> Dennis Lee Bieber :
>
>> Then there is the facet that tuples (being unmutable) can be used as
>> keys into a dictionary...
>
> Mutable objects can be used as keys into a dictionary.
Indeed.
And people can also put their hand into a fire in o
On Wed, Aug 9, 2017 at 8:00 AM, Marko Rauhamaa wrote:
> Yeah, when there's a will, there's a way.
My Dad used to say "Where there's a will, there's relatives."
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico :
> On Wed, Aug 9, 2017 at 8:38 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
Mutable objects can be used as keys into a dictionary.
>>>
>>> Only when the objects' mutability does not affect their values.
>>
>> Up t
On Wed, Aug 9, 2017 at 8:38 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
>>> Mutable objects can be used as keys into a dictionary.
>>
>> Only when the objects' mutability does not affect their values.
>
> Up to equality. The objects can
On Tue, 08 Aug 2017 14:19:53 +, Stefan Ram wrote:
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave in other
> languages, that means, the course starts roughly with these topics:
>
> - number and string literals - types of number and string liter
Chris Angelico :
> On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
>> Mutable objects can be used as keys into a dictionary.
>
> Only when the objects' mutability does not affect their values.
Up to equality. The objects can carry all kinds of mutable payload as
long as __hash__() and __eq
On Wed, Aug 9, 2017 at 7:51 PM, Marko Rauhamaa wrote:
> Dennis Lee Bieber :
>
>> Then there is the facet that tuples (being unmutable) can be used as
>> keys into a dictionary...
>
> Mutable objects can be used as keys into a dictionary.
Only when the objects' mutability does not affect the
Dennis Lee Bieber :
> Then there is the facet that tuples (being unmutable) can be used as
> keys into a dictionary...
Mutable objects can be used as keys into a dictionary.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Dennis Lee Bieber :
> Tabs are logical entities indicating structure and should always be
> used!
I wrote an entire database program using only tabs.
http://dilbert.com/strip/1992-09-08>
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Aug 8, 2017 10:20 AM, "Stefan Ram" wrote:
>
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave
> in other languages, that means, the course starts roughly
> with these topics:
>
> - number and string literals
> - types of number and string litera
On 2017-08-08, Peter Heitzer wrote:
> Stefan Ram wrote:
>> I am planning a Python course.
> [different topics]
>> Are there any other very simple things that
>> I have missed and that should be covered very
>> early in a Python course?
>
> The differences between blanks and tabs :-)
You've
On Tue, Aug 8, 2017 at 7:19 AM, Stefan Ram wrote:
> I am planning a Python course.
>
> I started by writing the course akin to courses I gave
> in other languages, that means, the course starts roughly
> with these topics:
>
> - number and string literals
> - types of number and string li
On Wed, Aug 9, 2017 at 1:02 AM, Stefan Ram wrote:
> Chris Angelico writes:
>>Why a new Python course?
>
> It is not a course in the sense of a written text
> (which I would call "course notes").
>
> It is a course in the sense of an event, where I will meet
> participants in a classroom.
Stefan Ram wrote:
> I am planning a Python course.
[different topics]
> Are there any other very simple things that
> I have missed and that should be covered very
> early in a Python course?
The differences between blanks and tabs :-)
--
Dipl.-Inform(FH) Peter Heitzer, peter.heit...@rz.u
On Wed, Aug 9, 2017 at 12:19 AM, Stefan Ram wrote:
> I am planning a Python course.
>
Before answering any other questions, answer this one:
Why a new Python course? How is it different from what already exists?
The answer to that will govern just about everything else. The
specifics that you
52 matches
Mail list logo
