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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4