[stdlib-sig] Proposal: new "interpreter" module
musiccomposition at gmail.com
Fri Apr 4 15:29:42 CEST 2008
On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon <brett at python.org> wrote:
> On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de>
> > Benjamin Peterson schrieb:
> > > I originally brought this in the discussion about removing types, but
> it can
> > > be separate.
> > >
> > > Through the years, sys has gather a fare share of crud. Much of these
> > > additions are low-level and CPython specific. I believe the sys
> > > should strive to be an interpreter neutral, clean module. Hence, I
> > > the "interpreter" module. We could move all those internal functions
> > > _getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to
> > > Also, if we decided to remove the types module, this would be a
> > > place for frames and code objects.
> > The idea popped up several months ago when we were discussion the
> > of the types module. Guido suggested the name 'pyvm'. The module was
> > meant to contain low level interfaces to the (C)Python virtual machine.
> > Once the pyvm module is implemented the sys module should only contain
> > system methods which can be implemented by all flavors of Python.
> This is exactly the type of separation I want to see. Unfortunately,
> because it would be a new module that means we will have to go through
> the typical steps needed to add it and can't rely on 2to3 and the
> reorg to handle it.
> But I totally support moving CPython-specific stuff to another module.
> Probably the best thing to do is write up a proposal of what should go
> where, run it past here, and the write up a PEP to present to
> python-dev. Then we can introduce the module in 2.6/3.0. Proper
> deprecations will be needed in the sys module so that people can
> slowly transition to the new module (whether it is named interpreter,
> pyvm, or some other name) since the sys module can't obviously just
> suddenly drop some methods or attributes.
> And do realize this is a chance to change the API so that if a
> property-like situation is better than a method call that can be used.
> Sound good to people? If so, who wants to take this on?
If there is further support, I will.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the stdlib-sig