[James Y Knight] > > Basically, I'd like to see them be given a binding somewhere, and have > > their claimed module agree with that, but am not particular as to > > where. Option #2 seemed to be rejected last time, and option #1 was > > given approval, so that's what I wrote a patch for. It sounds like it's > > getting pretty strong "no" votes this time around, however. Therefore, > > I would like to suggest option #3, with <newmodule> being, say, > > 'internals'.
[GvR] > +1 That gives them a place to live and doesn't clutter __builtin__. However, it should be named __internals__. The next question is how to document it. My preference is to be clear that it is implementation specific (Jython won't have cell, PyCFunction, and dictproxy types); that it is subject to change between versions (so as not to prematurely immortalize design/implementation accidents); and that they have only esoteric application (99.9% of programs won't need them and should avoid them like the plague). Calling it __internals__ will help emphasize that we are exposing parts of the implementation that were consciously left semi-private or undocumented. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
