Mailing List Archive

On 9/9/2021 1:56 PM, Ethan Furman wrote:
> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>
> > While I think int.to_bytes() is pretty obscure (I knew about it,
> forgot about it, and learned
> > about it again!) I’m not so sure it’s any less obscure than a
> proposed bytes.fromint().
> >
> > So why don’t we just relax int.to_bytes()’s signature to include
> natural default values:
> >
> >      int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)

Default arg values are one of Python's great features.

> > Then I ought to be able to just do
> >
> >      >>> (65).to_bytes()
> >      b’A’
>
> That seems so much worse than
>
>     >>> bchr(65)
>     b'A'
>
> ;-)

Except that .to_bytes already exists, and arguably should have had such
defaults from the beginning, making any new function to do the same
thing superfluous.

--
Terry Jan Reedy


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/A7OQPRVVE4WPQ7YCIMCGK2AMPXR6GYTB/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sep 9, 2021, at 10:56, Ethan Furman <ethan@stoneleaf.us> wrote:
>
> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>
> > While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned
> > about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint().
> >
> > So why don’t we just relax int.to_bytes()’s signature to include natural default values:
> >
> > int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)
> >
> > Then I ought to be able to just do
> >
> > >>> (65).to_bytes()
> > b’A’
>
> That seems so much worse than
>
> >>> bchr(65)
> b'A'
>
> ;-)

Maybe, but given that you can *already* do the equivalent of bchr() with:

>>> (65).to_bytes(1, sys.byteorder)
b'A'

it seems like a small stretch to make that more usable, and that would outweigh adding a difficult to understand new builtin. TOOWTDI.

In case you really want bchr():

def bchr(x):
return x.to_bytes(1, sys.byteorder)

>>> bchr(65)
b’A'

Cheers,
-Barry

On 9/9/21 12:12 PM, Barry Warsaw wrote:
> On Sep 9, 2021, at 10:56, Ethan Furman wrote:
>> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>>
>>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned
>>> about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint().
>>>
>>> So why don’t we just relax int.to_bytes()’s signature to include natural default values:
>>>
>>> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)
>>>
>>> Then I ought to be able to just do
>>>
>>> >>> (65).to_bytes()
>>> b’A’
>>
>> That seems so much worse than
>>
>> >>> bchr(65)
>> b'A'
>>
>> ;-)
>
> Maybe, but given that you can *already* do the equivalent of bchr() with:
>
>>>> (65).to_bytes(1, sys.byteorder)
> b'A'
>
> it seems like a small stretch to make that more usable, and that would outweigh adding a difficult
> to understand new builtin. TOOWTDI.

FWIW, bchr doesn't feel (much) like a new built-in, but more like a swap from unichr. At any rate, I know the built-in
is not going to happen.

int.to_bytes() doesn't feel like the One Obvious Way to me, and it certainly doesn't do much for readability in the
bytearray case.

Instead of `.fromord()` or `.fromint()` (or `int.to_bytes()`), my new favorite name, guaranteed not to change for at
least the rest the day, is:

bytes.chr()
bytearray.chr()

- this gets rid of the superflous b in bchr (not needed as the method is on bytes/bytearray)
- has a nice symmetry with both the Python 3 chr(), and the answer to "where did the Python 2 chr() go?" question

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/WJOTPVYSPLK4RX2EFO2C4XK6KJ4Y47LE/
Code of Conduct: http://python.org/psf/codeofconduct/

On 09/09/2021 18:54, raymond.hettinger@gmail.com wrote:
>> I would rather keep `bchr` and lose the `.fromint()` methods.
> For me, "bchr" isn't a readable name. If I expand mentally expand it to "byte_character", it becomes an oxymoron that opposes what we try teach about bytes and characters being different things.
>
> Can you show examples in existing code of how this would be used? I'm unclear on how frequently users need to create a single byte from an integer. For me, it is very rare.
It's probably rare, but recently I was converting from Python 2 to
Python 3 a program that implements a data compression algorithm (LZW). 
It (now) constructs the compressed data as a bytes object. Sometimes it
needs to add a series of bytes, sometimes a single byte converted from
an int.  Not knowing if there was a "recommended" way to do the latter,
I found something that worked, viz.
    bytes((i,))
