Re: Hash stability

Am 16.01.2012 09:44, schrieb Christian Heimes: Am 16.01.2012 09:18, schrieb Peter Otten: I've taken a quick look into the suds source; the good news is that you have to change a single method, reader.Reader.mangle(), to fix the problem with hash stability. However, I didn't see any code to deal

Re: Hash stability

Am 16.01.2012 09:18, schrieb Peter Otten: > I've taken a quick look into the suds source; the good news is that you have > to change a single method, reader.Reader.mangle(), to fix the problem with > hash stability. > > However, I didn't see any code to deal with hash collisions at all. It sme

Re: Hash stability

Heiko Wundram wrote: > Am 15.01.2012 13:22, schrieb Peter Otten: >> I'm curious: did you actually get false cache hits in a suds cache >> or just slower responses? > It broke the application using suds, not due to false cache hits, but > due to not getting a cache hit anymore at all. > so ba

Re: Hash stability

Chris Angelico, 15.01.2012 17:13: > Of course, it's still dodgy to depend on the stability of something > that isn't proclaimed stable, and would be far better to use some > other hashing algorithm (MD5 or SHA for uberreliability). I've seen things like MD5 or SHA* being used quite commonly for fi

Re: Hash stability

Am 15.01.2012 17:13, schrieb Chris Angelico: On Mon, Jan 16, 2012 at 3:07 AM, Heiko Wundram wrote: I don't know the prevalence of suds, but I guess there's more people than me using it to query SOAP-services - all of those will be affected if the hash() output is changed. Additionally, if hash(

Re: Hash stability

On Mon, Jan 16, 2012 at 3:07 AM, Heiko Wundram wrote: > I don't know the prevalence of suds, but I guess there's more people than me > using it to query SOAP-services - all of those will be affected if the > hash() output is changed. Additionally, if hash() isn't stable between runs > (the randomi

Re: Hash stability

Am 15.01.2012 13:22, schrieb Peter Otten: Heiko Wundram wrote: I agree completely with that (I hit the corresponding problem with suds while transitioning from 32-bit Python to 64-bit Python, where hashes aren't stable either), but as stated in my mail: that wasn't the original question. ;-) I

Re: Hash stability

Heiko Wundram wrote: > Am 15.01.2012 11:13, schrieb Stefan Behnel: >> That's a stupid design. Using a hash function that the application does >> not control to index into persistent storage just screams for getting the >> code broken at some point. > > I agree completely with that (I hit the corr

Re: Hash stability

On Sun, Jan 15, 2012 at 11:03 PM, Bryan wrote: > Chris Angelico wrote: >> Suggestion: Create a subclass of dict, the SecureDict or something, >> ... there's no point adding extra load to every >> name lookup just because of a security issue in an extremely narrow >> situation. > > That seemingly "

Re: Hash stability

Chris Angelico wrote: > Suggestion: Create a subclass of dict, the SecureDict or something, > which could either perturb the hashes or even use a proper > cryptographic hash function; normal dictionaries can continue to use > the current algorithm. The description in Objects/dictnotes.txt > suggest

Re: Hash stability

Am 15.01.2012 11:13, schrieb Stefan Behnel: That's a stupid design. Using a hash function that the application does not control to index into persistent storage just screams for getting the code broken at some point. I agree completely with that (I hit the corresponding problem with suds while

Re: Hash stability

Heiko Wundram, 14.01.2012 23:45: > Am 14.01.2012 10:46, schrieb Peter Otten: >> Steven D'Aprano wrote: >>> How many people rely on hash(some_string) being stable across Python >>> versions? Does anyone have code that will be broken if the string hashing >>> algorithm changes? >> >> Nobody who under

Re: Hash stability

On 1/14/2012 9:26 PM, Roy Smith wrote: Steven D'Aprano wrote: How many people rely on hash(some_string) being stable across Python versions? Does anyone have code that will be broken if the string hashing algorithm changes? I would never rely on something like that unless the docs unambiguo

Re: Hash stability

In article <4f1107b7$0$29988$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions

Re: Hash stability

On Sat, Jan 14, 2012 at 3:42 PM, Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions? Does anyone have code that will be b

Re: Hash stability

Am 14.01.2012 10:46, schrieb Peter Otten: Steven D'Aprano wrote: How many people rely on hash(some_string) being stable across Python versions? Does anyone have code that will be broken if the string hashing algorithm changes? Nobody who understands the question ;) Erm, not exactly true. The

Re: Hash stability

Steven D'Aprano wrote: > On the Python Dev mailing list, there is a discussion going on about the > stability of the hash function for strings. > > How many people rely on hash(some_string) being stable across Python > versions? Does anyone have code that will be broken if the string hashing > al

Re: hash values and equality

On Sat, 21 May 2011 15:55:56 -0700, John Nagle wrote: > On 5/19/2011 11:33 PM, Ulrich Eckhardt wrote: > >> For that reason, it is generally useful to use immutable types like >> integers, floats, strings and tuples thereof as keys. Since you can't >> change them, you basically have the guarantee

Re: hash values and equality

On 22-5-2011 0:55, John Nagle wrote: > On 5/19/2011 11:33 PM, Ulrich Eckhardt wrote: > >> For that reason, it is generally useful to use immutable types like >> integers, floats, strings and tuples thereof as keys. Since you can't change >> them, you basically have the guarantee that they hash the

Re: hash values and equality

On 5/19/2011 11:33 PM, Ulrich Eckhardt wrote: For that reason, it is generally useful to use immutable types like integers, floats, strings and tuples thereof as keys. Since you can't change them, you basically have the guarantee that they hash the same. Right. It's something of a lack tha

Re: hash values and equality

Gregory Ewing wrote: > Ethan Furman wrote: >> Ulrich Eckhardt wrote: >> >>> If two equal objects have different hashes, they >>> will be stored in different places in the hash map. Looking for >>> object1 will then not turn up with object2, even though they are equal. >> >> In this case this is

Re: hash values and equality

Ethan Furman wrote: Ulrich Eckhardt wrote: If two equal objects have different hashes, they will be stored in different places in the hash map. Looking for object1 will then not turn up with object2, even though they are equal. In this case this is the behavior I want. You can't rely on i

Re: hash values and equality

On Sat, 21 May 2011 02:02:48 +0100, MRAB wrote: > On 21/05/2011 01:47, Steven D'Aprano wrote: >> On Fri, 20 May 2011 21:17:29 +0100, MRAB wrote: >> >>> On 20/05/2011 20:01, Christian Heimes wrote: Am 20.05.2011 17:50, schrieb MRAB: > Is this strictly true? I thought that the hash value, a

Re: hash values and equality

On 21/05/2011 01:47, Steven D'Aprano wrote: On Fri, 20 May 2011 21:17:29 +0100, MRAB wrote: On 20/05/2011 20:01, Christian Heimes wrote: Am 20.05.2011 17:50, schrieb MRAB: Is this strictly true? I thought that the hash value, an integer, is moduloed (Is that how you spell it? Looks weird!) ..

Re: hash values and equality

On Fri, 20 May 2011 21:17:29 +0100, MRAB wrote: > On 20/05/2011 20:01, Christian Heimes wrote: >> Am 20.05.2011 17:50, schrieb MRAB: >>> Is this strictly true? I thought that the hash value, an integer, is >>> moduloed (Is that how you spell it? Looks weird!) ... >> >> I don't think 'moduloed' is

Re: hash values and equality

Peter Otten wrote: Ethan Furman wrote: Peter Otten wrote: Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ --> class Wierd(): ... def __init__(self

Re: hash values and equality

Ethan Furman wrote: > Peter Otten wrote: >> Ethan Furman wrote: >> >>> Several folk have said that objects that compare equal must hash equal, >>> and the docs also state this >>> http://docs.python.org/dev/reference/datamodel.html#object.__hash__ >>> >>> I'm hoping somebody can tell me what horr

Re: hash values and equality

On 20/05/2011 20:01, Christian Heimes wrote: Am 20.05.2011 17:50, schrieb MRAB: Is this strictly true? I thought that the hash value, an integer, is moduloed (Is that how you spell it? Looks weird!) with the number of array elements to give an index into the array, so different hashes could give

Re: hash values and equality

Am 20.05.2011 17:50, schrieb MRAB: > Is this strictly true? I thought that the hash value, an integer, is > moduloed (Is that how you spell it? Looks weird!) with the number of > array elements to give an index into the array, so different hashes > could give the same index, and objects with differ

Re: hash values and equality

On Fri, May 20, 2011 at 10:56 AM, Ethan Furman wrote: > Chris Rebert wrote: >> On Thu, May 19, 2011 at 10:43 PM, Ethan Furman wrote: >>> Several folk have said that objects that compare equal must hash equal, >>> and >>> the docs also state this >>> http://docs.python.org/dev/reference/datamodel.

Re: hash values and equality

Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ Two things I didn't make clear originally: I'm using Python3. My objects (of type Wierd) obey the prem

Re: hash values and equality

Ulrich Eckhardt wrote: Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ I'm hoping somebody can tell me what horrible thing will happen if this isn't the c

Re: hash values and equality

On Fri, May 20, 2011 at 10:36 AM, Chris Kaynor wrote: > I think the question was: can this dummy code ever produce a set containing > less then itemCount items (for 0 < itemCount < 2**32)? In CPython, no. Even when you get a hash collision, the code checks to see whether the hashes are actually

Re: hash values and equality

Peter Otten wrote: Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ I'm hoping somebody can tell me what horrible thing will happen if this isn't the case

Re: hash values and equality

Chris Rebert wrote: On Thu, May 19, 2011 at 10:43 PM, Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ I'm hoping somebody can tell me what horrible thing

Re: hash values and equality

On Fri, May 20, 2011 at 9:20 AM, Chris Angelico wrote: > On Sat, May 21, 2011 at 1:50 AM, MRAB wrote: > > [snip] > > Is this strictly true? I thought that the hash value, an integer, is > > moduloed (Is that how you spell it? Looks weird!) with the number of > > array elements to give an index i

Re: hash values and equality

On Sat, May 21, 2011 at 1:50 AM, MRAB wrote: > [snip] > Is this strictly true? I thought that the hash value, an integer, is > moduloed (Is that how you spell it? Looks weird!) with the number of > array elements to give an index into the array, so different hashes > could give the same index, and

Re: hash values and equality

On 20/05/2011 07:33, Ulrich Eckhardt wrote: Ethan Furman wrote: Several folk have said that objects that compare equal must hash equal, and the docs also state this http://docs.python.org/dev/reference/datamodel.html#object.__hash__ I'm hoping somebody can tell me what horrible thing will happe

Re: hash values and equality

Ethan Furman wrote: > Several folk have said that objects that compare equal must hash equal, > and the docs also state this > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > I'm hoping somebody can tell me what horrible thing will happen if this > isn't the case? If you w

Re: hash values and equality

On Thu, May 19, 2011 at 10:43 PM, Ethan Furman wrote: > Several folk have said that objects that compare equal must hash equal, and > the docs also state this > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > I'm hoping somebody can tell me what horrible thing will happen i

Re: hash values and equality

Ethan Furman wrote: > Several folk have said that objects that compare equal must hash equal, > and the docs also state this > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > I'm hoping somebody can tell me what horrible thing will happen if this > isn't the case? Here's

Re: hash and __eq__

In article <0233137f$0$8244$c3e8...@news.astraweb.com>, Steven D'Aprano wrote: >On Sun, 31 May 2009 12:08:33 +0100, Arnaud Delobelle wrote: > >> Anyway, it's good to know that quicksort is O(n^2) in the worst case - >> and that this worst case can crop up very easily in some situations, >> especi

Re: hash and __eq__

In article <003e1491$0$9723$c3e8...@news.astraweb.com>, Steven D'Aprano wrote: >On Sun, 31 May 2009 07:24:09 +0100, Arnaud Delobelle wrote: >> >> AFAIK, 'complexity' means 'worst case complexity' unless otherwise >> stated. > >No, it means "average or typical case" unless otherwise specified. >C

Re: hash and __eq__

Steven D'Aprano wrote: On Sun, 31 May 2009 12:08:33 +0100, Arnaud Delobelle wrote: Anyway, it's good to know that quicksort is O(n^2) in the worst case - and that this worst case can crop up very easily in some situations, especially if not too much care has been taken implementing it. The na

Re: hash and __eq__

On Sun, 31 May 2009 12:08:33 +0100, Arnaud Delobelle wrote: > Anyway, it's good to know that quicksort is O(n^2) in the worst case - > and that this worst case can crop up very easily in some situations, > especially if not too much care has been taken implementing it. The naive quicksort algorit

Re: hash and __eq__

Arnaud Delobelle wrote: Steven D'Aprano writes: On Sun, 31 May 2009 07:24:09 +0100, Arnaud Delobelle wrote: AFAIK, 'complexity' means 'worst case complexity' unless otherwise stated. No, it means "average or typical case" unless otherwise specified. I think you both are standing on opposi

Re: hash and __eq__

Steven D'Aprano writes: > On Sun, 31 May 2009 07:24:09 +0100, Arnaud Delobelle wrote: > >> AFAIK, 'complexity' means 'worst case complexity' unless otherwise >> stated. > > No, it means "average or typical case" unless otherwise specified. > Consult almost any comp sci text book and you'll see h

Re: hash and __eq__

On Sun, 31 May 2009 07:24:09 +0100, Arnaud Delobelle wrote: > AFAIK, 'complexity' means 'worst case complexity' unless otherwise > stated. No, it means "average or typical case" unless otherwise specified. Consult almost any comp sci text book and you'll see hash tables with chaining (like Pyth

Re: hash and __eq__

Piet van Oostrum writes: >> Arnaud Delobelle (AD) wrote: > >>AD> Piet van Oostrum writes: > Aaron Brady (AB) wrote: >>AB> I am writing a mapping object, and I want to ask about the details of >>AB> __hash__ and __eq__. IIUC if I understand correctly, the Python >>AB> dict's

Re: hash and __eq__

> Arnaud Delobelle (AD) wrote: >AD> Piet van Oostrum writes: Aaron Brady (AB) wrote: >>> >AB> I am writing a mapping object, and I want to ask about the details of >AB> __hash__ and __eq__. IIUC if I understand correctly, the Python >AB> dict's keys' hash codes are looked up firs

Re: hash and __eq__

On 2009-05-30 17:29, Terry Reedy wrote: Aaron Brady wrote: I am writing a mapping object, and I want to ask about the details of __hash__ and __eq__. IIUC if I understand correctly, the Python dict's keys' hash codes are looked up first in O( 1 ), then all the matching hash entries are compared

Re: hash and __eq__

Aaron Brady wrote: I am writing a mapping object, and I want to ask about the details of __hash__ and __eq__. IIUC if I understand correctly, the Python dict's keys' hash codes are looked up first in O( 1 ), then all the matching hash entries are compared on equality in O( n ). That is, the has

Re: hash and __eq__

Piet van Oostrum writes: >> Aaron Brady (AB) wrote: > >>AB> I am writing a mapping object, and I want to ask about the details of >>AB> __hash__ and __eq__. IIUC if I understand correctly, the Python >>AB> dict's keys' hash codes are looked up first in O( 1 ), then all the >>AB> matching ha

Re: hash and __eq__

> Aaron Brady (AB) wrote: >AB> I am writing a mapping object, and I want to ask about the details of >AB> __hash__ and __eq__. IIUC if I understand correctly, the Python >AB> dict's keys' hash codes are looked up first in O( 1 ), then all the >AB> matching hash entries are compared on equali

Re: hash and __eq__

On May 30, 12:11 pm, Dennis Lee Bieber wrote: > On Sat, 30 May 2009 11:20:47 -0700 (PDT), Aaron Brady > declaimed the following in > gmane.comp.python.general: > > > P.S.  I always feel like my posts should start like, "A mapping object > > am writing I."  Not too many verbs you can do that with

Re: Hash of None varies per-machine

On 03 Apr 2009 10:57:05 -0700, Paul Rubin wrote: > ben.tay...@email.com writes: >> 1. Is it correct that if you hash two things that are not equal they >> might give you the same hash value? > > Yes, hashes are 32 bit numbers and there are far more than 2**32 > possible Python values (think of lon

Re: Hash of None varies per-machine

"Steven D'Aprano" wrote: >Seems to me you have misunderstood the way pickling works. Yeah right - have you ever looked at the pickle code? Good to hear it "just works" :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list

Re: Hash of None varies per-machine

On Sat, 04 Apr 2009 13:09:06 +0200, Hendrik van Rooyen wrote: >>Any object can be hashed if it has a working __hash__ method. There's no >>reason not to have None hashable -- it costs nothing and allows you to >>use None as a dict key. > > So what happens if I try to pickle the dict and keep it f

Re: Hash of None varies per-machine

"Steven D'Aprano" wrote: On Fri, 03 Apr 2009 10:50:08 -0700, ben.taylor wrote: >> 2. Should the hash of None vary per-machine? I can't think why you'd >> write code that would rely on the value of the hash of None, but you >> might I guess. > >The value of hash(None) appears to be the value of i

Re: Hash of None varies per-machine

Steven D'Aprano wrote: > You can hash numbers no matter how big they are. > >>> hash(float('inf')) > 314159 Cute. And hash(float('-inf')) is -271828... -- Thomas Bellman, Lysator Computer Club, Linköping University, Sweden "God is real, but Jesus is an integer." ! bellman @ lysa

Re: Hash of None varies per-machine

On Fri, 03 Apr 2009 10:50:08 -0700, ben.taylor wrote: > 1. Is it correct that if you hash two things that are not equal they > might give you the same hash value? Absolutely. From help(hash): hash(...) hash(object) -> integer Return a hash value for the object. Two objects with the sa

Re: Hash of None varies per-machine

Paul Rubin wrote: > Yes, hashes are 32 bit numbers and there are far more than 2**32 > possible Python values (think of long ints), so obviously there must > be multiple values that hash to the same slot. No, hashs are C longs. On most 64bit platforms a C long has 64bits. As far as I know only 64b

Re: Hash of None varies per-machine

ben.tay...@email.com wrote: Found this while trying to do something unrelated and was curious... If you hash an integer (eg. hash(3)) you get the same integer out. If you hash a string you also get an integer. If you hash None you get an integer again, but the integer you get varies depending on

Re: Hash of None varies per-machine

Paul Rubin writes: > > ben.tay...@email.com writes: > > 1. Is it correct that if you hash two things that are not equal they > > might give you the same hash value? > > Yes, hashes are 32 bit numbers and there are far more than 2**32 > possible Python values (think o

Re: Hash of None varies per-machine

ben.tay...@email.com writes: > 1. Is it correct that if you hash two things that are not equal they > might give you the same hash value? Yes, hashes are 32 bit numbers and there are far more than 2**32 possible Python values (think of long ints), so obviously there must be multiple values that ha

Re: HASH TABLES IN PYTHON

Blubaugh, David A. wrote: > I was wondering if anyone has ever worked with hash tables within the > Python Programming language? I will need to utilize this ability for > quick numerical calculations. Dictionaries are, by definition, hash tables with a very optimized algorithm to minimize colli

Re: HASH TABLES IN PYTHON

On 14 mai, 18:23, "Eduardo O. Padoan" <[EMAIL PROTECTED]> wrote: > On Wed, May 14, 2008 at 12:20 PM, Blubaugh, David A. > > <[EMAIL PROTECTED]> wrote: > > To Whom It May Concern, > > > I was wondering if anyone has ever worked with hash tables within the Python > > Programming language? I wonder i

Re: HASH TABLES IN PYTHON

On Wed, May 14, 2008 at 12:20 PM, Blubaugh, David A. <[EMAIL PROTECTED]> wrote: > To Whom It May Concern, > > I was wondering if anyone has ever worked with hash tables within the Python > Programming language? I will need to utilize this ability for quick > numerical calculations. http://docs.py

Re: hash() yields different results for different platforms

> "Kerry, Richard" <[EMAIL PROTECTED]> (KR) wrote: >KR> The hash is not expected to be unique, it just provides a starting point >KR> for another search (usually linear ?). >KR> See http://en.wikipedia.org/wiki/Hash_function That only contains a definition of a hash function. I know what a

Re: hash() yields different results for different platforms

On 2006-07-12, Qiangning Hong <[EMAIL PROTECTED]> wrote: > Grant Edwards wrote: >> On 2006-07-11, Qiangning Hong <[EMAIL PROTECTED]> wrote: >> > However, when I come to Python's builtin hash() function, I >> > found it produces different values in my two computers! In a >> > pentium4, hash('a') ->

Re: hash() yields different results for different platforms

On 2006-07-12, Carl Banks <[EMAIL PROTECTED]> wrote: > Grant Edwards wrote: >> On 2006-07-11, Qiangning Hong <[EMAIL PROTECTED]> wrote: >> >> > I'm writing a spider. I have millions of urls in a table (mysql) to >> > check if a url has already been fetched. To check fast, I am >> > considering to a

Re: hash() yields different results for different platforms

"Kerry, Richard" <[EMAIL PROTECTED]> writes: > The hash is not expected to be unique, it just provides a starting point > for another search (usually linear ?). The database is good at organizing indexes and searching in them. Why not let the database do what it's good at. -- http://mail.pytho

RE: hash() yields different results for different platforms

Oostrum Sent: 12 July 2006 10:56 To: python-list@python.org Subject: Re: hash() yields different results for different platforms >>>>> Grant Edwards <[EMAIL PROTECTED]> (GE) wrote: >GE> The low 32 bits match, so perhaps you should just use that >GE> portion of

Re: hash() yields different results for different platforms

> Grant Edwards <[EMAIL PROTECTED]> (GE) wrote: >GE> The low 32 bits match, so perhaps you should just use that >GE> portion of the returned hash? If the hashed should be unique, 32 bits is much too low if you have millions of entries. -- Piet van Oostrum <[EMAIL PROTECTED]> URL: http://www.

Re: hash() yields different results for different platforms

Using Python's hash as column in the table might not be a good idea. You just found out why. So you could instead just use the base url and create an index based on that so next time just quickly get all urls from same base address then do a linear search for a specific one, or even easier, impleme

Re: hash() yields different results for different platforms

Qiangning Hong wrote: > /.../ add a "hash" column in the table, make it a unique key at this point, you should have slapped yourself on the forehead, and gone back to the drawing board. -- http://mail.python.org/mailman/listinfo/python-list

Re: hash() yields different results for different platforms

[Grant Edwards] >> ... >> The low 32 bits match, so perhaps you should just use that >> portion of the returned hash? >> >> >>> hex(12416037344) >> '0x2E40DB1E0L' >> >>> hex(-468864544 & 0x) >> '0xE40DB1E0L' >> >> >>> hex(12416037344 & 0x) >> '0xE40DB1E0L' >> >>> hex

Re: hash() yields different results for different platforms

Grant Edwards wrote: > On 2006-07-11, Qiangning Hong <[EMAIL PROTECTED]> wrote: > > However, when I come to Python's builtin hash() function, I > > found it produces different values in my two computers! In a > > pentium4, hash('a') -> -468864544; in a amd64, hash('a') -> > > 12416037344. Does ha

Re: hash() yields different results for different platforms

Grant Edwards wrote: > On 2006-07-11, Qiangning Hong <[EMAIL PROTECTED]> wrote: > > > I'm writing a spider. I have millions of urls in a table (mysql) to > > check if a url has already been fetched. To check fast, I am > > considering to add a "hash" column in the table, make it a unique key, > > a

Re: hash() yields different results for different platforms

On 2006-07-11, Qiangning Hong <[EMAIL PROTECTED]> wrote: > I'm writing a spider. I have millions of urls in a table (mysql) to > check if a url has already been fetched. To check fast, I am > considering to add a "hash" column in the table, make it a unique key, > and use the following sql stateme

Re: hash() yields different results for different platforms

"Qiangning Hong" <[EMAIL PROTECTED]> writes: > However, when I come to Python's builtin hash() function, I found it > produces different values in my two computers! In a pentium4, > hash('a') -> -468864544; in a amd64, hash('a') -> 12416037344. Does > hash function depend on machine's word length

Re: hash of hashes

Thanks to all for the feedback. it worked. --RR Tim Chase wrote: > > how do i create a hash of hash similar to perl using dict in python > > $x{$y}{z}=$z > > Pretty much the same as in perl, only minus half the crazy abuses > of the ASCII character-set. > > Okay...well, not quite half the abuses

Re: hash of hashes

> how do i create a hash of hash similar to perl using dict in python > $x{$y}{z}=$z Pretty much the same as in perl, only minus half the crazy abuses of the ASCII character-set. Okay...well, not quite half the abuses in this case... >>> x = {} >>> y = 42 >>> z = 'foonting turlingdromes' >>

Re: hash of hashes

In <[EMAIL PROTECTED]>, sfo wrote: > how do i create a hash of hash similar to perl using dict in python > $x{$y}{z}=$z Just put dictionaries as values into a dictionary. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list

Re: hash of hashes

sfo wrote: > how do i create a hash of hash similar to perl using dict in python > $x{$y}{z}=$z Haven't done any Perl in a long while (thankfully ;-) ) so I'm not quite sure on your syntax there, but here's how to do it in Python: >>> x = {'y': {'z': 'My value'}} >>> x['y']['z'] 'My value' Much

Re: hash()

On Tue, 06 Dec 2005 15:44:07 +, John Marshall wrote: > The goal is to be able to keep some meta-data > for each file/directory of a directory hierarchy > in a separate directory: one meta-data file per > file/directory. So you are planning on shadowing the entire file system with a single ma

Re: hash()

Tim Peters wrote: > [John Marshall] > Second, what are your assumptions about (a) the universe of strings; > and, (b) the hash function? My assumptions are: (a) valid and "reasonable" pathnames (e.g., 1024 characters long) (b) just the builtin hash(). The goal is to be able to keep some met

Re: hash()

Aahz wrote: > QOTW: Timbot makes an error ;-) Now exactly who was in charge of the replacement capacitors? --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list

Re: hash()

In article <[EMAIL PROTECTED]>, Tim Peters <[EMAIL PROTECTED]> wrote: > >First, if `st` is a string, `st[::-1]` is a list. Do you really mean >to compare string hashes with list hashes here? I'm going to assume >not. QOTW: Timbot makes an error ;-) -- Aahz ([EMAIL PROTECTED]) <*>

Re: hash()

Tim Peters wrote: > First, if `st` is a string, `st[::-1]` is a list. I hate to question the great timbot, but am I missing something? >>> 'abcde'[::-1] 'edcba' STeVe -- http://mail.python.org/mailman/listinfo/python-list

Re: hash()

[John Marshall] >>> For strings of > 1 character, what are the chances >>> that hash(st) and hash(st[::-1]) would return the >>> same value? [Tim Peters] >> First, if `st` is a string, `st[::-1]` is a list. Do you really mean >> to compare string hashes with list hashes here? I'm going to assume

Re: hash()

> [John Marshall] > > For strings of > 1 character, what are the chances > > that hash(st) and hash(st[::-1]) would return the > > same value? > On Mon, Dec 05, 2005 at 09:11:14PM -0500, Tim Peters wrote: > First, if `st` is a string, `st[::-1]` is a list. Do you really mean > to compare string h

Re: hash()

[John Marshall] > For strings of > 1 character, what are the chances > that hash(st) and hash(st[::-1]) would return the > same value? First, if `st` is a string, `st[::-1]` is a list. Do you really mean to compare string hashes with list hashes here? I'm going to assume not. Second, what are y

Re: hash()

[John Marshall] > For strings of > 1 character, what are the chances > that hash(st) and hash(st[::-1]) would return the > same value? Python's string hash algorithm is non-commutative, so a collision with a reversed string is not likely. The exact answer depends on the population of strings bein

Re: hash()

John Marshall wrote: > For strings of > 1 character, what are the chances > that hash(st) and hash(st[::-1]) would return the > same value? the algorithm is described here: http://effbot.org/zone/python-hash.htm feel free to do a mathematical analysis. a non-mathematical analysis says that

Re: hash()

John Marshall wrote: > Scott David Daniels wrote: >> ... Why not grab a dictionary and do the stats yourself? > I was actually interested in the mathematical/probability > side rather than the empirical w/r to the current > hash function in python. Well, the probability depends on the universe you

Re: hash()

John Marshall wrote: > I was actually interested in the mathematical/probability > side rather than the empirical w/r to the current > hash function in python. Although I imagine I could do > a brute force test for x-character strings. Hah. No. At least on the version I have handy (Py 2.2.3 on

Re: hash()

Scott David Daniels wrote: > John Marshall wrote: > >>For strings of > 1 character, what are the chances >>that hash(st) and hash(st[::-1]) would return the >>same value? > > > Why not grab a dictionary and do the stats yourself? I was actually interested in the mathematical/probability side ra

Re: hash()

John Marshall wrote: > For strings of > 1 character, what are the chances > that hash(st) and hash(st[::-1]) would return the > same value? Why not grab a dictionary and do the stats yourself? --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list

Re: Hash map with multiple keys per value ?

On Fri, 11 Nov 2005 22:55:53 +, Chris Stiles <[EMAIL PROTECTED]> wrote: >Hi -- > >I'm working on something that includes the concept of multiple aliases for a >particular object, where a lookup for any of the aliases has to return all the >others. The hack way of doing this was to have a dict

  1   2   >