On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <jimjjewett(a)gmail.com> wrote:
> How have you decided which attributes are CPython-specific?
> I'm not saying your decisions are wrong, but I find all of them at
> least up for questioning.
>
> Those marked non-CPython-specific
> ============================
>
> - argv
>
> Does this make sense for embedded python?
Maybe, that doesn't mean it shouldn't be there.
>
>
> - byteorder
>
> This seems fairly low-level. I wouldn't expect to need it if working
> strictly at the python level, unless writing wire-protocols *and*
> working with objects larger than bytes.
>
> If you do need it, should text representation (UCS2 vs UCS4 vs UTF8 vs
> bytestrings) be exposed?
It should probably go to platform.
>
>
> - builtin_module_names, path, and modules
>
> I'm not sure why these three are together.
> What is the builtin_module_names?
Modules which are compiled into the interpreter (like sys and nt, mac, or
posix). Maybe, it should go to interpreter.
>
> sys.path might be an oddball on a database-based system, such as classic
> PalmOS.
>
> - subversion, copyright, hexversion, version, and version_info
>
> These do seem reasonable; they refer to the executable. Though even
> then, I wonder if there should be a way to extend it for
> customizations. ("embedded in XYZ", or "without unicode")
>
> - displayhook, __displayhook__
> - excepthook, __excepthook__, exc_info, and exc_clear
>
> Are these required of every implementation?
Every one that wants to work. :)
>
>
> - exec_prefix and prefix
> - executable
> - exit
>
> Are these? And do they make sense when embedded?
sys.executable and exec_prefix is allowed to be empty.
>
>
> - flags, py3kwarning, dont_write_bytecode, and warn_options
>
> Is the bytecode stage itself a crucial part of the langauge? I had
> thought of the the bytecode as an implementation detail, and so
> whether or not to write it out would seem even more
> implementation-specific.
What the bytecode is and how it is generated is implementation specific.
It's not the fact you're writing it or not.
>
>
> - getfilesystemencoding
>
> OK; but this seems to interact with text representation and path.
>
> - get/setprofile
> - get/settrace
>
> These seem as CPython-specific as anything frame-related.
Jython provides them.
>
>
> - getwindowsversion
>
> This obviously doesn't make sense on a non-windows machine; why isn't
> it in platform instead of sys?
>
> - maxint and maxunicode
>
> I'm not sure what value these have. I assume maxint doesn't include
> longs -- so is it just the maximum efficiently represented integer, or
> is this specific to C extensions, or ..?
The maximum int on the system. Jython provides this.
>
>
> And is maxunicode just roundabout way of figuring out the concrete
> representation (code points) of unicode characters?
It is the max Unicode character that Python's unicode implementation is
capable of handling. Jython provides this.
>
>
> - platform
>
> Should this be subsumed by the platform module?
Hmm. I don't know. For basic platform tests, this sure is easy.
>
>
> - ps1 and ps2
>
> This really seems like a config issue rather than sys.
Yeh, sys is about runtime Python. Besides, it's global to all
implementations.
>
>
> - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>
> These, at least, are clear -- to the extent that they make sense. (In
> some environments, they don't.)
>
> - tracebacklimit
>
> How is this different from setrecursionlimit?
It defines how many lines of traceback are printed in an exception.
>
>
> Those marked CPython-specific
> =========================
>
> - get/setrecursionlimit
> - get/setcheckinterval
>
> These are runtime characteristics, but I don't see them (necessarily)
> being tied to the implementation. Just returning False to say the
> limit isn't relevant makes sense, and returning some huge number may
> work in practice. If you care enough to say "Can I recurse 3000
> frames?", that is a legitimate question, and it just so happens that
> Jython should always answer "yes".
Actually, I believe you get a stack overflow before that. It doesn't tell
you that.
>
>
> - _getframe and _current_frame
>
> I expect the details of a frame may be different with different
> implementations, but is there an implemenation that doesn't have
> frames at all? (I could imagine that it is a pain to get a frame from
> a compiled version, but the Java tracebacks and introspection need
> something roughly equivalent.)
Well, it's not there now...
>
>
> - getrefcount
>
> This should probably be in gc, rather that sys.
>
> - get/setdlopenflags
> - settscdumps
> - api_version
> - winver
> - dllhandle
> - float_info
>
> I don't find all of these in 2.5 help(sys), but to the extent I
> understand them, they are about extensions rather the system. If
> Python under java or .net did open .dlls or support ffi extensions, I
> would expect a similar API.
Some of them are new in 2.6. Look at those docs.
>
>
> - _compact_freelists
> - _clear_type_cache
>
> These should probably be in gc, rather that sys.
>
>
> To summarize my alternative
> ======================
>
> sys -- representing the built system
>
> - subversion, copyright, hexversion, version, and version_info
> - builtin_module_names
> - exec_prefix and prefix
> - executable
> - exit
>
> gc -- representing memory management
>
> - getrefcount
> - _compact_freelists
> - _clear_type_cache
>
> platform -- representing the OS environment
> - getfilesystemencoding
> - getwindowsversion
> - platform
>
> runtime -- representing this particular runtime environment
Sys is the runtime environment. We don't need a new module for that.
>
>
> - argv
> - path (today's sys.path, not os.path)
> - modules
> - displayhook, __displayhook__
> - excepthook, __excepthook__, exc_info, and exc_clear
> - flags
> - py3kwarning, warn_options (why are these not just in warnings?)
> - dont_write_bytecode
> - get/setprofile
> - get/settrace
> - ps1 and ps2
> - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>
> - tracebacklimit
> - get/setrecursionlimit
> - get/setcheckinterval
> - _getframe and _current_frame
>
>
> ffi -- representing bit-level foreign function interface details
> (maybe tied to ctypes?)
>
> - byteorder
> - maxint and maxunicode
> - get/setdlopenflags
> - settscdumps # I'm not sure what this one is
> - api_version
> - winver
> - dllhandle
> - float_info
>
>
> (whehter os and os.path should also be mixed in to the reorg ... is a
> different question.)
>
> -jJ
>
--
Cheers,
Benjamin Peterson
