Chris Withers wrote:
> M.-A. Lemburg wrote:
>> As I understand it, the only case that the PYC cleaner is trying
>> to work around here is a local configuration problem which only
>> occurs if some PY file was removed upstream.
> Nope, not at all...
> Quite often shows up early in the development cycle...
> 1. create myfoo.py
> 2. run unit tests
> 3. decide it really should have been mybar.py
I suppose you are doing 'mv myfoo.py mybar.py' here ...
> 4. delete myfoo.py
... then this should be 'rm myfoo.py*' to get rid off the
old PYC files.
> 5. run unit tests to make sure you've fixed all import statements
That's a weird way to check your code. You should really
do a grep on the sources to see whether any references
to the 'myfoo' module are still left.
Unit tests only make sure that you haven't screwed up some
functional part of the machinery. They don't help to verify
code quality or to find hidden imports, unless you have 100%
code coverage and are able to test all possible combinations
of execution paths, which is unlikely :-)
PyChecker and grep are much better for this kind of task.
> 6. happilly checkin
> 7. get errors on fresh checkout because unit tests were using mybar.pyc
I still have a feeling that your trying to work around developer
laziness here ;-)
That's not a bad thing in general, but if this causes unwanted
side-effects for other people, you should really think twice
before adding a change that saves you 10 minutes every now and
then while causing many others to spend 30 minutes or more
trying to figure out why their code doesn't work anymore after
a simple test run...
Professional Python Services directly from the Source (#1, Oct 19 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Zope-DB mailing list