But it felt a bit of a kludge.  I would have used something like bchr if
(a) it existed (b) I knew about it.
Rob Cliffe
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/VWCOIYTKYOGWWIL7KEUMJSU4P2C3EEPN/
Code of Conduct: http://python.org/psf/codeofconduct/

Adding default arguments to int.to_bytes() is both useful on its own merits and kind of too easy *not* to do, so...

https://bugs.python.org/issue45155
https://github.com/python/cpython/pull/28265

-Barry

> On Sep 9, 2021, at 12:12, Barry Warsaw <barry@python.org> wrote:
>
> Signed PGP part
> On Sep 9, 2021, at 10:56, Ethan Furman <ethan@stoneleaf.us> wrote:
>>
>> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>>
>>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned
>>> about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint().
>>>
>>> So why don’t we just relax int.to_bytes()’s signature to include natural default values:
>>>
>>> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)
>>>
>>> Then I ought to be able to just do
>>>
>>>>>> (65).to_bytes()
>>> b’A’
>>
>> That seems so much worse than
>>
>>>>> bchr(65)
>> b'A'
>>
>> ;-)
>
> Maybe, but given that you can *already* do the equivalent of bchr() with:
>
>>>> (65).to_bytes(1, sys.byteorder)
> b'A'
>
> it seems like a small stretch to make that more usable, and that would outweigh adding a difficult to understand new builtin. TOOWTDI.
>
> In case you really want bchr():
>
> def bchr(x):
> return x.to_bytes(1, sys.byteorder)
>
>>>> bchr(65)
> b’A'
>
> Cheers,
> -Barry
>
>
>

On Fri, 10 Sep 2021, 12:32 am Arnaud Delobelle, <arnodel@gmail.com> wrote:

> It probably won't fly but why not bytes.frombyte?
>
> There's no such thing as a byte type in Python, only bytes, so I want
> to argue it makes it clear the argument is a number in the range
> 0..255 and the result is a bytes object containing this single byte
> value.
>

The getbyte() and iterbytes() methods added by the PEP make a length 1
bytes object the pseudo "byte" type, just as a length 1 string is the
pseudo "character" (technically "code point") type, so "frombyte()" would
have the type implications backwards (it produces a "byte", it doesn't
really read one).

I think it's OK for "int.from_bytes", "int.to_bytes", "bytes.fromint" and
"byte array.fromint" to have closely related names, since they're closely
related operations. The OverflowError raised for out of bounds values in
the latter two methods could even mention int.to_bytes explicitly.

While the SC already accepted "fromint", the range limitation could be made
more explicit by appending "byte" to give "bytes.fromintbyte" and
"bytearray.fromintbyte" (thus naming a pseudo "int byte" type for integers
in the range 0-255 inclusive). An advantage of this approach is to give a
specific name to the kinds of values that regular indexing and iteration of
bytes objects produce.

The SC has already rejected "fromord" as too obscure.

I'd be OK with bytes.bchr, but bytearray.bchr would look odd to me, so I
don't like that option as a whole.

For "bytes.byte", I have 3 objections:
* I think Greg's Smith's API stuttering concerns are valid
* I think it's potentially ambiguous as to whether it is an alternate
constructor or an indexed access method (i.e. doing what getbyte() does in
the PEP)
* I don't like it as a bytearray method name

Cheers,
Nick.





> Tentatively,
>
> Arnaud
>
> PS. But truly I feel like this method is superfluous.
>
> On Thu, 9 Sept 2021 at 11:11, Victor Stinner <vstinner@python.org> wrote:
> >
> > I proposed bytes.byte earlier in this thread:
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/
> >
> > Gregory dislikes the name: "I don't *like* to argue over names (the
> > last stage of anything) but I do need to point out how that sounds to
> > read".
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/
> >
> > That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-)
> >
> > Victor
> >
> > On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou <antoine@python.org>
> wrote:
> > >
> > > On Thu, 9 Sep 2021 18:55:04 +1000
> > > Nick Coghlan <ncoghlan@gmail.com> wrote:
> > > >
> > > > P.S. The fact that it *didn't* look like the inverse operation for
> > > > `int.from_bytes` was one advantage of calling the method
> > > > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the
> SC
> > > > is right that `bytes.fromint` is a more comprehensible method name
> > > > overall.
> > >
> > > Perhaps we can call it `bytes.byte` to make it unambiguous?
> > >
> > > Regards
> > >
> > > Antoine.
> > >
> > >
> > > _______________________________________________
> > > Python-Dev mailing list -- python-dev@python.org
> > > To unsubscribe send an email to python-dev-leave@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/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > 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-leave@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/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/P7XG5CLLBXZTS6UE72KSGWLVYXRDXKT4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Ethan Furman writes:

