PEP 3147 - new .pyc format

[Steven D'Aprano]

On Mon, 01 Feb 2010 21:19:52 +0100, Daniel Fetchinson wrote:

>> Personally, I think it is a terribly idea to keep the source file and
>> byte code file in such radically different places. They should be kept
>> together. What you call "clutter" I call having the files that belong
>> together kept together.
> 
> I see why you think so, it's reasonable, however there is compelling
> argument, I think, for the opposite view: namely to keep things
> separate. An average developer definitely wants easy access to .py
> files. However I see no good reason for having access to .pyc files. I
> for one have never inspected a .pyc file. Why would you want to have a
> .pyc file at hand?

If you don't care about access to .pyc files, why do you care where they 
are? If they are in a subdirectory module.pyr, then shrug and ignore the 
subdirectory. 

If you (generic you) are one of those developers who don't care 
about .pyc files, then when you are browsing your source directory and 
see this:


module.py
module.pyc 

you just ignore the .pyc file. Or delete it, and Python will re-create it 
as needed. So if you see

module.pyr/

just ignore that as well.



> If we don't really want to have .pyc files in convenient locations
> because we (almost) never want to access them really, then I'd say it's
> a good idea to keep them totally separate and so make don't get in the
> way.

I like seeing them in the same place as the source file, because when I 
start developing a module, I often end up renaming it multiple times 
before it settles on a final name. When I rename or move it, I delete 
the .pyc file, and that ensures that if I miss changing an import, and 
try to import the old name, it will fail.

By hiding the .pyc file elsewhere, it is easy to miss deleting one, and 
then the import won't fail, it will succeed, but use the old, obsolete 
byte code.



-- 
Steven