Mailman 3 November 1999 - Python-Dev

dircache.py
by Gordon McMillan 01 Nov '99

01 Nov '99

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

2 1

Re: [Python-Dev] Benevolent dictator versus the bureaucratic committee?
by Jack Jansen 01 Nov '99

01 Nov '99

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

1 0

Re: [Python-Dev] Embedding Python when using different calling conventions.
by Jack Jansen 01 Nov '99

01 Nov '99

> 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

1 0