Tim Peters wrote:
[M.-A. Lemburg]
The reason is that I don't want to break the -U scheme.
But -U doesn't work anyway:
(-U changes the semantics of the language in a pretty nasty way ... nothing works anymore ;-).
The only things -U have bought us are a bizarre definition of "magic number", code complication, and complaints from people who see -U in the "python -h" blurb and want to know why everything breaks when they try it. It may be a hack you want to use for internal testing, but stuff that's been broken since the day it was introduced, and makes no progress towards working, doesn't belong in the general release.
Wait... the -U option was added in order to be able to see how well the 8-bit string / Unicode integration works. It's a know fact that the Python standard lib is not Unicode compatible yet and that's exactly what the -U option allows you to test (in a very simple way).
In the long run, Python's std lib should move into the direction of being Unicode compatible, so I don't really see the need for removing -U altogether. To reduce the noise about Python failing to run with the option set, it may be a good idea to remove the mentioning from the -h blurb, though.
I know it's a hack, but until someone comes up with a better way to add flags to store PYC compile options, we'll have to stick with it.
But there is no need to store info about PYC compile options: -U is its only use now, and -U has never worked. Since it's worse than useless, better to throw it out, then dream up a rational way to store PYC compile options if and when (and only if and when) there's an actual need for such.
The -U option is currently the only application of such a flag. We will definitely have a need for these options in the future to make the runtime aware of certain assumptions which have been made in the compiled byte code, e.g. byte code using special opcodes, byte code compiled for a different Python virtual machine (once we get pluggable Python compiler / VM combos), byte code which was compiled using special literal interpretations (such as in the -U case or when compiling the source code with a different source code encoding assumption).
I would be more than happy to get rid off the current PYC magic hack for -U and have it replaced with a better and extensible alternative, e.g. a combination of PYC version number and marhsalled option dictionary.