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

[Benjamin Peterson]

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>
> wrote:
> > 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
> new
> >  > additions are low-level and CPython specific. I believe the sys
> module
> >  > should strive to be an interpreter neutral, clean module. Hence, I
> propose
> >  > the "interpreter" module. We could move all those internal functions
> like
> >  > _getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to
> it.
> >  > Also, if we decided to remove the types module, this would be a
> natural
> >  > place for frames and code objects.
> >
> >  The idea popped up several months ago when we were discussion the
> future
> >  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.

>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080404/7d4994be/attachment.htm