Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor
>>
>>
>> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)
> The proposal is that it should be documented as being part of the > language spec starting in 3.4 (or whatever). Is the performance characteristics of any object part of the language spec? I.e if someone wrote an implementation with an O(n) insert dict, it would suck, but wouldn't it still be Python? -CHB > So applications that > support Python 2.7 can't rely on it, sure. But if I have an > application that requires, say, 3.5+ but I don't want to depend on > CPython-only implementation details, then I'm still allowed to use it. > > AFAIK basically the only project that would be affected by this is > PyPy, and I when I asked on #pypy they said: > > njs`: I think we either plan to or already support this > > so I'm not sure why this is controversial. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)
On Wed, Oct 19, 2016 at 2:57 AM, Chris Barker - NOAA Federal wrote: >> The proposal is that it should be documented as being part of the >> language spec starting in 3.4 (or whatever). > > Is the performance characteristics of any object part of the language spec? > > I.e if someone wrote an implementation with an O(n) insert dict, it > would suck, but wouldn't it still be Python? This exact question came up when MicroPython wanted to represent Unicode strings internally as UTF-8. It was decided that having O(n) indexing/slicing was acceptable, and was something that the implementation could judge the value of. (Since uPy is designed for smaller systems than CPython is, O(n) is less significant.) ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] typing.py doesn't export Pattern and Match; is that intentional
E.g.: import typing print(typing.Pattern, typing.Match) # Works. from typing import * print(Pattern, Match) # NameError: name 'Pattern' is not defined A quick look shows that typing.py doesn't have Pattern and Match in __all__. Was this intentional, or just an oversight? -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] typing.py doesn't export Pattern and Match; is that intentional
Yes, that's intentional. (We have a separate tracker for this module, https://github.com/python/typing/issues) On Tue, Oct 18, 2016 at 11:08 AM, Ryan Gonzalez wrote: > E.g.: > > > import typing > print(typing.Pattern, typing.Match) # Works. > from typing import * > print(Pattern, Match) # NameError: name 'Pattern' is not defined > > > A quick look shows that typing.py doesn't have Pattern and Match in __all__. > Was this intentional, or just an oversight? > > > -- > Ryan > [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something’s wrong. > http://kirbyfan64.github.io/ > > > ___ > Python-Dev mailing list > [email protected] > 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) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
