Proposal: Moratorium on Python language changes [LWN.net]

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 17:44 UTC (Thu) by drag (subscriber, #31333)
In reply to: Proposal: Moratorium on Python language changes by foom
Parent article: Proposal: Moratorium on Python language changes

I think that it reached a point were it was cleaner and easier to do a ABI
break in one version then to try the gradual upgrade.

I think that it has a lot to do with getting rid of the heavily overloaded
use of strings and stuff like that. One of the irritating things with python
I run into is that strings are used to represent everything, yet they can't
really cleanly support things like UTF-8 and makes handling binary data
irritating.

(Log in to post comments)

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 17:58 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

it's always easier for the developers of a tool/language to do a clean break rather than a gradual upgrade.

but it's always easier for the users of that tool or language to a gradual upgrade.

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 20:54 UTC (Thu) by drag (subscriber, #31333) [Link]

Well the problem is there may NOT be a way to upgrade. For all intents and
purposes Python3 is a new language, not merely a upgrade of a old one.

Like I mentioned before strings types in Python 2.x are heavily overloaded.
They are used for everything and holding all sorts of information and are
fundamental part of a lot of modules.

But with 3.0 they got rid of strings completely. Well.. they are still
called strings, but they are very different. Now all strings are encoded in
Unicode and they introduced a new datatype "byte".

For what I do this is a _massive_ improvement. In Python 2.x every time you
touch any sort of data it must be translated to text first.

So you end up trying to do lots of binary operations on text-encoded binary
strings. Or you are forced to do things like read text-encoded binary
strings from a file or datastream, convert it to byte arrays (thin wrapper
around C arrays), perform your data manipulation, convert it back to text-
encoded binaries and then output that to a file or data stream which
triggers yet another string to binary conversion.

Also operating in C data types like arrays are often slower then other more
pythonic data types because of the overhead that occurs when you access the
datatype and it processes the variables into something that python can
garbage collect and that sort of thing.

And this spreads itself out to other things like dealing with Unicode text
which can't be handled by regular strings... instead it must be manipulated
like a binary data; a text-encoded binary format. Of course lots of methods
and such take care of most of the pain of dealing with that, but it's still
a lot of overhead and a PITA.

So while the syntax is very similar I don't think that there is any nice
way to co-mingle Python 2.x with Python 3.x. If you try you'd just end up
with hell for everybody.