[issue1816] sys.cmd_flags patch

Éric Araujo added the comment: Okay, so having both flags makes sense. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue1816] sys.cmd_flags patch

Georg Brandl added the comment: 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). -- nosy: +georg.brandl ___

[issue1816] sys.cmd_flags patch

Éric Araujo added the comment: I’ve recently remarked that -i maps to both sys.flags.inspect and sys.flags.interactive. Is this behavior useful? -- nosy: +eric.araujo ___ Python tracker __

[issue1816] sys.cmd_flags patch

Christian Heimes added the comment: Committed in r59947, r59948 and r59949 -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1816] sys.cmd_flags patch

Guido van Rossum added the comment: 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. :-) __ Tracker <[EMAIL PROTECTED]>

[issue1816] sys.cmd_flags patch

Christian Heimes added the comment: Does anybody see a problem with this repr slot implementation for structseq? It gives this output: >>> os.stat(".") static PyObject * structseq_repr(PyStructSequence *obj) { PyObject *tup, *val, *repr; PyTypeObject *typ = Py_TYPE(obj);

[issue1816] sys.cmd_flags patch

Christian Heimes added the comment: 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. __ Tracker <[EMAIL PROTECTED]> _

Re: [issue1816] sys.cmd_flags patch

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 > a

[issue1816] sys.cmd_flags patch

Guido van Rossum added the comment: > 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. __ Tracker <[EMAIL PROTECTED]>

[issue1816] sys.cmd_flags patch

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

[issue1816] sys.cmd_flags patch

Guido van Rossum added the comment: Can't you use a namedtuple? Then printing it would show the names of the flags... __ Tracker <[EMAIL PROTECTED]> __

[issue1816] sys.cmd_flags patch

Christian Heimes added the comment: The new patch is using a struct sequence (like the result of os.stat): >>> import sys >>> sys.flags >>> dir(sys.flags) ['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '_

[issue1816] sys.cmd_flags patch

Guido van Rossum added the comment: 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 mod

[issue1816] sys.cmd_flags patch

New submission from Christian Heimes: 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. -- components: Interpreter Core files: trunk_sys_c