Eric Snow wrote:
The implementation for sys.implementation is going to use a new (but
"private") type[1]. It's basically equivalent to the following:
Does this really need to be written in C rather than Python?
class namespace:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
def __repr__(self):
keys = (k for k in self.__dict__ if not k.startswith('_'))
pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys))
return "{}({})".format(type(self).__name__, ", ".join(pairs))
There were other options for the type, but the new type was the best
fit and not hard to do. Neither the type nor its API is directly
exposed publicly, but it is still accessible through
"type(sys.implementation)".
This brings me to a couple of questions:
1. should we make the new type un-instantiable (null out tp_new and tp_init)?
2. would it be feasible to officially add the type (or something like
it) in 3.3 or 3.4?
I've had quite a bit of positive feedback on the type (otherwise I
wouldn't bother bringing it up). But, if we don't add a type like
this to Python, I'd rather close the loophole and call it good (i.e.
*not* introduce a new type by stealth). My preference is for the type
(or equivalent) to be blessed in the language. Regardless of the
specific details of such a type, my more immediate concern is with the
impact on sys.implementation of python-dev's general sentiment in this
space.
-eric
[1] http://bugs.python.org/issue14673
_______________________________________________
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/mark%40hotpy.org
_______________________________________________
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
