On 06/07/2016 02:34 PM, Koos Zevenhoven wrote:
Why not bytes.viewbytes (or whatever name) so that one could also
subscript it? And if it were a property, one could perhaps
conveniently get the n'th byte:
b'abcde'.viewbytes[n] # compared to b'abcde'[n:n+1]
AFAICT, 'viewbytes' doesn't add
On 06/07/2016 10:42 PM, Serhiy Storchaka wrote:
On 07.06.16 23:28, Ethan Furman wrote:
* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
``memoryview.iterbytes`` alternative iterators
"Byte" is an alias to "octet" (8-bit integer) in modern terminology.
Maybe so, but not, to my
On 9 June 2016 at 19:21, Barry Warsaw wrote:
> On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>
>>Deprecation of current "zero-initialised sequence" behaviour
>>
>>
>>Currently, the ``bytes`` and ``bytearray``
On Jun 8, 2016 8:13 AM, "Paul Sokolovsky" wrote:
>
> Hello,
>
> On Wed, 8 Jun 2016 14:45:22 +0300
> Serhiy Storchaka wrote:
>
> []
>
> > > $ ./run-bench-tests bench/bytealloc*
> > > bench/bytealloc:
> > > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py
On Wed, Jun 08, 2016 at 10:04:08AM +0200, Victor Stinner wrote:
> It's common that users complain that Python core developers like
> breaking the compatibility at each release.
No more common as users complaining that Python features are badly
designed and crufty and should be fixed.
Whatever
On Jun 08, 2016, at 02:01 AM, Martin Panter wrote:
>Bytes.byte() is a great idea. But what’s the point or use case of
>bytearray.byte(), a mutable array of one pre-defined byte?
I like Bytes.byte() too. I would guess you'd want the same method on
bytearray for duck typing APIs.
-Barry
Hello,
On Wed, 8 Jun 2016 14:45:22 +0300
Serhiy Storchaka wrote:
[]
> > $ ./run-bench-tests bench/bytealloc*
> > bench/bytealloc:
> > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py
> > 11.244s (+237.35%) bench/bytealloc-2-repeat.py
>
> If the performance of
On 08.06.16 14:26, Paul Sokolovsky wrote:
On Wed, 8 Jun 2016 14:05:19 +0300
Serhiy Storchaka wrote:
On 08.06.16 13:37, Paul Sokolovsky wrote:
The obvious way to create the bytes object of length n is b'\0' *
n.
That's very inefficient: it requires allocating useless
Hello,
On Wed, 8 Jun 2016 14:05:19 +0300
Serhiy Storchaka wrote:
> On 08.06.16 13:37, Paul Sokolovsky wrote:
> >> The obvious way to create the bytes object of length n is b'\0' *
> >> n.
> >
> > That's very inefficient: it requires allocating useless b'\0', then
> > a
On 08.06.16 13:37, Paul Sokolovsky wrote:
The obvious way to create the bytes object of length n is b'\0' * n.
That's very inefficient: it requires allocating useless b'\0', then a
generic function to repeat arbitrary memory block N times. If there's a
talk of Python to not be laughed at for
Hello,
On Wed, 8 Jun 2016 11:53:06 +0300
Serhiy Storchaka wrote:
> On 08.06.16 11:04, Victor Stinner wrote:
> >> Currently, the ``bytes`` and ``bytearray`` constructors accept an
> >> integer argument and interpret it as meaning to create a
> >> zero-initialised sequence of
On 08.06.16 02:03, Nick Coghlan wrote:
That said, it occurs to me that there's a reasonably strong
composability argument in favour of a view-based approach: a view will
work with operator.itemgetter() and other sequence consuming APIs,
while special methods won't. The "like-memoryview-but-not"
On 08.06.16 11:04, Victor Stinner wrote:
Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
argument and interpret it as meaning to create a zero-initialised sequence
of the given size::
(...)
This PEP proposes to deprecate that behaviour in Python 3.6, and remove it
Hi,
> Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
> argument and interpret it as meaning to create a zero-initialised sequence
> of the given size::
> (...)
> This PEP proposes to deprecate that behaviour in Python 3.6, and remove it
> entirely in Python 3.7.
I'm
Ethan Furman writes:
> * Deprecate passing single integer values to ``bytes`` and
> ``bytearray``
Why? This is a slightly awkward idiom compared to .zeros (EITBI etc),
but your 32-bit clock will roll over before we can actually remove it.
There are a lot of languages that do this kind of
On 07.06.16 23:28, Ethan Furman wrote:
Minor changes: updated version numbers, add punctuation.
The current text seems to take into account Guido's last comments.
Thoughts before asking for acceptance?
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
On 7 June 2016 at 21:56, Nick Coghlan wrote:
> On 7 June 2016 at 14:33, Paul Sokolovsky wrote:
>> Ethan Furman wrote:
>>> Deprecation of current "zero-initialised sequence" behaviour
>>>
On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 07 Jun 2016 15:46:00 -0700
> Ethan Furman wrote:
>
> > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote:
> >
> > >> This PEP proposes to deprecate that behaviour in Python 3.6, and
> > >>
Hello,
On Tue, 07 Jun 2016 15:46:00 -0700
Ethan Furman wrote:
> On 06/07/2016 02:33 PM, Paul Sokolovsky wrote:
>
> >> This PEP proposes to deprecate that behaviour in Python 3.6, and
> >> remove it entirely in Python 3.7.
> >
> > Why the desire to break applications of
On 7 June 2016 at 15:22, Koos Zevenhoven wrote:
> On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote:
>> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:
>>
>>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:
What's wrong with
On 06/07/2016 02:33 PM, Paul Sokolovsky wrote:
This PEP proposes to deprecate that behaviour in Python 3.6, and
remove it entirely in Python 3.7.
Why the desire to break applications of thousands and thousands of
people? Besides, bytes(3) behavior is very logical. Everyone who knows
what
On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote:
> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:
>
>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:
>>> What's wrong with b[i:i+1] ?
>>It always succeeds while indexing can trigger an IndexError.
>
>
On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:
>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:
>> What's wrong with b[i:i+1] ?
>It always succeeds while indexing can trigger an IndexError.
Right. You want a method with the semantics of __getitem__() but that returns
t;ba...@python.org>
> Cc: python-dev@python.org
> Subject: RE: [Python-Dev] PEP 467: Minor API improvements to bytes,
> bytearray, and memoryview
>
>
>
> > -Original Message-
> > From: Python-Dev [mailto:python-dev-bounces+tritium-
> > list=sdamon@
On 7 June 2016 at 14:33, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 07 Jun 2016 13:28:13 -0700
> Ethan Furman wrote:
>
>> Minor changes: updated version numbers, add punctuation.
>>
>> The current text seems to take into account Guido's last comments.
>>
> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Nick Coghlan
> Sent: Tuesday, June 7, 2016 5:40 PM
> To: Barry Warsaw <ba...@python.org>
> Cc: python-dev@python.org
> Subject: Re: [Pyt
On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 7 Jun 2016 17:31:19 -0400
> Barry Warsaw wrote:
>
> > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
> >
> > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
> > >
On 7 June 2016 at 14:31, Barry Warsaw wrote:
> On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>
>>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
>> ``memoryview.iterbytes`` alternative iterators
>
> +1 but I want to go just a little farther.
>
> We can't change
Hello,
On Tue, 7 Jun 2016 17:31:19 -0400
Barry Warsaw wrote:
> On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>
> >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
> > ``memoryview.iterbytes`` alternative iterators
>
> +1 but I want to go just a little farther.
>
On Tue, Jun 7, 2016 at 11:28 PM, Ethan Furman wrote:
>
> Minor changes: updated version numbers, add punctuation.
>
> The current text seems to take into account Guido's last comments.
>
> Thoughts before asking for acceptance?
>
> PEP: 467
> Title: Minor API improvements for
On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
> ``memoryview.iterbytes`` alternative iterators
+1 but I want to go just a little farther.
We can't change bytes.__getitem__ but we can add another method that returns
single byte
Minor changes: updated version numbers, add punctuation.
The current text seems to take into account Guido's last comments.
Thoughts before asking for acceptance?
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan
On Aug 17, 2014, at 09:39 PM, Antoine Pitrou wrote:
need for a special case for a single byte. We already have a perfectly
good spelling:
NUL = bytes([0])
That is actually a very cumbersome spelling. Why should I first create a
one-element list in order to create a one-byte bytes object?
On Aug 14, 2014, at 10:50 PM, Nick Coghlan ncogh...@gmail.com wrote:
Key points in the proposal:
* deprecate passing integers to bytes() and bytearray()
I'm opposed to removing this part of the API. It has proven useful
and the alternative isn't very nice. Declaring the size of fixed
On 17 August 2014 18:13, Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Aug 14, 2014, at 10:50 PM, Nick Coghlan ncogh...@gmail.com wrote:
Key points in the proposal:
* deprecate passing integers to bytes() and bytearray()
I'm opposed to removing this part of the API. It has
On Aug 17, 2014, at 1:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
If I see bytearray(10) there is nothing there that suggests this
creates an array of length 10 and initialises it to zero to me. I'd
be more inclined to guess it would be equivalent to bytearray([10]).
bytearray.zeros(10),
On Aug 17, 2014, at 1:07 PM, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Aug 17, 2014, at 1:41 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
If I see bytearray(10) there is nothing there that suggests this
creates an array of length 10 and
On 08/17/2014 10:16 AM, Donald Stufft wrote:
For the record I’ve had all of the problems that Nick states and I’m
+1 on this change.
I've had many of the problems Nick states and I'm also +1.
--
~Ethan~
___
Python-Dev mailing list
On Aug 17, 2014, at 11:33 AM, Ethan Furman et...@stoneleaf.us wrote:
I've had many of the problems Nick states and I'm also +1.
There are two code snippets below which were taken from the standard library.
Are you saying that:
1) you don't understand the code (as the pep suggests)
2) you are
On Aug 17, 2014, at 5:19 PM, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Aug 17, 2014, at 11:33 AM, Ethan Furman et...@stoneleaf.us
mailto:et...@stoneleaf.us wrote:
I've had many of the problems Nick states and I'm also +1.
There are two code snippets below which were
Le 17/08/2014 13:07, Raymond Hettinger a écrit :
FWIW, I've been teaching Python full time for three years. I cover the
use of bytearray(n) in my classes and not a single person out of 3000+
engineers have had a problem with it.
This is less about bytearray() than bytes(), IMO. bytearray()
On 18 Aug 2014 03:07, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Aug 17, 2014, at 1:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
If I see bytearray(10) there is nothing there that suggests this
creates an array of length 10 and initialises it to zero to me. I'd
be more
Le 16/08/2014 01:17, Nick Coghlan a écrit :
* Deprecate passing single integer values to ``bytes`` and ``bytearray``
I'm neutral. Ideally we wouldn't have done that mistake at the beginning.
* Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors
* Add ``bytes.byte`` and
On Aug 17, 2014, at 4:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
Purely deprecating the bytes case and leaving bytearray alone would likely
address my concerns.
That is good progress. Thanks :-)
Would a warning for the bytes case suffice, do you need an actual deprecation?
On 18 Aug 2014 09:41, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
I encourage restraint against adding an unneeded class method that has no
parallel
elsewhere. Right now, the learning curve is mitigated because bytes is
very str-like
and because bytearray is list-like (i.e. the
Le 17/08/2014 19:41, Raymond Hettinger a écrit :
The APIs have been around since 2.6 and AFAICT there have been zero
demonstrated
need for a special case for a single byte. We already have a perfectly
good spelling:
NUL = bytes([0])
That is actually a very cumbersome spelling. Why
On 08/17/2014 02:19 PM, Raymond Hettinger wrote:
On Aug 17, 2014, at 11:33 AM, Ethan Furman wrote:
I've had many of the problems Nick states and I'm also +1.
There are two code snippets below which were taken from the standard library.
[...]
My issues are with 'bytes', not 'bytearray'.
On 08/17/2014 04:08 PM, Nick Coghlan wrote:
I'm fine with postponing the deprecation elements indefinitely (or just
deprecating bytes(int) and leaving
bytearray(int) alone).
+1 on both pieces.
--
~Ethan~
___
Python-Dev mailing list
On Sun, Aug 17, 2014 at 8:52 PM, Ethan Furman et...@stoneleaf.us wrote:
On 08/17/2014 04:08 PM, Nick Coghlan wrote:
I'm fine with postponing the deprecation elements indefinitely (or just
deprecating bytes(int) and leaving
bytearray(int) alone).
+1 on both pieces.
Perhaps postpone the
Donald Stufft donald at stufft.io writes:
For the record I’ve had all of the problems that Nick states and I’m
+1 on this change.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
I've hit basically every problem everyone here has stated, and in no
On Sun, Aug 17, 2014 at 7:14 PM, Alex Gaynor alex.gay...@gmail.com wrote:
I've hit basically every problem everyone here has stated, and in no uncertain
terms am I completely opposed to deprecating anything. The Python 2 to 3
migration is already hard enough, and already proceeding far too
This feels chatty. I'd like the PEP to call out the specific proposals and
put the more verbose motivation later. It took me a long time to realize
that you don't want to deprecate bytes([1, 2, 3]), but only bytes(3). Also
your mention of bytes.byte() as the counterpart to ord() confused me -- I
15.08.14 08:50, Nick Coghlan написав(ла):
* add bytes.zeros() and bytearray.zeros() as a replacement
b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need
to learn new method. And it works right now.
* add bytes.iterbytes(), bytearray.iterbytes() and
2014-08-15 21:54 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
15.08.14 08:50, Nick Coghlan написав(ла):
* add bytes.zeros() and bytearray.zeros() as a replacement
b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need to
learn new method. And it works right now.
FYI
2014-08-15 7:50 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
As far as I am aware, that last item poses the only open question,
with the alternative being to add an iterbytes builtin (...)
Do you have examples of use cases for a builtin function? I only found
5 usages of bytes((byte,))
On 16 August 2014 03:48, Guido van Rossum gu...@python.org wrote:
This feels chatty. I'd like the PEP to call out the specific proposals and
put the more verbose motivation later.
I realised that some of that history was actually completely
irrelevant now, so I culled a fair bit of it entirely.
I just posted an updated version of PEP 467 after recently finishing
the updates to the Python 3.4+ binary sequence docs to decouple them
from the str docs.
Key points in the proposal:
* deprecate passing integers to bytes() and bytearray()
* add bytes.zeros() and bytearray.zeros() as a
57 matches
Mail list logo