>>
>>
>> Method proliferation on builtins is a Big Deal(TM)
>
> I wanted to quantify this concept, so here's a quick metric that helps
> convey how every time we add a new builtin method we're immediately
> making Python harder to comprehend:
>
>>>> def get_builtin_types():
> ... import builtins
> ... return {name:obj for name, obj in vars(builtins).items()
> if isinstance(obj, type) and not (name.startswith("__") or
> issubclass(obj, BaseException))}
> ...
>>>> len(get_builtin_types())
> 26
Sure -- adding a new builtin is s big deal.
>>>> def get_builtin_methods():
> ... return [(name, method_name) for name, obj in
> get_builtin_types().items() for method_name, method in
> vars(obj).items() if not method_name.startswith("__")]
> ...
>>>> len(get_builtin_methods())
> 230
So what? No one looks in all the methods of builtins at once. If we
have anything like an OO System (and python builtins only sort of
do...) then folks look for a built in that they need, and only then
look at its methods.
If you need to work with bytes, you'll look at the bytes object and
bytarray object. Having to go find some helper function module to know
to efficiently do something with bytes is VERY non-discoverable!
bytes and bytarray are already low-level objects -- adding low-level
functionality to them makes perfect sense.
And no, this is not just for asycio at all -- it's potentially useful
for any byte manipulation.
+1 on a frombuffer() method.
> Putting special purpose functionality behind an import gate helps to
> provide a more explicit context of use
This is a fine argument for putting bytearray in a separate module --
but that ship has sailed. The method to construct a bytearray from a
buffer belongs with the bytearray object.
-CHB
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
