[Grok-dev] martian scan "bug" (feature?)

Chris McDonough chrism at plope.com
Thu Nov 20 11:21:12 EST 2008

Lennart Regebro wrote:
> On Thu, Nov 20, 2008 at 15:58, Chris McDonough <chrism at plope.com> wrote:
>> Lennart Regebro wrote:
>>> Well. this is how python works. You can even distribute only pyc
>>> files, if you want.
>> Yup, but it's not the usual case.
> Well, that's true, but still, if you don't remove the pyc file, python
> will still thing the module is there. It is how python behaves, and
> I'm not at all sure it's a good idea to fight the language. :)

Martian is importing files that are no longer in use; I don't want it to.  This
happens when you do, e.g. a .py module rename or svn up after someone else does.
 It happens all the time.  As Brandon mentioned, zope.testing has special
support for this case too.

If I had explicitly imported the module that only had a pyc representation from
another .py module in my project that martian found, or if I had configured
martian to use "ignore_nonsource=True", and I expected it to not find the
module, then *that* would definitely be fighting the language.  But being able
to configure it to not find pycs without a py source is not fighting the
language, it's just expressing policy.

Note that I'm not changing *Grok*.  I'm changing Martian.  If Grok itself wanted
to continue to find pyc files without a py repr (which IMO would be a bad
default), it would just use "martian.grok_dotted_name(.., ignore_nonsource=False)".

>> The difference here is that Martian imports everything it finds, whereas in
>> normal operations a "stray" pyc might exist but would never be imported or
>> otherwise used.
> True, it's a more significant issue with grok, and would be encoutered
> more often.

Yes, and with anything else that uses martian.

- C

More information about the Grok-dev mailing list