[stdlib-sig] Proposal: new "interpreter" module

[Benjamin Peterson]

On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <jimjjewett at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/30b1fb23/attachment-0001.htm