Python Makefiles... are they possible?

[Steven D'Aprano]

Roy Smith wrote:

> In article <511b2a7c$0$11096$c3e8da3 at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> 
>> On Tue, 12 Feb 2013 20:06:35 -0500, Roy Smith wrote:
>> 
>> > One thing we do in our Makefiles is "find . -name '*.pyc' | xargs rm".
>> > It avoids all sorts of nasty and hard to track down bugs (consider what
>> > happens if you move a .py file from one place in your source tree to
>> > another and leave the old .pyc behind).
>> 
>> 
>> How often do you move files around in the source tree?
> 
> It has happened enough times to make us look for a solution.  Which
> means "more than once".

Maybe the solution is education, not a technical fix.

I've suspicious of technical fixes for developer problems, because in my
experience that strategy ends in a race to the bottom where you end up with
coding standards and procedures that assume everyone is a code monkey who
can barely spell PC. It doesn't protect the monkeys, because there is no
end to the ways they can screw up, while the competent developers suffer
under repressive, B&D procedures that hinder more than help.

YMMV.

I prefer to keep the .pyc files, and only remove them when necessary, rather
than to remove them whether it's necessary or not. It's not just because
I'm an arrogant SOB who expects my team of developers to know at least more
than me, therefore if I know enough to look for orphaned .pyc files so
should they. It's because I am a big believer that your development system
should be as close as possible to the eventual deployment system as is
practical. Your app will (probably) use .pyc files when it is deployed, so
you should do the same when developing. Otherwise you can get bugs in
deployment that you cannot reproduce in development because the
environments are different.


>> Meanwhile, *every* time you run make, you take a performance hit on
>> every Python module in your project, whether it has moved or not.
> 
> The performance hit is minimal.

I guess that depends on the size of your project and how much you care about
the start up time. But as general advice, no, it may not be minimal.

[...]


> Another solution would be if there was a flag you could give to Python
> to tell it, "Only import a .pyc if the corresponding .py file exists".
> It's already checking to see if the .py is newer, so this wouldn't even
> cost anything.

That's called "Python 3.3" :-)



-- 
Steven