On Thu, Dec 9, 2010 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 9 Dec 2010 13:55:08 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum gu...@python.org wrote:
..
string-string transforms use the same namespace
On Mon, Dec 6, 2010 at 3:39 AM, M.-A. Lemburg m...@egenix.com wrote:
Guido van Rossum wrote:
The moratorium is intended to freeze the state of the language as
implemented, not whatever was discussed and approved but didn't get
implemented (that'd be a hole big enough to drive a truck through,
On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum gu...@python.org wrote:
..
string-string transforms use the same namespace even though the
typical transform only supports one or the other. E.g. IMO all of the
following should raise LookupError:
b'abc'.transform('rot13')
Traceback (most
On Thu, 9 Dec 2010 13:55:08 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum gu...@python.org wrote:
..
string-string transforms use the same namespace even though the
typical transform only supports one or the other. E.g. IMO
Le 09/12/2010 19:42, Guido van Rossum a écrit :
Given that it's in 3.2b1 I'm okay with keeping it. That's at best a
+0. [...]
though I still don't like that the registries for transforms and
codecs use the same namespace. Also bytes-bytes and
string-string transforms use the same namespace
On Thu, Dec 9, 2010 at 2:17 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 9 Dec 2010 13:55:08 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
..
This is actually *very* misleading because
'abc'.transform('rot13')
'nop'
works even though 'abc' is not an object with
Guido van Rossum wrote:
On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray rdmur...@bitdance.com
wrote:
..
Please also
On Dec 3, 2010, at 10:05 AM, Guido van Rossum wrote:
Regardless of what I or others may have said before, I am not
currently a fan of adding transform() to either str or bytes.
Just to clarify, is your preference to go back to the Python 2.x way
and use encode()/decode() for both unicode
FWIW, transform()/untransform() are already in the 3.2 beta.
Do you want them taken out? If so, do you want the codecs
made accessible with encode/decode or have them continue
to be inaccessible in 3.x?
Notice that they wouldn't be inaccessible even if transform
is taken out again:
On Sun, Dec 5, 2010 at 5:25 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
On Saturday 04 December 2010 09:31:04 you wrote:
Alexander Belopolsky writes:
In fact, once the language moratorium is over, I will argue that
str.encode() and byte.decode() should deprecate encoding
On Tue, Dec 7, 2010 at 12:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Dec 7, 2010 at 2:46 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Having all encodings accessible in a str method only promotes a
programming style where bytes objects can contain differently
On Saturday 04 December 2010 09:31:04 you wrote:
Alexander Belopolsky writes:
In fact, once the language moratorium is over, I will argue that
str.encode() and byte.decode() should deprecate encoding argument and
just do UTF-8 encoding/decoding. Hopefully by that time most people
On Mon, Dec 6, 2010 at 8:25 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Not only, many libraries expect use bytes arguments encoded to a specific
encoding (eg. locale encoding). Said differenlty, only few libraries written
in
C accept wchar* strings.
The Linux kernel (or many, or
Alexander Belopolsky writes:
In fact, once the language moratorium is over, I will argue that
str.encode() and byte.decode() should deprecate encoding argument and
just do UTF-8 encoding/decoding. Hopefully by that time most people
will forget that other encodings exist. (I can dream,
On Thursday 02 December 2010 19:06:51 georg.brandl wrote:
Author: georg.brandl
Date: Thu Dec 2 19:06:51 2010
New Revision: 86934
Log:
#7475: add (un)transform method to bytes/bytearray and str, add back codecs
that can be used with them from Python 2.
Oh no, someone did it. Was it really
On Fri, 03 Dec 2010 10:16:04 +0100, Victor Stinner
victor.stin...@haypocalc.com wrote:
On Thursday 02 December 2010 19:06:51 georg.brandl wrote:
Author: georg.brandl
Date: Thu Dec 2 19:06:51 2010
New Revision: 86934
Log:
#7475: add (un)transform method to bytes/bytearray and str,
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray rdmur...@bitdance.com wrote:
..
Please also recall that transform/untransform was discussed before
the release of Python 3.0 and was approved at the time, but it just
did not get implemented before the 3.0 release.
Can you provide a link? My
On Friday 03 December 2010 16:11:29 R. David Murray wrote:
'abc'.transform('hex')
TypeError: 'str' does not support the buffer interface
b'abc'.transform('rot13')
TypeError: expected an object with the buffer interface
I find these 'buffer interface' error messages to be the most
On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray rdmur...@bitdance.com
wrote:
..
Please also recall that transform/untransform was discussed before
the release of Python 3.0 and was approved at
On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray rdmur...@bitdance.com
wrote:
..
Please also recall that
On Fri, Dec 3, 2010 at 4:16 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
..
I don't like transform() and untransform() because I think that we should not
add too much operations to the base types (bytes and str), and they do
implicit module import. I prefer explicit module import (eg.
21 matches
Mail list logo
