[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On Mon, Nov 8, 2021 at 8:21 PM Ethan Furman wrote: > The difference with the built-in ascii is the absence of extra quotes and the > `b` indicator when a string is used: > > ``` > >>> u_var = u'abc' > >>> bytes.ascii(u_var) > b'abc' What about bytes, bytearray and memoryview? What is the expected behavior? I expect that memoryview is not supported (return something like b''), and that bytes and bytearray are copied without adding "b" prefix or quotes. bytes.ascii(b'abc') == b'abc' bytes.ascii(bytearray(b'abc')) == b'abc' I just suggest to elaborate the specification in the PEP. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3HJQPZB6QWM7IDPDU3KJ4FVY4ESJHQOK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On 11/8/21 4:45 AM, Victor Stinner wrote:
> Is it implement "like" ascii(obj).encode("ascii") but with minor
> changes? What changes?
It works like `str()`, but you get ascii-encoded bytes (or an exception if
that's not possible).
The difference with the built-in ascii is the absence of extra quotes and the
`b` indicator when a string is used:
```
>>> u_var = u'abc'
>>> b_var = b'abc'
>>> str(u_var)
'abc'
>>> str(b_var)
"b'abc'"
>>> ascii(b_var)
"b'abc'"
>>> b'%a' % (u_var) # the docs will be updated to refer to %a as "ascii-repr"
b"'abc'" # as it mirrors %r but only returns ascii-encoded bytes
>>> bytes.ascii(u_var)
b'abc'
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/X3XUYTCEM7IWTID2GING62LCEG3XKM7Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
The ascii() constructor is not well specified by the PEP. There are
only a few examples. I don't understand how it's supposed by be
implemented. Would you mind to elaborate its specification?
Is it implement "like" ascii(obj).encode("ascii") but with minor
changes? What changes?
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LE5WDOPOCEVSLSFYVZQYDGZYUBYPLAN4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On Fri, Nov 5, 2021 at 2:59 AM Jonathan Goble wrote:
>
> On Thu, Nov 4, 2021 at 10:37 AM Eric Fahlgren wrote:
>>
>> On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman wrote:
>>>
>>> >>> bytearray.fromsize(5, fill=b'\x0a')
>>> bytearray(b'\x0a\x0a\x0a\x0a\x0a')
>>
>>
>> What happens if you supply more than one byte for the fill argument? Silent
>> truncation, raise ValueError('too long') or ???
>
>
> It would seem reasonable to me for a multi-byte sequence to be filled as-is
> in a repeating pattern, perhaps truncating the last repetition if len(fill)
> is not an even multiple of the size. At least that's the intuitive behavior
> for me.
>
> That said, I don't know if such behavior would be useful in practice (i.e.
> whether there's a use case for it).
>
It's definitely useful behaviour, but aligns better with sequence
multiplication than a fill= constructor parameter. My expectation (or
if you prefer: my preferred shed colour) would be ValueError.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/R35YPY4TRHMGDBELZTO25Z2UZBAEB7IC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On Thu, Nov 4, 2021 at 10:37 AM Eric Fahlgren
wrote:
> On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman wrote:
>
>> >>> bytearray.fromsize(5, fill=b'\x0a')
>> bytearray(b'\x0a\x0a\x0a\x0a\x0a')
>>
>
> What happens if you supply more than one byte for the fill argument?
> Silent truncation, raise ValueError('too long') or ???
>
It would seem reasonable to me for a multi-byte sequence to be filled as-is
in a repeating pattern, perhaps truncating the last repetition if len(fill)
is not an even multiple of the size. At least that's the intuitive behavior
for me.
That said, I don't know if such behavior would be useful in practice (i.e.
whether there's a use case for it).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/I4OE6VPBOBYBUQD45PJJKNR4BHA5EQF6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman wrote:
> >>> bytearray.fromsize(5, fill=b'\x0a')
> bytearray(b'\x0a\x0a\x0a\x0a\x0a')
>
What happens if you supply more than one byte for the fill argument?
Silent truncation, raise ValueError('too long') or ???
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GHXKHPNJSEK6SRNG2O3ZLZMKAEZTMVLS/
Code of Conduct: http://python.org/psf/codeofconduct/
