Skip to content

sys.cmd_flags patch #46141

New issue
New issue
Closed
Closed
sys.cmd_flags patch#46141
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)

Description

@tiran
tiran
opened on Jan 12, 2008
BPO 1816
Nosy @gvanrossum, @brettcannon, @birkenfeld, @tiran, @merwok
Files
  • trunk_sys_cmd_flags.patch
  • trunk_sys_flags.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2008-01-14.04:41:41.135>
created_at = <Date 2008-01-12.21:35:54.141>
labels = ['interpreter-core']
title = 'sys.cmd_flags patch'
updated_at = <Date 2010-12-31.01:32:47.116>
user = 'https://github.com/tiran'

    bugs.python.org fields:

    activity = <Date 2010-12-31.01:32:47.116>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2008-01-14.04:41:41.135>
closer = 'christian.heimes'
components = ['Interpreter Core']
creation = <Date 2008-01-12.21:35:54.141>
creator = 'christian.heimes'
dependencies = []
files = ['9143', '9149']
hgrepos = []
issue_num = 1816
keywords = ['patch']
message_count = 14.0
messages = ['59840', '59845', '59851', '59859', '59861', '59862', '59863', '59864', '59869', '59887', '59889', '124925', '124935', '124945']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'brett.cannon', 'georg.brandl', 'christian.heimes', 'eric.araujo']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1816'
versions = ['Python 2.6']

    Activity

    1. tiran commented on Jan 12, 2008

      @tiran
      tiran
      on Jan 12, 2008
      MemberAuthor

      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.

    2. tiran
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      on Jan 12, 2008

    3. gvanrossum commented on Jan 12, 2008

      @gvanrossum
      gvanrossum
      on Jan 12, 2008
      Member

      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.

    4. tiran commented on Jan 13, 2008

      @tiran
      tiran
      on Jan 13, 2008
      MemberAuthor

      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.

    5. gvanrossum commented on Jan 13, 2008

      @gvanrossum
      gvanrossum
      on Jan 13, 2008
      Member

      Can't you use a namedtuple? Then printing it would show the names of
      the flags...

    6. tiran commented on Jan 13, 2008

      @tiran
      tiran
      on Jan 13, 2008
      MemberAuthor

      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.

    7. gvanrossum commented on Jan 13, 2008

      @gvanrossum
      gvanrossum
      on Jan 13, 2008
      Member

      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.

    8. brettcannon commented on Jan 13, 2008

      @brettcannon
      brettcannon
      on Jan 13, 2008
      Member

      On Jan 13, 2008 9:45 AM, Christian Heimes <[email protected]> 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.

    9. tiran commented on Jan 13, 2008

      @tiran
      tiran
      on Jan 13, 2008
      MemberAuthor

      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.

    10. tiran commented on Jan 13, 2008

      @tiran
      tiran
      on Jan 13, 2008
      MemberAuthor

      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;
}

    11. gvanrossum commented on Jan 14, 2008

      @gvanrossum
      gvanrossum
      on Jan 14, 2008
      Member

      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. :-)

    12. tiran commented on Jan 14, 2008

      @tiran
      tiran
      on Jan 14, 2008
      MemberAuthor

      Committed in r59947, r59948 and r59949

    13. tiran
      closed this as completedon Jan 14, 2008

    14. merwok commented on Dec 30, 2010

      @merwok
      merwok
      on Dec 30, 2010
      Member

      I’ve recently remarked that -i maps to both sys.flags.inspect and sys.flags.interactive. Is this behavior useful?

    15. birkenfeld commented on Dec 30, 2010

      @birkenfeld
      birkenfeld
      on Dec 30, 2010
      Member

      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).

    16. merwok commented on Dec 31, 2010

      @merwok
      merwok
      on Dec 31, 2010
      Member

      Okay, so having both flags makes sense.

    17. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      interpreter-core(Objects, Python, Grammar, and Parser dirs)

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions