<p dir="ltr">Some quick comments below, a few more later:</p>
<p dir="ltr">On Thu, Sep 1, 2016 at 10:36 PM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
> One more iteration. PEPs repo not updated yet. Changes are renaming of<br>
> methods to be ``fromsize()`` and ``fromord()``, and moving ``memoryview`` to<br>
> an Open Questions section.<br>
><br>
><br>
> PEP: 467<br>
> Title: Minor API improvements for binary sequences<br>
> Version: $Revision$<br>
> Last-Modified: $Date$<br>
> Author: Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>>, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>><br>
> Status: Draft<br>
> Type: Standards Track<br>
> Content-Type: text/x-rst<br>
> Created: 2014-03-30<br>
> Python-Version: 3.6<br>
> Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01<br>
><br>
><br>
> Abstract<br>
> ========<br>
><br>
> During the initial development of the Python 3 language specification, the<br>
> core ``bytes`` type for arbitrary binary data started as the mutable type<br>
> that is now referred to as ``bytearray``. Other aspects of operating in<br>
> the binary domain in Python have also evolved over the course of the Python<br>
> 3 series.<br>
><br>
> This PEP proposes five small adjustments to the APIs of the ``bytes`` and<br>
> ``bytearray`` types to make it easier to operate entirely in the binary<br>
> domain:<br>
><br>
> * Deprecate passing single integer values to ``bytes`` and ``bytearray``<br>
> * Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative constructors<br>
> * Add ``bytes.fromord`` and ``bytearray.fromord`` alternative constructors<br>
> * Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods<br>
> * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators<br></p>
<p dir="ltr">I wonder if from_something with an underscore is more consistent (according to a quick search perhaps yes).</p>
<p dir="ltr">What about bytes.getchar and iterchars? A 'byte' in python 3 seems to be an integer. (I would still like a .chars property that gives a sequence view with __getitem__ and __len__ so that the getchar and iterchars methods are not needed)</p>
<p dir="ltr">chrb seems to be more in line with some bytes versions in for instance os than bchr. </p>
<p dir="ltr">Do we really need chrb? Better to introduce from_int or from_ord also in str and recommend that over chr?</p>
<p dir="ltr">-- Koos (mobile)</p>
<p dir="ltr">><br>
> Proposals<br>
> =========<br>
><br>
> Deprecation of current "zero-initialised sequence" behaviour without removal<br>
> ----------------------------------------------------------------------------<br>
><br>
> Currently, the ``bytes`` and ``bytearray`` constructors accept an integer<br>
> argument and interpret it as meaning to create a zero-initialised sequence<br>
> of the given size::<br>
><br>
> >>> bytes(3)<br>
> b'\x00\x00\x00'<br>
> >>> bytearray(3)<br>
> bytearray(b'\x00\x00\x00')<br>
><br>
> This PEP proposes to deprecate that behaviour in Python 3.6, but to leave<br>
> it in place for at least as long as Python 2.7 is supported, possibly<br>
> indefinitely.<br>
><br>
> No other changes are proposed to the existing constructors.<br>
><br>
><br>
> Addition of explicit "count and byte initialised sequence" constructors<br>
> -----------------------------------------------------------------------<br>
><br>
> To replace the deprecated behaviour, this PEP proposes the addition of an<br>
> explicit ``fromsize`` alternative constructor as a class method on both<br>
> ``bytes`` and ``bytearray`` whose first argument is the count, and whose<br>
> second argument is the fill byte to use (defaults to ``\x00``)::<br>
><br>
> >>> bytes.fromsize(3)<br>
> b'\x00\x00\x00'<br>
> >>> bytearray.fromsize(3)<br>
> bytearray(b'\x00\x00\x00')<br>
> >>> bytes.fromsize(5, b'\x0a')<br>
> b'\x0a\x0a\x0a\x0a\x0a'<br>
> >>> bytearray.fromsize(5, b'\x0a')<br>
> bytearray(b'\x0a\x0a\x0a\x0a\x0a')<br>
><br>
> ``fromsize`` will behave just as the current constructors behave when passed<br>
> a single<br>
> integer, while allowing for non-zero fill values when needed.<br>
><br>
><br>
> Addition of "bchr" function and explicit "single byte" constructors<br>
> -------------------------------------------------------------------<br>
><br>
> As binary counterparts to the text ``chr`` function, this PEP proposes<br>
> the addition of a ``bchr`` function and an explicit ``fromord`` alternative<br>
> constructor as a class method on both ``bytes`` and ``bytearray``::<br>
><br>
> >>> bchr(ord("A"))<br>
> b'A'<br>
> >>> bchr(ord(b"A"))<br>
> b'A'<br>
> >>> bytes.fromord(65)<br>
> b'A'<br>
> >>> bytearray.fromord(65)<br>
> bytearray(b'A')<br>
><br>
> These methods will only accept integers in the range 0 to 255 (inclusive)::<br>
><br>
> >>> bytes.fromord(512)<br>
> Traceback (most recent call last):<br>
> File "<stdin>", line 1, in <module><br>
> ValueError: integer must be in range(0, 256)<br>
><br>
> >>> bytes.fromord(1.0)<br>
> Traceback (most recent call last):<br>
> File "<stdin>", line 1, in <module><br>
> TypeError: 'float' object cannot be interpreted as an integer<br>
><br>
> While this does create some duplication, there are valid reasons for it::<br>
><br>
> * the ``bchr`` builtin is to recreate the ord/chr/unichr trio from Python<br>
> 2 under a different naming scheme<br>
> * the class method is mainly for the ``bytearray.fromord`` case, with<br>
> ``bytes.fromord`` added for consistency<br>
><br>
> The documentation of the ``ord`` builtin will be updated to explicitly note<br>
> that ``bchr`` is the primary inverse operation for binary data, while<br>
> ``chr``<br>
> is the inverse operation for text data, and that ``bytes.fromord`` and<br>
> ``bytearray.fromord`` also exist.<br>
><br>
> Behaviourally, ``bytes.fromord(x)`` will be equivalent to the current<br>
> ``bytes([x])`` (and similarly for ``bytearray``). The new spelling is<br>
> expected to be easier to discover and easier to read (especially when used<br>
> in conjunction with indexing operations on binary sequence types).<br>
><br>
> As a separate method, the new spelling will also work better with higher<br>
> order functions like ``map``.<br>
><br>
><br>
> Addition of "getbyte" method to retrieve a single byte<br>
> ------------------------------------------------------<br>
><br>
> This PEP proposes that ``bytes`` and ``bytearray`` gain the method<br>
> ``getbyte``<br>
> which will always return ``bytes``::<br>
><br>
> >>> b'abc'.getbyte(0)<br>
> b'a'<br>
><br>
> If an index is asked for that doesn't exist, ``IndexError`` is raised::<br>
><br>
> >>> b'abc'.getbyte(9)<br>
> Traceback (most recent call last):<br>
> File "<stdin>", line 1, in <module><br>
> IndexError: index out of range<br>
><br>
><br>
> Addition of optimised iterator methods that produce ``bytes`` objects<br>
> ---------------------------------------------------------------------<br>
><br>
> This PEP proposes that ``bytes`` and ``bytearray``gain an optimised<br>
> ``iterbytes`` method that produces length 1 ``bytes`` objects rather than<br>
> integers::<br>
><br>
> for x in data.iterbytes():<br>
> # x is a length 1 ``bytes`` object, rather than an integer<br>
><br>
> For example::<br>
><br>
> >>> tuple(b"ABC".iterbytes())<br>
> (b'A', b'B', b'C')<br>
><br>
><br>
> Design discussion<br>
> =================<br>
><br>
> Why not rely on sequence repetition to create zero-initialised sequences?<br>
> -------------------------------------------------------------------------<br>
><br>
> Zero-initialised sequences can be created via sequence repetition::<br>
><br>
> >>> b'\x00' * 3<br>
> b'\x00\x00\x00'<br>
> >>> bytearray(b'\x00') * 3<br>
> bytearray(b'\x00\x00\x00')<br>
><br>
> However, this was also the case when the ``bytearray`` type was originally<br>
> designed, and the decision was made to add explicit support for it in the<br>
> type constructor. The immutable ``bytes`` type then inherited that feature<br>
> when it was introduced in PEP 3137.<br>
><br>
> This PEP isn't revisiting that original design decision, just changing the<br>
> spelling as users sometimes find the current behaviour of the binary<br>
> sequence<br>
> constructors surprising. In particular, there's a reasonable case to be made<br>
> that ``bytes(x)`` (where ``x`` is an integer) should behave like the<br>
> ``bytes.fromint(x)`` proposal in this PEP. Providing both behaviours as<br>
> separate<br>
> class methods avoids that ambiguity.<br>
><br>
><br>
> Open Questions<br>
> ==============<br>
><br>
> Do we add ``iterbytes`` to ``memoryview``, or modify<br>
> ``memoryview.cast()`` to accept ``'s'`` as a single-byte interpretation? Or<br>
> do we ignore memory for now and add it later?<br>
><br>
><br>
> References<br>
> ==========<br>
><br>
> .. [1] Initial March 2014 discussion thread on python-ideas<br>
> (<a href="https://mail.python.org/pipermail/python-ideas/2014-March/027295.html">https://mail.python.org/pipermail/python-ideas/2014-March/027295.html</a>)<br>
> .. [2] Guido's initial feedback in that thread<br>
> (<a href="https://mail.python.org/pipermail/python-ideas/2014-March/027376.html">https://mail.python.org/pipermail/python-ideas/2014-March/027376.html</a>)<br>
> .. [3] Issue proposing moving zero-initialised sequences to a dedicated API<br>
> (<a href="http://bugs.python.org/issue20895">http://bugs.python.org/issue20895</a>)<br>
> .. [4] Issue proposing to use calloc() for zero-initialised binary sequences<br>
> (<a href="http://bugs.python.org/issue21644">http://bugs.python.org/issue21644</a>)<br>
> .. [5] August 2014 discussion thread on python-dev<br>
> (<a href="https://mail.python.org/pipermail/python-ideas/2014-March/027295.html">https://mail.python.org/pipermail/python-ideas/2014-March/027295.html</a>)<br>
> .. [6] June 2016 discussion thread on python-dev<br>
> (<a href="https://mail.python.org/pipermail/python-dev/2016-June/144875.html">https://mail.python.org/pipermail/python-dev/2016-June/144875.html</a>)<br>
><br>
><br>
> Copyright<br>
> =========<br>
><br>
> This document has been placed in the public domain.<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe:<br>
> <a href="https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com">https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com</a><br><br></p>
<p dir="ltr">-- <br>
+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven">http://twitter.com/k7hoven</a> +</p>