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

Proposal: Moratorium on Python language changes

Posted Oct 21, 2009 23:39 UTC (Wed) by cortana (subscriber, #24596)
In reply to: Proposal: Moratorium on Python language changes by mhelsley
Parent article: Proposal: Moratorium on Python language changes

It's not like C had many features to begin with. Did C99 deprecate anything that was in C89?

I'm reluctantly coming to the conclusion that Python 3 should have remained 100% compatible with Python 2 code. Today, I write python3 scripts for my own stuff, but any serious work involves third-party libraries, none of which work with python 3... oh well! :(

(Log in to post comments)

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 0:40 UTC (Thu) by foom (subscriber, #14868) [Link]

Python had a perfectly reasonable deprecation policy. It would have been much better IMO to keep using it, and slowly deprecating, replacing, and eventually deleting undesirable features, over a period of time, as has been the previous policy.

But, that's not what happened. Instead, a ton of new things were added, old things were deleted, and significant parts of the language incomapatibly changed, all at once. So, the result is certainly different. But is it better? Perhaps. There was very little time to review all the changes that happened, and I'm afraid there may be just as many new misfeatures as there were old misfeatures that were removed.

And, as things stand now, not even all of the standard library in Py3k works properly yet -- nevermind 3rd party software! Hopefully by 3.2, at least the stdlib will be finished being converted.

Proposal: Moratorium on Python language changes

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

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.

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.

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 16:39 UTC (Thu) by nye (guest, #51576) [Link]

Are you sure about the latter? I'm fairly certain string literal concatenation is still considered kosher (I've certainly seen it used without generating warnings, let alone errors).

Proposal: Moratorium on Python language changes

Posted Nov 1, 2009 23:05 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

String concatenation in C is recent, it wasn't in K&R. And I doubt it will go away (it is way too useful, the previous way using '\' at the end of the line was bletcherous)

Proposal: Moratorium on Python language changes

Posted Nov 2, 2009 0:25 UTC (Mon) by nix (subscriber, #2304) [Link]

Adjacent string concatenation via comments, e.g.

#define PASTE(a,b) a/**/b

PASTE("foo","bar")

was thankfully broken when cpp was defined in terms of tokens rather than
in terms of text-stream transformation. But that was C89...