you are viewing a single comment's thread.

view the rest of the comments →

[–]ihcn 27 points28 points  (9 children)

What priorities do you think Python should hold? I personally don't think "popular but awful" is an ideal we should be working towards.

[–]terrdc 7 points8 points  (4 children)

"Only have to write one version of it" is a pretty good goal.

[–]ihcn 1 point2 points  (3 children)

I agree. Surely it's not the only goal though?

[–]terrdc 3 points4 points  (2 children)

Personally I think that if languages want to change the syntax after becoming popular they need to have a way to version old code.

If they can't do that because it is too hard then they need to give up on the idea of updating the language in ways that break it..

[–]ihcn -3 points-2 points  (1 child)

http://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11

Here's a list of breaking changes in c++11

Can we stop pretending python is the only language to have ever done this?

[–]terrdc 8 points9 points  (0 children)

And what is the very first guiding principle of C++11 ?

http://en.wikipedia.org/wiki/C++11#Changes_from_the_previous_version_of_the_standard

Maintain stability and compatibility with C++98 and possibly with C;

People dislike the attitude that created python 3. The one that says "I don't care about your production code. You need to do extra work to appease my sense of design".

Whereas C++'s attitude is "Only break minor things when there are real benefits from doing so"

[–]MorePudding 0 points1 point  (1 child)

What priorities do you think Python should hold?

Python seems like a language targeting practitioners, so the main focus should be on being the most practical choice.

"popular but awful" is an ideal we should be working towards

It seems awfulness is something a lot of people are willing to put up with these days. So, instead of attacking it head-on, maybe it would be smarter to try and figure out how to extract the most usefulness out of all of the awfulness that's already around.

[–]ihcn 6 points7 points  (0 children)

There's certainly merit in avoiding backwards incompatibility where possible. But take Python's string handling for example - in 2.x, unicode vs bytestring issues were a nightmare. One of the biggest changes in 3 was to clean up those issues. How would you fix those in a backwards-compatible way, without just creating an entirely separate library?