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
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