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() int
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-b
On 09/09/2021 18:54, raymond.hettin...@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 be
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 usab
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 tre
On Fri, 10 Sep 2021, 12:32 am Arnaud Delobelle, 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 contain
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 wrote:
>
> Signed PGP part
> On Sep 9, 2021, at 1
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
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().
> >
>
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 jus
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 n
> 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
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
On Sep 9, 2021, at 08:53, Christopher Barker wrote:
>
> I fully admit serious bikeshedding here, but:
I think you meant “byte-shedding” :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@pytho
On 9/9/21 8:53 AM, Christopher Barker wrote:
> On 9/9/21 7:25 AM, Ethan Furman wrote:
>> I'm starting to think the name should be `bytes.bchr` -- it avoids any
confusion with the `int.to_bytes` and
>> `int.from_bytes` methods,
>
> are they so different? :-)
Yes, they are. Conceptually, one is
I fully admit serious bikeshedding here, but:
I'm starting to think the name should be `bytes.bchr` -- it avoids any
> confusion with the `int.to_bytes` and
> `int.from_bytes` methods,
are they so different? :-)
In [23]: x.to_bytes(1, 'little')
Out[23]: b'A'
In [27]: int.from_bytes(b'A', 'litt
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.
Tentatively,
Arnaud
PS. But truly I
On 9/9/21 1:55 AM, Nick Coghlan wrote:
> `bytes.fromint` is still the inverse of `ord` for bytes objects, even
> without the `bchr` builtin alias. The spelling of the trio is just
> `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact
> the method throws an exception for integers
Brandt Bucher wrote:
> You can even get creative and use the dedicated “pistol” operator…
Ah, wait, ignore this example. I got the chr and ord behavior flipped in my
head.
Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
On 9/9/21 3:49 AM, Steven D'Aprano wrote:
> We're Python programmers. To Python programmers, the int 20 is not a
> space character.
That's because int 32 is the space character. ;-)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To u
Steven D'Aprano wrote:
> TIL :-)
> How have I never noticed to_bytes until now? o_O
I’m going to go out on a limb here: because it’s rarely ever needed?
I mean, the proposed bchr() functionality is crazy simple to implement yourself
if you actually *do* need it. You can even get creative and use
On Thu, Sep 09, 2021 at 12:29:46AM +0100, Rob Cliffe via Python-Dev wrote:
> Why not byte() ?
Too easy to typo it as bytes().
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
On Wed, Sep 08, 2021 at 05:06:08PM -, Brandt Bucher wrote:
> Steven D'Aprano wrote:
> > To me, it sounds like should be the opposite of int.from_bytes.
> > >>> int.from_bytes(b'Hello world', 'little')
> > 121404708502361365413651784
> > >>> bytes.from_int(121404708502361365413651784, 'l
On Thu, Sep 09, 2021 at 10:57:26AM +0200, Victor Stinner wrote:
> I propose to rename PEP 467 method bytes.fromint(n) to =>
> bytes.fromchar(n) <= to convert an integer to a single *character*: it
> fails if n is not in the [0; 255] range. "char" comes from
> "character", as "bchr()" means "bytes
On Thu, 9 Sep 2021 12:06:49 +0200
Victor Stinner 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 a
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
On Thu, 9 Sep 2021 18:55:04 +1000
Nick Coghlan 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 mor
Hum, it seems like this is a confusion between converting a whole
bytes *string* to/from an integer, and converting a single *character*
to/from an integer.
I propose to rename PEP 467 method bytes.fromint(n) to =>
bytes.fromchar(n) <= to convert an integer to a single *character*: it
fails if n i
On Thu, 9 Sept 2021 at 01:46, Ethan Furman wrote:
>
> On 9/7/21 10:39 PM, Steven D'Aprano wrote:
> > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
> >
> >> I think Nick is on board with bytes.fromint() and no bchr(), and my
> >> sense of the sentiment here is that this would be
On 2021-09-09 00:29, Rob Cliffe via Python-Dev wrote:
On 08/09/2021 21:21, Christopher Barker wrote:
[snip]
NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the name.
[snip]
Why not byte() ?
I happened to need to convert an integer to a byte recen
On 08/09/2021 21:21, Christopher Barker wrote:
[snip]
NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the name.
[snip]
Why not byte() ?
I happened to need to convert an integer to a byte recently and I settled on
bytes((i,))
I don't know if I
On 9/8/21 1:21 PM, Christopher Barker wrote:
> NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the
> name. Equating a byte with a character is a legacy of C ( and Python 2” — in
Python 3, they
> are completely distinct concepts.
No, they aren't. If you
What am I missing?
The integers between 0 and 255 map directly to a particular byte value.
But any other integer could be expressed as a wide variety of multiple byte
combinations.
The proposal here covers byte-order, but what about 16 vs 32 vs 64 bits?
Unsigned vs signed?
I thought that’s what
> On 8 Sep 2021, at 06:39, Steven D'Aprano wrote:
>
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
>
>> I think Nick is on board with bytes.fromint() and no bchr(), and my
>> sense of the sentiment here is that this would be an acceptable
>> resolution for most folks. Ethan
Steven D'Aprano wrote:
> To me, it sounds like should be the opposite of int.from_bytes.
> >>> int.from_bytes(b'Hello world', 'little')
> 121404708502361365413651784
> >>> bytes.from_int(121404708502361365413651784, 'little')
> # should return b'Hello world'
> If that's not the API bein
On 2021-09-08 13:37, Victor Stinner wrote:
On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
>>> bytes.from_int(121404708502361365413651784, 'little')
# should return b'Hello world'
Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code
On 9/7/21 10:39 PM, Steven D'Aprano wrote:
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
>
>> I think Nick is on board with bytes.fromint() and no bchr(), and my
>> sense of the sentiment here is that this would be an acceptable
>> resolution for most folks. Ethan, can you recon
On Wed, Sep 8, 2021 at 10:42 PM Victor Stinner wrote:
>
> On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
> > >>> bytes.from_int(121404708502361365413651784, 'little')
> > # should return b'Hello world'
>
> Really? I don't know anyone serializing strings as a "bigint" number.
> Did
On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
> >>> bytes.from_int(121404708502361365413651784, 'little')
> # should return b'Hello world'
Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code pattern in the wild? Usually, bytes are
se
On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
> I think Nick is on board with bytes.fromint() and no bchr(), and my
> sense of the sentiment here is that this would be an acceptable
> resolution for most folks. Ethan, can you reconsider?
I haven't been completely keeping up wit
I’m finally getting back around to this thread. I’d like to see some
resolution to the bchr/fromint question, since it seems like that’s the last
thing holding up approval of the PEP. And the PEP has other useful additions
that I’d like to see in Python 3.11.
On Aug 22, 2021, at 16:08, Guido
On Sun, 22 Aug 2021 16:08:56 -0700
Guido van Rossum wrote:
> Hm, I don’t think the major use for bchr() will be with a constant.
What would be the major use for bchr()? I don't think I've ever
regretted its absence.
Regards
Antoine.
>
> On Sun, Aug 22, 2021 at 14:48 Gregory P. Smith wrote:
Hm, I don’t think the major use for bchr() will be with a constant.
On Sun, Aug 22, 2021 at 14:48 Gregory P. Smith wrote:
>
> On Tue, Aug 10, 2021 at 3:48 PM Christopher Barker
> wrote:
>
>> On Tue, Aug 10, 2021 at 3:00 PM wrote:
>>
>>> The history of bytes/bytearray is a dual-purpose view. I
On Tue, Aug 10, 2021 at 3:48 PM Christopher Barker
wrote:
> On Tue, Aug 10, 2021 at 3:00 PM wrote:
>
>> The history of bytes/bytearray is a dual-purpose view. It can be used in
>> a string-like way to emulate Python 2 string handling (hence all the usual
>> string methods and a repr that displa
Barry Warsaw wrote:
> On Aug 4, 2021, at 07:31, Victor Stinner vstin...@python.org wrote:
> > On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman et...@stoneleaf.us wrote:
> > I would rather keep `bchr` and lose the `.fromint()` methods.
> > I would prefer to only have a bytes.byte(65) method, no bchr()
>
On Tue, Aug 10, 2021 at 3:00 PM wrote:
> The history of bytes/bytearray is a dual-purpose view. It can be used in
> a string-like way to emulate Python 2 string handling (hence all the usual
> string methods and a repr that displays in a string-like fashion). It can
> also be used as an array o
I recommend removing the "discouragement" from writing "bytes(10)". That is
merely stylistic. As long as we support the API, it is valid Python. In the
contexts where it is currently used, it tends to be clear about what it is
doing: buffer = bytearray(bufsize). That doesn't need to be disco
On Fri, Aug 6, 2021 at 12:23 PM Stephen J. Turnbull
wrote:
> As a builtin, not my problem, I'm not the proponent. As a facility
> with *some* spelling, it's convenient in contexts where chr() is, but
> much less so (eg, coding ROT13 ;-). I know I've used this translation
> in mail hacking, but I
Antoine Pitrou writes:
> In what context is `bchr()` useful?
As a builtin, not my problem, I'm not the proponent. As a facility
with *some* spelling, it's convenient in contexts where chr() is, but
much less so (eg, coding ROT13 ;-). I know I've used this translation
in mail hacking, but I don
On Fri, 6 Aug 2021 01:37:48 +0900
"Stephen J. Turnbull" wrote:
> Christopher Barker writes:
>
> > A byte is not a character
>
> While I am -0.5 on bchr for many of the reasons already cited in the
> thread (and would be -1 if the methods names proposed for the feature
> were a bit more aesthe
Christopher Barker writes:
> A byte is not a character
While I am -0.5 on bchr for many of the reasons already cited in the
thread (and would be -1 if the methods names proposed for the feature
were a bit more aesthetic), I don't think this argument is valid.
Bytes that could otherwise be arbitr
I see in the PEP:
"the bchr builtin is to recreate the ord/chr/unichr trio from Python 2
under a different naming scheme"
Why recreate that trio? Shouldn't we be moving away from the
bytes-is-a-string concept here?
A byte is not a character -- why would the function that creates a byte
from an i
On Aug 4, 2021, at 07:31, Victor Stinner wrote:
>
> On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman wrote:
>> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> I would prefer to only have a bytes.byte(65) method, no bchr()
> built-in function. I would prefer to keep builtins namespa
On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman wrote:
> I would rather keep `bchr` and lose the `.fromint()` methods.
I would prefer to only have a bytes.byte(65) method, no bchr()
built-in function. I would prefer to keep builtins namespace as small
as possible.
bytes.byte() name is similar to byt
On 8/3/21 1:19 PM, Barry Warsaw wrote:
> Can you provide some rationale for why you prefer bchr() over .fromint()?
- `bchr` directly corresponds with `chr`
- `str` has no `fromint`
- `bytearray(bchr(int))` is roughly the same as `bytearray.fromint(int)`, but
`bchr(int)` for a bytes object is
Thanks for responding Ethan.
> On Aug 3, 2021, at 10:48, Ethan Furman wrote:
>
> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> To get bytes:
>
> some_var = bchr(65)
> vs
> some_var = bytes.fromint(65)
>
> and for bytearrays
>
> some_var = bytearray(bchr(65))
> vs
> so
On 7/29/21 3:46 PM, Barry Warsaw wrote:
> We’re generally very favorable for adding to Python 3.11 the features and
APIs described
> in the PEP. We have some requests for changes that we’d like you to consider.
>
> * The Python-Version in the PEP needs to target Python 3.11 of course.
Done.
>
Thanks Nick. Ethan, what do you think?
-Barry
> On Jul 29, 2021, at 16:28, Nick Coghlan wrote:
>
>
>
> On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
> binary sequences at our 2021-07
On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
> binary sequences at our 2021-07-26 meeting.
>
> Thank you for work on this PEP. We’re generally very favorable for adding
> to Python 3.11 the
59 matches
Mail list logo
