Comment 10 for bug 1655619

Well, I assume it is not new, I guess it just wasn't visible before as we simpy shipped and installed pre-compiled .pyc files.

I'm afraid I was too accurate when lately updating devlibs64, but also CMake and the installer scripts: In all these steps I started to exclude files unnecessary for the final distribution - also .pyc files.

Now I'm still of the opinion that we should *not* ship .pyc files as those are cache files of the compiled Python bytecode (i.e. they are generated from the corresponding .py file). They can be easily generated after installation and in fact they are (at least inprinciple) system dependent. As we ship Python with our Windows distributions we can assume that most people will probably use the same version of Python, but if this was not the case or if a user decided to update an extensions the bytecode file would have to be re-created.

I had previously hoped that those files would simply be put into Windows's "Virtual Store" folder, but it seems that is somehow not the case and Python fails instead (I have not yet determined which step actually fails as some extensions work fine while others obviously won't).

Right now I see three possible solutions:
* Drop the idea of stripping .pyc files from the installer packages and hope for the best (i.e. that most people will never try to update extensions)
* Tell Python not to create/use .pyc files at all. There are even three different possibilities for this: The "PYTHONDONTWRITEBYTECODE" environment variable, the "-B" command line switch and also "sys.dont_write_bytecode=True" directly from python scripts.
* Try to figure out the actual issue, and fix it (or get it fixed by Python devs, depending on where the issue is).

While the third options is obviously the hardest it would also be the cleanest and (for me) preferred option.