is python 3 better than python 2?

[neil]

what are the advantages? if it wasn't for python 3 breaking backwards
compatibility would it be the better choice?

 

[Mel]

what are the advantages? if it wasn't for python 3 breaking backwards
compatibility would it be the better choice?

IMHO the killer app for Python 3 is in more reasonable support for
foreign character sets (no matter where your are, at least one out of
the hundred-odd Unicode character sets is going to be foreign,) and
generally internationalized data processing.

Mel.

 

[Gnarlodious]

what are the advantages? if it wasn't for python 3 breaking backwards
compatibility would it be the better choice?

I adopted Py3 because of support of OrderedDict and many new features.
Since mine was a new project using no existing libraries, it made
sense.

-- Gnarlie

 

[John Nagle]

IMHO the killer app for Python 3 is in more reasonable support for
foreign character sets (no matter where your are, at least one out of
the hundred-odd Unicode character sets is going to be foreign,) and
generally internationalized data processing.

Well, actually Unicode support went in back around Python 2.4.
In 3.x, ASCII strings went away, but that was more of a removal.

John Nagle

 

[Terry Reedy]

Well, actually Unicode support went in back around Python 2.4.

Even earlier, I think, but there were and still are problems with
unicode in 2.x. Some were and will only be fixed in 3.x.

In 3.x, ASCII strings went away, but that was more of a removal.

Yes and no. They were kept slightly modified as bytes, with all of the
string methods kept.

 

[MRAB]

On Tue, Apr 5, 2011 at 10:04 PM, Terry Reedy <[email protected]

On 4/5/2011 4:42 PM, John Nagle wrote:

Well, actually Unicode support went in back around Python 2.4.


Even earlier, I think, but there were and still are problems with
unicode in 2.x. Some were and will only be fixed in 3.x.


In 3.x, ASCII strings went away, but that was more of a removal.


Yes and no. They were kept slightly modified as bytes, with all of
the string methods kept.


I suspect not all string methods were kept for the bytes type:
$ /usr/local/cpython-3.2/bin/python
cmd started 2011 Tue Apr 05 11:05:08 PM
Python 3.2 (r32:88445, Feb 20 2011, 16:47:11)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.

'a/b/c'.split('/') ['a', 'b', 'c']
b'a/b/c'.split('/')

Traceback (most recent call last):

You're trying to split bytes with a str (Unicode) argument. Try this:
[b'a', b'b', b'c']

 

[Terry Reedy]

On 06/04/2011 07:06, Dan Stromberg wrote:

Doc says "Bytes and bytearray objects, being “strings of bytes”, have
all methods found on strings, with the exception of encode(), format()
and isidentifier(), which do not make sense with these types. " If you
find that in error, please file a bug report. You can check with
dir(str) and dir(bytes), possibly using set differences. But I believe I
did that once.

'a/b/c'.split('/') ['a', 'b', 'c']
b'a/b/c'.split('/')

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Type str doesn't support the buffer API

Known confusing error message, but notice that you did *not* get
AttributeError: 'bytes' object has no attribute 'split'
which is the error you get for random names. So .split was successfully
looked up and then called, and its execution gave the above message.

You're trying to split bytes with a str (Unicode) argument. Try this:
[b'a', b'b', b'c']

One change in 3.x is the elimination of automatic coercions between
bytes and (unicode) strings.
'a/b/c'.split(b'/')
# TypeError: Can't convert 'bytes' object to str implicitly

 

[Dan Stromberg]

On Tue, Apr 5, 2011 at 10:04 PM, Terry Reedy <[email protected]

   On 4/5/2011 4:42 PM, John Nagle wrote:

       Well, actually Unicode support went in back around Python2.4.


   Even earlier, I think, but there were and still are problems with
   unicode in 2.x. Some were and will only be fixed in 3.x.


       In 3.x, ASCII strings went away, but that was more of a removal.


   Yes and no. They were kept slightly modified as bytes, with all of
   the string methods kept.


I suspect not all string methods were kept for the bytes type:
$ /usr/local/cpython-3.2/bin/python
cmd started 2011 Tue Apr 05 11:05:08 PM
Python 3.2 (r32:88445, Feb 20 2011, 16:47:11)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> 'a/b/c'.split('/')
['a', 'b', 'c']
 >>> b'a/b/c'.split('/')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type str doesn't support the buffer API
 >>>

You're trying to split bytes with a str (Unicode) argument. Try this:
[b'a', b'b', b'c']

Doh. Thanks. Now I can eliminate my my_split function. ^_^