> Maybe it makes more sense to deprecate .pyo altogether and instead > have a post-load optimizer optimize .pyc files according to the > current optimization settings? That would not be enough, because it would leave the docstrings in the .pyc files. > Unless others are interested in this nothing will happen. The status quo is good enough, for "normal" imports. If zipimport works differently, well, that's not nice. > I've never heard of a third party making their code available only as > .pyo, *cough* Ahem, here we are (the firm I work for). > so the use case for changing things isn't very strong. In fact > the only use cases I know for not making .py available are in > situations where a proprietary "canned" application is distributed to > end users who have no intention or need to ever add to the code. Well, exactly. :-) -- Nicola Larosa - nico at tekNico.net No inventions have really significantly eased the cognitive difficulty of writing scalable concurrent applications and it is unlikely that any will in the near term. [...] Most of all, threads do not help, in fact, they make the problem worse in many cases. -- G. Lefkowitz, August 2005
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