[Python-Dev] PEP 460 reboot

Guido van Rossum guido at python.org
Wed Jan 15 05:17:03 CET 2014

I am exhausted from all these discussions. I just recommend not
touching those docs.

On Tue, Jan 14, 2014 at 8:08 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum <guido at python.org> wrote:
>> Personally I wouldn't add any words suggesting or referring to the
>> option of creation another class for this purpose. You wouldn't
>> recommend subclassing dict for constraining the types of keys or
>> values, would you?
> Yes, and it is so clear that I suspect I'm missing some context for
> your question.
> Do I recommend that each individual application should create new
> concrete classes instead of just using the builtins?  No.
> When trying to understand (learn about) the text/binary distinction, I
> do recommend pretending that they are represented by separate classes.
>  Limits on the values in a bytearray are NOT the primary reason for
> this; the primary reason is that operations like the literal
> representation or the capitalize method are arbitrary nonsense unless
> the data happens to be representing ASCII.
>     sound_sample.capitalize()  -- syntactically valid, but semantic garbage
>     header.capitalize() -- OK, which implies that data is an instance
> of something more specific than bytes.
> Would I recommend subclassing dict if I wanted to constrain the key
> types?  Yes -- though MutableMapping (fewer gates to guard) or the
> upcoming TransformDict would probably be better still.
> The existing dict implementation itself effectively uses (hidden,
> quasi-)subclasses to restrict types of keys strictly for efficiency.
> (lookdict* variants)
> -jJ
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list