RetroSearch Browse

Thu May 31 09:21:36 CEST 2012 · https://mail.python.org/pipermail/python-dev/2012-May/119771.html

The implementation for sys.implementation is going to use a new (but
"private") type[1].  It's basically equivalent to the following:

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-May/119771.html below:

[Python-Dev] a new type for sys.implementation