> `int.from_bytes` methods, and is an appropriate name for the target
> domain (where bytes are treated as characters).

The relevant domains treat bytes as bytes. It's frequently useful
(and dare I say "Pythonic"?) for *programmers* to take advantage of
the mnemonic of treating 95 of the bytes as the ASCII encoding of
characters. It follows that it's good sense for protocol designers to
restrict themselves to that alphabet for their magic numbers. But
standards themselves make clear that these protocols handle *octets*
(historically, "byte" was too ambiguous for network protocols!), not
characters or ints that happen to fit into 8 bits. The "control
characters" aren't really characters even when they're syntactically
significant, some of them are not significant unless combined in a
particular order (CRLF), and of course the bytes 0x80-0xFF are never
treated as characters.

As far as I can see, the "programmers' mnemonic" interpretation gets
us everything we really want in this area. We should avoid the idea
that "bytes are treated as characters" because they aren't, and
because that way lies the madness that incited the upheaval of Python
3 in the first place.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/DCSW7WLND6SZ6CGV4BZXP6QEOS2MZ7FA/
Code of Conduct: http://python.org/psf/codeofconduct/

On 9/9/21 12:04 PM, Terry Reedy wrote:

> Except that .to_bytes already exists, and arguably should have had such defaults from the
> beginning, making any new function to do the same thing superfluous.

New functions aren't always about new functionality; sometimes they are about increased usability.

Everything in the PEP can already be accomplished, just not easily:

bstr = b'hello world'

bchr = bstr.getbyte(7) # proposed
bchr = bstr[7:8] # existing

for bchr in bstr.iterbytes(): # proposed
...
for num in bstr: # existing
bchr = bytes([bchr])

bchr = bytes.fromint(65) # proposed
bchr = bytes([65]) # existing

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/VRZOW3CKHC25I43EIFZO7ZOEOHYBZFNX/
Code of Conduct: http://python.org/psf/codeofconduct/

There is some discussion going on in bpo-45155 about what the default value of the `byteorder` argument should be for int.to_bytes() and int.from_bytes():

https://bugs.python.org/issue45155

I’ve created a short Discourse poll if you’d like to weigh in.

https://discuss.python.org/t/what-should-be-the-default-value-for-int-to-bytes-byteorder/10616

Cheers,
-Barry

Le 13/09/2021 à 19:01, Barry Warsaw a écrit :
> There is some discussion going on in bpo-45155 about what the default value of the `byteorder` argument should be for int.to_bytes() and int.from_bytes():

Hello,

a use case and feature request:

I have used int.to_bytes() and int.from_bytes() interactively at the
Python REPL for picking apart pieces of binary data files, in contexts
of debugging or casual reverse-engineering (I could have used `struct`,
but then I would have needed to reread the doc ;-)

For this use case, setting defaults for the arguments is obviously
beneficial (less typing), and the most comfortable defaults would be:

- for `length`, the minimum length needed to encode the integer (I
mostly care for the content, not the leading or trailing zeros);

- for `byteorder`, preferably a fixed default so I can remember it once
and for all, and in any case something rather than None (if the bytes
are reversed, I'll still recognize them).

Whatever comes out of this discussion, it would be nice if the
`byteorder` constants got a one-character short form, be it 'l' and 'b'
for discoverability, or '<' and '>' for consistency with `struct`.
Having to type 'little' is painfully long at the REPL.

Cheers,
Baptiste
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/7ZTUJDMSJEBLORSTHV6X6DZVESIKOKKL/
Code of Conduct: http://python.org/psf/codeofconduct/