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 15:34, Nick Coghlan ncogh...@gmail.com wrote:
On 17 August 2014 15:08, Guido van Rossum gu...@python.org wrote:
I think this would be a great topic for a blog post. Once you've written it
I can even bless it by Tweeting about it. :-)
Sounds like a plan - I'll try to put
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
This change is okay and not harmful. But I think, It might still not fix
the encoding issue that we encountered on Mac.
[localhost cpython]$ hg log -l 1
changeset: 92128:7cdc941d5180
tag: tip
parent: 92126:3153a400b739
parent: 92127:a894b629bbea
user:Serhiy Storchaka
On 08/17/2014 03:28 AM, Nick Coghlan wrote:
I've seen a few people on python-ideas express the assumption that
there will be another Py3k style compatibility break for Python 4.0.
I've also had people express the concern that you broke compatibility
in a major way once, how do we know you won't
On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
(Don't understand this to mean that we should never deprecate things.
Deprecations will happen, they are necessary for the evolution of any
programming language. But they won't ever hurt in the way that Python 3
hurt.)
It would be useful to
Currently most functions which accepts string argument which then passed
to C function as NUL-terminated string, reject strings with embedded NUL
character and raise TypeError. ValueError looks more appropriate here,
because argument type is correct (str), only its value is wrong. But
this is
Sounds good to me.
On Sun, Aug 17, 2014 at 7:47 AM, Serhiy Storchaka storch...@gmail.com
wrote:
Currently most functions which accepts string argument which then passed
to C function as NUL-terminated string, reject strings with embedded NUL
character and raise TypeError. ValueError looks
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 12:17 PM, Donald Stufft don...@stufft.io wrote:
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 wrote:
If I see bytearray(10) there is nothing there that suggests this
creates an
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
I think the biggest API problem is that default iteration returns integers
instead of bytes. That's a real pain.
I'm not sure .iterbytes() is the best name for spelling iteration over bytes
instead of integers though. Given that we can't change __iter__(), I
personally would perhaps prefer a
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
On Sun, Aug 17, 2014 at 05:41:10PM -0400, Barry Warsaw wrote:
I think the biggest API problem is that default iteration returns integers
instead of bytes. That's a real pain.
I agree, this behavior required some helper functions while porting Werkzeug to
Python 3 AFAIK.
I'm not sure
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 08:04, Markus Unterwaditzer mar...@unterwaditzer.net
wrote:
On Sun, Aug 17, 2014 at 05:41:10PM -0400, Barry Warsaw wrote:
I think the biggest API problem is that default iteration returns
integers
instead of bytes. That's a real pain.
I agree, this behavior required some
On Aug 18, 2014, at 08:48 AM, Nick Coghlan wrote:
Calling it bytes is too confusing:
for x in bytes(data):
...
for x in bytes(data).bytes()
When referring to bytes, which bytes do you mean, the builtin or the method?
iterbytes() isn't especially attractive as a method name, but
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
On 18 Aug 2014 08:55, Barry Warsaw ba...@python.org wrote:
On Aug 18, 2014, at 08:48 AM, Nick Coghlan wrote:
Calling it bytes is too confusing:
for x in bytes(data):
...
for x in bytes(data).bytes()
When referring to bytes, which bytes do you mean, the builtin or the
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
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
I'm talking more generally - do you *really* want to be explaining that
bytes behaves like a tuple of integers, while bytes.bytes behaves like
a tuple of bytes?
I would explain it differently though, using concrete examples.
data =
On 18 Aug 2014 09:57, Barry Warsaw ba...@python.org wrote:
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
I'm talking more generally - do you *really* want to be explaining that
bytes behaves like a tuple of integers, while bytes.bytes behaves
like
a tuple of bytes?
I would explain it
On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
There's actually another aspect to your idea, independent of the naming:
exposing a view rather than just an iterator. I'm going to have to look at
the implications for memoryview, but it may be a good way to go (and would
align with the iterator
On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw ba...@python.org wrote:
On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
There's actually another aspect to your idea, independent of the naming:
exposing a view rather than just an iterator. I'm going to have to look at
the implications for
On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw ba...@python.org wrote:
On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
(Don't understand this to mean that we should never deprecate things.
Deprecations will happen, they are necessary for the evolution of any
programming language. But
On Sun, Aug 17, 2014, at 09:02 PM, Guido van Rossum wrote:
On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw ba...@python.org wrote:
On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
(Don't understand this to mean that we should never deprecate things.
Deprecations will happen, they are
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'.
Le 17/08/2014 20:08, Nick Coghlan a écrit :
On 18 Aug 2014 09:57, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
I'm talking more generally - do you *really* want to be explaining that
bytes behaves like a tuple of
from __future__ import bytesdoneright? :D
--
Donald Stufft
don...@stufft.io
On Sun, Aug 17, 2014, at 09:40 PM, Antoine Pitrou wrote:
Le 17/08/2014 20:08, Nick Coghlan a écrit :
On 18 Aug 2014 09:57, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Aug 18, 2014,
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 08/17/2014 09:40 PM, Antoine Pitrou wrote:
Le 17/08/2014 20:08, Nick Coghlan a écrit :
On 18 Aug 2014 09:57, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
I'm talking more generally - do you *really* want to be
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
39 matches
Mail list logo
