pypy_vm (was: Proposal: new "interpreter" module)
"Benjamin Peterson" <musiccomposition@gmail.com> wrote:
On Mon, Apr 7, 2008 at 3:41 PM, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
I think the idea is nice, but PyPy couldn't really expose a "pypy" module, since that is the namespace the implementation itself is living in. Maybe add a suffix to the implementation name? cpython_vm or so.
You can name your implementation specific module anything you want. We're not forcing anybody else to use our naming scheme! :)
Yes and no. If important information is in the interpreter-specific location, it would be nice to know where that is. That could be a specific module name, but a module-name-pattern might be enough. sys.interpreter=cpython (or pypy_js_43, or whatever is chosen) <==> cpython_vm (or pypy_js_43_vm) is the module for internals Also note that even the interpreter-specific modules will probably be somewhat related. Just because something is implementation-defined doesn't mean prevent implementations from making similar choices. For example, even if Jython chooses to limit recursion only through memory exhaustion, some pypy targets might use exactly the same limits as standard CPython -- in which case, the obvious names for them to use will match CPython. -jJ
Le mardi 08 avril 2008 à 13:42 -0400, Jim Jewett a écrit :
If important information is in the interpreter-specific location, it would be nice to know where that is. That could be a specific module name, but a module-name-pattern might be enough.
sys.interpreter=cpython (or pypy_js_43, or whatever is chosen) <==> cpython_vm (or pypy_js_43_vm) is the module for internals
Then why not: sys.interpreter_module = cpython <=> cpython sys.interpreter_module = pypy_vm <=> pypy_vm sys.interpreter_module = org.baked.beans.jython <=> org.baked.beans.jython :) ie. those targets which choose to use a "_vm" suffix make it explicit rather than imposing that naming upon everyone ?
Also note that even the interpreter-specific modules will probably be somewhat related. Just because something is implementation-defined doesn't mean prevent implementations from making similar choices.
I think that's the real problem here, but there is no simple scheme that will allow us to solve it.
On 2008-04-08 20:06, Antoine Pitrou wrote:
Le mardi 08 avril 2008 à 13:42 -0400, Jim Jewett a écrit :
If important information is in the interpreter-specific location, it would be nice to know where that is. That could be a specific module name, but a module-name-pattern might be enough.
sys.interpreter=cpython (or pypy_js_43, or whatever is chosen) <==> cpython_vm (or pypy_js_43_vm) is the module for internals
Then why not: sys.interpreter_module = cpython <=> cpython ?sys.interpreter_module = pypy_vm <=> pypy_vm ?sys.interpreter_module = org.baked.beans.jython <=> ?org.?baked.beans.jython :)
ie. those targets which choose to use a "_vm" suffix make it explicit rather than imposing that naming upon everyone ?
We already have a way to identify the Python implementation and it works for CPython, IronPython and Jython:
import platform platform.python_implementation() 'CPython'
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 08 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
participants (3)
-
Antoine Pitrou -
Jim Jewett -
M.-A. Lemburg