Pursuant to my volunteering to implement Guido's plan to
combine cmp.py, cmpcache.py, dircmp.py and dircache.py
into filecmp.py, I did some investigating of dircache.py.
I find it completely unreliable. On my NT box, the mtime of the
directory is updated (on average) 2 secs after a file is added,
but within 10 tries, there's always one in which it takes more
than 100 secs (and my test script quits). My Linux box hardly
ever detects a change within 100 secs.
I've tried a number of ways of testing this ("this" being
checking for a change in the mtime of the directory), the latest
of which is below. Even if dircache can be made to work
reliably and surprise-free on some platforms, I doubt it can be
done cross-platform. So I'd recommend that it just get dropped.
Comments?
---------------------------------------------------
import os
import sys
import time
d = os.getcwd()
atimes = []
def test():
m = os.stat(d)[8]
for i in range(10):
fnm = 's%d.tmp' % i
open(fnm,'w').write('dummy - delete me')
for j in range(10000):
newm = os.stat(d)[8]
if newm != m:
atimes.append(j*0.01)
m = newm
break
time.sleep(0.01)
else:
print "At round %d, failed to detect add within %3.2f
secs" % (i, j*0.01)
break
def report():
import operator
if atimes:
print "detect adds: min= %3.2f max= %3.2f avg=
%3.2f" % (min(atimes), max(atimes), reduce(operator.add,
atimes, 0.0)/len(atimes))
else:
print "no successfully detected adds"
test()
report()
- Gordon
I think I agree with Mark's post, although I do see a little more light (the
relative imports dicussion resulted in working code, for instance).
The benevolent lieutenant idea may work, _if_ the lieutenants can be found. I
myself will quickly join Mark in wishing the new python-dev well and
abandoning ship (half a :-).
If that doesn't work maybe we should try at the very least to create a
"memory". If you bring up a subject for discussion and you don't have working
code that's fine the first time. But if anyone brings it up a second time
they're supposed to have code. That way at least we won't be rehashing old
discussions (as happend on the python-list every time, with subjects like GC
or optimizations).
And maybe we should limit ourselves in our replies: don't speak up too much in
discussions if you're not going to write code. I know that I'm pretty good at
answering with my brilliant insights to everything myself:-). It could well be
that refining and refining the design (as in the getopt discussion) results in
such a mess of opinions that no-one has the guts to write the code anymore.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
> OTOH, we could take chance to reorganize these macros from bottom
> up: when I started coding extensions I found them not very useful
> mostly because I didn't have control over them meaning "export
> this symbol" or "import the symbol". Especially the DL_IMPORT
> macro is strange because it seems to handle both import *and*
> export depending on whether Python is compiled or not.
This would be very nice. The DL_IMPORT/DL_EXPORT stuff is really weird unless
you're working with it all the time. We were trying to build a plugin DLL for
PythonWin and first you spend hours finding out that you have to set DL_IMPORT
(and how to set it), and the you spend another few hours before you realize
that you can't simply copy the DL_IMPORT and DL_EXPORT from, say, timemodule.c
because timemodule.c is going to be in the Python core (and hence can use
DL_IMPORT for its init() routine declaration) while your module is going to be
a plugin so it can't.
I would opt for a scheme where the define shows where the symbols is expected
to live (DL_CORE and DL_THISMODULE would be needed at least, but probably one
or two more for .h files).
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
