Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys.cmd_flags patch #46141

Closed
tiran opened this issue Jan 12, 2008 · 14 comments
Closed

sys.cmd_flags patch #46141

tiran opened this issue Jan 12, 2008 · 14 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@tiran
Copy link
Member

tiran commented 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']

    @tiran
    Copy link
    Member Author

    tiran commented Jan 12, 2008

    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.

    @tiran tiran added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jan 12, 2008
    @gvanrossum
    Copy link
    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.

    @tiran
    Copy link
    Member Author

    tiran commented Jan 13, 2008

    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.

    @gvanrossum
    Copy link
    Member

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

    @tiran
    Copy link
    Member Author

    tiran commented Jan 13, 2008

    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.

    @gvanrossum
    Copy link
    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.

    @brettcannon
    Copy link
    Member

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Jan 13, 2008

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Jan 13, 2008

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

    @gvanrossum
    Copy link
    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. :-)

    @tiran
    Copy link
    Member Author

    tiran commented Jan 14, 2008

    Committed in r59947, r59948 and r59949

    @tiran tiran closed this as completed Jan 14, 2008
    @merwok
    Copy link
    Member

    merwok commented Dec 30, 2010

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

    @birkenfeld
    Copy link
    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).

    @merwok
    Copy link
    Member

    merwok commented Dec 31, 2010

    Okay, so having both flags makes sense.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants