It can be useful to enable or disable global Python features based on command-line flags. The -X is supposed to allow implementation-specific options but it is currently disabled for CPython. This patch allows to use -X for arbitrary options in CPython. These options are not validated but minimally parsed and fed into a dictionary, sys.xoptions. An example is better than a thousand words:

$ ./python -c "import sys; print(sys.xoptions)"
{}
$ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
{'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}


This could be useful for various debug enablers, such as Victor's SIGSEGV handler, warnings about unclosed files, etc.

See issue10093 for a possible use case.

Seems like a good idea to me.  Would other VMs have to implement sys.xoptions too?

> Seems like a good idea to me.  Would other VMs have to implement sys.xoptions too?

I don't think we should mandate that, no.

Why wouldn't they? A standard way to extend the command line options seems useful in all environments.
Now the interpretation of these options are subject to variations of course...

On Wed, Oct 13, 2010 at 07:01:40PM +0000, Antoine Pitrou wrote:
> $ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
> {'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}

Docs should be updated too. I see that the values could either be True
or a string? Would this be perceived as a limitation?

Well, the syntax allows to pass either a string value (because it's a substring of the command line), or nothing.

When no value is passed, True seems better than None, because this allows the usage of the get() method::
    x = sys.xoptions.get('a')
or::
    if sys.xoptions.get('a'):
this returns None if the option was not set, True if set to a empty value, and a non-empty string if set to an actual value.

I suggest using sys._xoptions to make it clearer that this is for CPython specific internal implementation runtime tweaks. We're putting it in sys so *we* can get at it, not applications.

(It also makes it clear that other implementations aren't obliged to implement *any* particular interface to the -X options. Requiring that would go against the whole spirit of -X)

> (It also makes it clear that other implementations aren't obliged to
> implement *any* particular interface to the -X options. Requiring that 
> would go against the whole spirit of -X)

Agreed. I'll update the patch to use sys._xoptions.

Here is a new patch renaming the attribute to sys._xoptions, and adding some docs.

I'd prefer "-X key[=val]" without the possibility to mention multiple key=val pairs, so that val can contain anything (commata in particular).

Otherwise, the change looks fine to me.

Here is a simpler version without comma-separated pairs.

Committed in r85772.