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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4