> 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 - [EMAIL PROTECTED] 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
