classification
Title: sys.cmd_flags patch
Type: Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, christian.heimes, eric.araujo, georg.brandl, gvanrossum
Priority: normal Keywords: patch

Created on 2008-01-12 21:35 by christian.heimes, last changed 2010-12-31 01:32 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
trunk_sys_cmd_flags.patch christian.heimes, 2008-01-12 21:35
trunk_sys_flags.patch christian.heimes, 2008-01-13 09:14
Messages (14)
msg59840 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-12 21:35
The output should be self explaining:
./python -tt -E -OO -Qnew -c "import sys; print sys.cmd_flags"
('Qnew', 'O', 'OO', 'E', 't', 'tt')

I'll provide doc updates and a mini test if the patch wanted.
msg59845 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-12 23:33
I like the idea of exposing Python's command line flags, but I think
this API is a bit odd.  I'd rather see it be a struct with members named
after the various arguments and values that are ints or bools -- or
simply a bunch of new flags directly in the sys module if making it a
string is too much work.

It also looks like the patch includes a few unrelated changes to
install.py and site.py.
msg59851 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-13 09:14
The new patch is using a struct sequence (like the result of os.stat):

>>> import sys
>>> sys.flags
<sys.flags (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)>
>>> dir(sys.flags)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
'__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__rmul__', '__setattr__', '__str__', 'debug',
'division_new', 'division_warning', 'dont_write_bytecode',
'ingnore_environment', 'inspect', 'interactive', 'n_fields',
'n_sequence_fields', 'n_unnamed_fields', 'no_site', 'optimize',
'py3k_warning', 'tabcheck', 'unicode', 'verbose']
>>> sys.flags.debug
0

Please ignore the other files. They are part of my second PEP.
msg59859 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-13 17:35
Can't you use a namedtuple?  Then printing it would show the names of
the flags...
msg59861 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-13 17:45
Guido van Rossum wrote:
> Can't you use a namedtuple?  Then printing it would show the names of
> the flags...

... and increase the startup costs of Python by loading several
additional modules. The collections module imports _collections,
operator and keyword. I'd rather see a better repr function for the
sequence types.
msg59862 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-13 18:29
> I'd rather see a better repr function for the
> sequence types.

Agreed.  It's kind of unfortunate that we have two implementations for
the same concept, one in C and one in Python.
msg59863 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-01-13 20:19
On Jan 13, 2008 9:45 AM, Christian Heimes <report@bugs.python.org> wrote:
>
> Christian Heimes added the comment:
>
> Guido van Rossum wrote:
> > Can't you use a namedtuple?  Then printing it would show the names of
> > the flags...
>
> ... and increase the startup costs of Python by loading several
> additional modules. The collections module imports _collections,
> operator and keyword. I'd rather see a better repr function for the
> sequence types.

Can we make it a function so that it is lazy? That way you can still
use namedtuple but it is only imported when the function is called
instead of during sys' initialization.
msg59864 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-13 20:37
I've coded sys.flags for my per-user site-packages PEP. I could make it
a function but the function would be called by site.py on every startup.
msg59869 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-13 22:41
Does anybody see a problem with this repr slot implementation for
structseq? It gives this output:

>>> os.stat(".")
<posix.stat_result st_mode=16832, st_ino=11666571L, st_dev=65025L,
st_nlink=20, st_uid=1000, st_gid=1000, st_size=4096L,
st_atime=1200261754, st_mtime=1200261721, st_ctime=1200261721>

static PyObject *
structseq_repr(PyStructSequence *obj)
{
	PyObject *tup, *val, *repr;
	PyTypeObject *typ = Py_TYPE(obj);
	int i, len;
	char buf[250+5]; /* "...>\0" */
	char *cname, *crepr;
	char *pbuf = buf;
 	char *endbuf = &buf[250];

	*pbuf++ = '<';
	strncpy(pbuf, typ->tp_name, 50);
	pbuf += strlen(typ->tp_name) > 50 ? 50 : strlen(typ->tp_name);
	*pbuf++ = ' ';

	if ((tup = make_tuple(obj)) == NULL) {
		return NULL;
	}
	for (i=0; i < VISIBLE_SIZE(obj); i++) {
		cname = typ->tp_members[i].name;
		val = PyTuple_GetItem(tup, i);
		if (cname == NULL || val == NULL) {
			return NULL;
		}
		repr = PyObject_Repr(val);
		if (repr == NULL) {
			Py_DECREF(tup);
			return NULL;
		}
		crepr = PyString_AsString(repr);
		if (crepr == NULL) {
			Py_DECREF(tup);
			Py_DECREF(repr);
			return NULL;
		}
		len = strlen(cname) + strlen(crepr) + 3;
		if ((pbuf+len) < endbuf) {
			strcpy(pbuf, cname);
			pbuf += strlen(cname);
			*pbuf++ = '=';
			strcpy(pbuf, crepr);
			pbuf += strlen(crepr);
			*pbuf++ = ',';
			*pbuf++ = ' ';
			Py_DECREF(repr);
		}
		else {
			strcpy(pbuf, "...");
			pbuf += 5;
			Py_DECREF(repr);
			break;
		}
	}
	Py_DECREF(tup);

	pbuf-=2;
	*pbuf++ = '>';
	*pbuf = '\0';

	repr = PyString_FromString(buf);
	return repr;
}
msg59887 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-01-14 03:15
Nice -- perhaps you can make it look like a function call,
posix.stat_result(st_mode=..., ...)?  (Then someone else might finally
create a constructor with such a signature. :-)
msg59889 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-14 04:41
Committed in r59947, r59948 and r59949
msg124925 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-30 18:11
I’ve recently remarked that -i maps to both sys.flags.inspect and sys.flags.interactive.  Is this behavior useful?
msg124935 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-12-30 20:58
Maybe not, but note that there is both a Py_InteractiveFlag and Py_InspectFlag, and they enable different things (they are both set by -i, while setting the PYTHONINSPECT envvar only activates Py_InspectFlag).
msg124945 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-31 01:32
Okay, so having both flags makes sense.
History
Date User Action Args
2010-12-31 01:32:47eric.araujosetnosy: gvanrossum, brett.cannon, georg.brandl, christian.heimes, eric.araujo
messages: + msg124945
2010-12-30 20:58:19georg.brandlsetnosy: + georg.brandl
messages: + msg124935
2010-12-30 18:11:53eric.araujosetnosy: + eric.araujo
messages: + msg124925
2008-01-14 04:41:41christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg59889
2008-01-14 03:15:48gvanrossumsetmessages: + msg59887
2008-01-13 22:41:20christian.heimessetmessages: + msg59869
2008-01-13 20:37:55christian.heimessetmessages: + msg59864
2008-01-13 20:19:13brett.cannonsetnosy: + brett.cannon
messages: + msg59863
2008-01-13 18:29:21gvanrossumsetmessages: + msg59862
2008-01-13 17:45:10christian.heimessetmessages: + msg59861
2008-01-13 17:35:24gvanrossumsetmessages: + msg59859
2008-01-13 09:14:54christian.heimessetfiles: + trunk_sys_flags.patch
messages: + msg59851
2008-01-12 23:33:04gvanrossumsetnosy: + gvanrossum
messages: + msg59845
2008-01-12 21:35:54christian.heimescreate