[Python-Dev] __file__

[Ron Adam]

Barry Warsaw wrote:
> On Feb 26, 2010, at 02:09 PM, Brett Cannon wrote:
> 
>> But a benefit of no longer supporting bytecode-only modules by default is it
>> cuts back on possible stat calls which slows down Python's startup time (a
>> complaint I hear a lot). Performance issues become even more acute if you try
>> to come up with even a remotely proper way to have backwards-compatible
>> support in importlib for its ABCs w/o forcing caching on all implementors of
>> the ABCs.
> 
>> And personally, I don't see what bytecode-only modules buy you. The
>> obfuscation argument is bunk as we all know.
> 
> Brett really hits the nail on the head, and yes I'm sorry for not being clear
> about what "we discussed this at Pycon" meant.  The "we" being Brett and I of
> course (and Chris Withers IIRC).
> 
> Bytecode-only deployments are a bit of a sham, and definitely a minority use
> case, so why should all of Python pay for the extra stat calls to support this
> by default?  How many people would actually be hurt if this wasn't available
> out of the box, especially since you can still support it if you really want
> it and can't convince your manager that it provides essentially zero useful
> obfuscation of your code?
> 
> I say this having been down that road myself with a previous employer.
> Management was pretty adamant about wanting this until I explained how easy it
> was to defeat and convinced them that the engineering resources to do it were
> better spent elsewhere.
> 
> Having said that, I'd be all for including a reference implementation of a
> bytecode-only loader in the PEP for demonstration purposes.  Greg, would you
> like to contribute that?
> 
> -Barry


Micheal Foords view point on this strikes me as the most realistic. Some 
people do find it to be a value for their particular needs and circumstance.

Michael Foord Wrote:
> For many use-cases some protection is enough. After all *any* DRM or 
> source-code obfuscation is breakable in the medium / long term - so just
>  enough to discourage the casual looker is probably sufficient. The fact
>  that bytecode only distributions exist speaks to that.
> 
> Whether you believe that allowing companies who ship bytecode is a 
> disservice to them or not is fundamentally irrelevant. If they believe
> it is a service to them then it is... :-)


To possibly qualify it a bit more:

It does not make sense (to me) to have byte code only modules and packages 
in python's lib directory.  The whole purpose (as far as I know) is for 
modules and packages located there to be shared.  And as such, the source 
file becomes a source of documentation.  Not supporting bytecode only 
python modules and packages in pythons "lib" directory may be good.

For python programs located and installed elsewhere I think Michaels view 
point is applicable. For some files that are not meant to be shared, some 
form of discouragement can be a feature.

Ron Adam