Roy Smith wrote: > In article <511b2a7c$0$11096$c3e8...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
