Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2645 > unrolled thread

is python 3 better than python 2?

Back to article view | Back to comp.lang.python

Contents

  is python 3 better than python 2? neil <neilharper300890@gmail.com> - 2011-04-05 13:42 +0100
    Re: is python 3 better than python 2? Mel <mwilson@the-wire.com> - 2011-04-05 14:46 +0000
      Re: is python 3 better than python 2? John Nagle <nagle@animats.com> - 2011-04-05 13:42 -0700
        Re: is python 3 better than python 2? Terry Reedy <tjreedy@udel.edu> - 2011-04-06 01:04 -0400
        Re: is python 3 better than python 2? MRAB <python@mrabarnett.plus.com> - 2011-04-06 17:31 +0100
        Re: is python 3 better than python 2? Terry Reedy <tjreedy@udel.edu> - 2011-04-06 13:01 -0400
        Re: is python 3 better than python 2? Dan Stromberg <drsalists@gmail.com> - 2011-04-06 13:14 -0700
    Re: is python 3 better than python 2? Gnarlodious <gnarlodious@gmail.com> - 2011-04-05 09:50 -0700

#2645 — is python 3 better than python 2?

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

[toc] | [next] | [standalone]

#2651

neil wrote:

> 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.

[toc] | [prev] | [next] | [standalone]

#2672

On 4/5/2011 7:46 AM, Mel wrote:
> neil wrote:
>
>> 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.

    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

[toc] | [prev] | [next] | [standalone]

#2688

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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2709

On 06/04/2011 07:06, Dan Stromberg wrote:
>
> On Tue, Apr 5, 2011 at 10:04 PM, Terry Reedy <tjreedy@udel.edu
> <mailto:tjreedy@udel.edu>> wrote:
>
>     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):
>    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/c'.split(b'/')
[b'a', b'b', b'c']

[toc] | [prev] | [next] | [standalone]

#2712

On 4/6/2011 12:31 PM, MRAB wrote:
> On 06/04/2011 07:06, Dan Stromberg wrote:

>> I suspect not all string methods were kept for the bytes type:

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/c'.split(b'/')
> [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

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2720

On Wed, Apr 6, 2011 at 9:31 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 06/04/2011 07:06, Dan Stromberg wrote:
>>
>> On Tue, Apr 5, 2011 at 10:04 PM, Terry Reedy <tjreedy@udel.edu
>> <mailto:tjreedy@udel.edu>> wrote:
>>
>>    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):
>>   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/c'.split(b'/')
> [b'a', b'b', b'c']
> --
> http://mail.python.org/mailman/listinfo/python-list
>

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

[toc] | [prev] | [next] | [standalone]

#2660

On Apr 5, 6:42 am, neil <neilharper300...@gmail.com> wrote:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web