Hi,
I am reposting this message from python-dev.
Could someone please test the code below
to verify that there is indeed a problem
with eval() under python 2.3.5. I have
rebuilt python 2.3.5 under the latest debian
and under RH 7.3 (in case the problem is
in system libraries).
The following code
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 b
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
Hi,
For strings of > 1 character, what are the chances
that hash(st) and hash(st[::-1]) would return the
same value?
My goal is to uniquely identify multicharacter strings,
all of which begin with "/" and never end with "/".
Therefore, st != st[::-1].
Thanks,
John
--
http://mail.python.org/mail
On Thu, 2004-12-09 at 10:33 -0500, Peter Hansen wrote:
> John Marshall wrote:
> > It seems to me that a file.__del__() _should_
> > call a file.close() to make sure that the file
> > is closed as a clean up procedure before
> > releasing the object.
>
> I
On Thu, 2004-12-09 at 08:41 -0500, Peter Hansen wrote:
> John Marshall wrote:
> > Hi,
> >
> > Does anyone see a problem with doing:
> > data = file("tata").read()
> >
> > Each time this is done, I see a new file
> > descriptor allocat
Hi,
Does anyone see a problem with doing:
data = file("tata").read()
Each time this is done, I see a new file
descriptor allocated (Linux) but not
released.
1) Will there ever be a point where I
will have a problem with file
descriptors because the garbage
collector has _not_ yet co
