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
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 Wed, Sep 8, 2021 at 12:49 PM Yury Selivanov wrote:
> We have already merged it, the fix is part of the rc2.
>
Thanks! (If we were on Discourse I would have left a ♥ instead )
>
> yury
>
>
> On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote:
>
>> On Thu, Sep 2, 2021 at 7:43 PM Yury
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
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
We have already merged it, the fix is part of the rc2.
yury
On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote:
> On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov
> wrote:
>
>> Comments inlined:
>>
>> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote:
>>
>>> First of all, we should ping
On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov
wrote:
> Comments inlined:
>
> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote:
>
>> First of all, we should ping Yury, who implemented `async for` about 6
>> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and
>> anext()
> 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.
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
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
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
Thanks Serhiy,
I've made the few additional changes you noted in the PR. I took out my
attempt with path_t. However, here is why I think argument clinic (or
something else?!) is actually intercepting the attempted call:
With my temporary debugging, I have this function in
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
Hi Serhiy,
For me, "deprecated" should be used if the removal is *not* planned:
the feature is too popular, and removing it would break too much 3rd
party code.
"deprecated-removal" should be used if the feature removal *is*
planned. IMO it's ok if we forget to remove the feature and keep it
I always thought that the "deprecated" directive is used if the term of
removing the deprecated feature is not set yet, and the
"deprecated-removed" directive is used if it is set. After removing the
feature both directives are replaced with the "versionchanged" directive
which only specifies the
08.09.21 08:19, David Mertz, Ph.D. пише:
> I attempted to do this today, as my first actual contribution to CPython
> itself. I think the prior attempt went down a wrong path, which is why
> neither PR could actually pass tests.
>
> I've been looking at `posixmodule.c` for comparison,
17 matches
Mail list logo
