[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
I've had about 5 or 6 of them. Paul On Thu, 4 Nov 2021 at 19:22, Brett Cannon wrote: > > What notification? (I fully admit I may not have gotten one due to some team > I'm in, but I have no such notification if it happened recently.) > > On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: >> >> >> I guess this is part of the migration from bpo to GitHub issues? Maybe the >> initial work could be done in a private repo, to cut down on the spurious >> email notifications to literally everybody subscribed to cpython? Which is >> a lot of people. >> >> >> /arry >> >> ___ >> 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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > 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/OJYGOHGS27CUY7KWHE5PEC2CKYH6M5PI/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/JGPFO6R4AUDTF7LG6SSFDC6Y6GRTA66S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
I was looking into migrating twisted trac to github, and contacted GitHub support who told me there's a secret API that doesn't notify subscribers https://gist.github.com/jonmagic/5282384165e0f86ef105 On Thu, 4 Nov 2021, 19:28 Brett Cannon, wrote: > What notification? (I fully admit I may not have gotten one due to some > team I'm in, but I have no such notification if it happened recently.) > > On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: > >> >> I guess this is part of the migration from bpo to GitHub issues? Maybe >> the initial work could be done in a private repo, to cut down on the >> spurious email notifications to literally everybody subscribed to cpython? >> Which is a lot of people. >> >> >> */arry* >> ___ >> 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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > 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/OJYGOHGS27CUY7KWHE5PEC2CKYH6M5PI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/X5OWAZZRM6ZL2O6U4V7Q6EXBLG4NTJUT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
On 11/4/21 12:21 PM, Brett Cannon wrote: > What notification? (I fully admit I may not have gotten one due to some team I'm in, but I have > no such notification if it happened recently.) I've received 20-30 in the last three or four days. I'm not concerned about it, just providing a data point. -- ~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/LFF2AQPBXJPVNFDBTW6ZVSIO55AYOHVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
What notification? (I fully admit I may not have gotten one due to some team I'm in, but I have no such notification if it happened recently.) On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: > > I guess this is part of the migration from bpo to GitHub issues? Maybe > the initial work could be done in a private repo, to cut down on the > spurious email notifications to literally everybody subscribed to cpython? > Which is a lot of people. > > > */arry* > ___ > 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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/OJYGOHGS27CUY7KWHE5PEC2CKYH6M5PI/ 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/
[Python-Dev] Oh look, I've been subscribed to python/issues-test-2 notifications again
I guess this is part of the migration from bpo to GitHub issues? Maybe the initial work could be done in a private repo, to cut down on the spurious email notifications to literally everybody subscribed to cpython? Which is a lot of people. //arry/ ___ 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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 467: Minor bytes and bytearray improvements
The final PEP with SC feedback incorporated and one last addition: `bytes.ascii` as a replacement for the Python 2 idiom
of `str(some_var)` to get the bytes version, and the Python 3 workaround of either the correct
`str(some_var).encode('astii') or the potentially wrong `ascii(some_var).encode('ascii').
The rendered version is at https://www.python.org/dev/peps/pep-0467/
Happy reading!
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan , Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2014
Python-Version: 3.11
Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13
2021-11-03
Abstract
This PEP proposes five small adjustments to the APIs of the ``bytes`` and
``bytearray`` types to make it easier to operate entirely in the binary domain:
* Add ``fromsize`` alternative constructor
* Add ``fromint`` alternative constructor
* Add ``ascii`` alternative constructor
* Add ``getbyte`` byte retrieval method
* Add ``iterbytes`` alternative iterator
Rationale
=
During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series, for example with PEP 461.
Motivation
==
With Python 3 and the split between ``str`` and ``bytes``, one small but
important area of programming became slightly more difficult, and much more
painful -- wire format protocols.
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text). The addition of
the new constructors, methods, and iterators will aid both in writing new
wire format code, and in porting any remaining Python 2 wire format code.
Common use-cases include ``dbf`` and ``pdf`` file formats, ``email``
formats, and ``FTP`` and ``HTTP`` communications, among many others.
Proposals
=
Addition of explicit "count and byte initialised sequence" constructors
---
To replace the now discouraged behavior, this PEP proposes the addition of an
explicit ``fromsize`` alternative constructor as a class method on both
``bytes`` and ``bytearray`` whose first argument is the count, and whose
second argument is the fill byte to use (defaults to ``\x00``)::
>>> bytes.fromsize(3)
b'\x00\x00\x00'
>>> bytearray.fromsize(3)
bytearray(b'\x00\x00\x00')
>>> bytes.fromsize(5, b'\x0a')
b'\x0a\x0a\x0a\x0a\x0a'
>>> bytearray.fromsize(5, fill=b'\x0a')
bytearray(b'\x0a\x0a\x0a\x0a\x0a')
``fromsize`` will behave just as the current constructors behave when passed a
single integer, while allowing for non-zero fill values when needed.
Addition of explicit "single byte" constructors
---
As binary counterparts to the text ``chr`` function, this PEP proposes
the addition of an explicit ``fromint`` alternative constructor as a class
method on both ``bytes`` and ``bytearray``::
>>> bytes.fromint(65)
b'A'
>>> bytearray.fromint(65)
bytearray(b'A')
These methods will only accept integers in the range 0 to 255 (inclusive)::
>>> bytes.fromint(512)
Traceback (most recent call last):
File "", line 1, in
ValueError: integer must be in range(0, 256)
>>> bytes.fromint(1.0)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'float' object cannot be interpreted as an integer
The documentation of the ``ord`` builtin will be updated to explicitly note
that ``bytes.fromint`` is the primary inverse operation for binary data, while
``chr`` is the inverse operation for text data, and that ``bytearray.fromint``
also exists.
Behaviorally, ``bytes.fromint(x)`` will be equivalent to the current
``bytes([x])`` (and similarly for ``bytearray``). The new spelling is
expected to be easier to discover and easier to read (especially when used
in conjunction with indexing operations on binary sequence types).
As a separate method, the new spelling will also work better with higher
order functions like ``map``.
These new methods intentionally do NOT offer the same level of general integer
support as the existing ``int.to_bytes`` conversion method, which allows
arbitrarily large integers to be converted to arbitrarily long bytes objects.
The
restriction to only accept positive integers that fit in a single byte means
that no byte order information is needed, and there is no need to handle
negative numbers. The documentation of the new methods will refer readers to
``int.to_bytes`` for use cases where handling of arbitrary integers is needed.
Addition of "ascii" constructors
In Python 2 converting
