141–150 of 513 posts
It's a huge usability fail on the part of Python that it's not obvious and easily memorable how to do this.
print "goodbye, sweet prince" I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too huge/crusty/etc that they will never get ported.
Doesn't this say something about the language if it's been so difficult for people to migrate from 2 to 3? Yes, it was a major version change, but it doesn't bode well for arguments that Python is a good language to do long-term, maintainable, and large-scale development. Sure, now things are "settled" with 3, but Python continues to get more features. It just doesn't look good for the language if even doing a langua…
Earlier quoted context omitted.
It won't be fragmented indefinitely, that claim might've carried some weight five years ago, but these days I see very few Python libraries that still support Python 2.7. And, if they do, it strongly implies that they've not been maintained for some time. (See also, a dependency on six) - with the caveat that sometimes you don't need to continually upgrade a library that fills its desired niche perfectly. Hell, if yo…
The people it lost are going to things other than python3.
Earlier quoted context omitted.
> first major language with this approach was ECMAScript 2009 (5th ed.) Not that I've any proof but I kind of find it hard to believe there were no other examples before
Python had that long before js, with __future__ imports. But editions & friends are for syntax. Python 3 changed semantics all around. Editions are not an option when you’re changing the langage’s entire text model, especially without static typing.
Python 3.1 could then have introduced some of the other minor changes, perhaps behind a future import.
I had a hand in moving from 2.7 to 3.6 for a 1M LOC repo and it was not pleasant. So many backward compatible changes that that all had to be accounted for rather than being able to focus on the major breaking change of a particular version. We couldn’t have done it without six.
It seems that a bunch of changes were made all at once because it was already going to be incompatible so let’s take the opportunity to clean up as much as possible. I think that was the big mistake.
Earlier quoted context omitted.
I'm wondering, is there work on how python 3's changes could have been promoted in smoother way?
An excellent question, how do you smoothly break compatibility?
1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable.
2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI.
Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
Earlier quoted context omitted.
IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA
> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then…
2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the world would be all over it. But massive breaking changes going from 2 to 3 was a disaster for their audience. Worse still you could hear the acrimony in Pythons communications on the topic.
Well, trying to sell a project to the higher-ups is a lot easier when you can say > Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3" Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: > Hey, there is a new interpreter out there called COBRA. We need to rewrite our who…
Earlier quoted context omitted.
Funny, for about every point I feel the opposite way :-). Python is an elegant language that hits the sweet spot where it is very expressive, and easy to do what you want, and at the same time has enough structure so you don't produce a mess all the time. The libraries are very powerful, but a lot of them are hacks. Numpy and Pandas totally rely on magic and overloading the array indexing operator. You can't express…
Interesting, and nice to have a contrasting datapoint. I do think that "The libraries are very powerful, but a lot of them are hacks. Numpy and Pandas totally rely on magic and overloading the array indexing operator. You can't express a problem the natural way or it will be slow, you have to think the numpy way. I find it especially confusing if you create expressions with numpy arrays. Am I operating on them elemen…
The language is 100% capable. Matplotlib's API is horrible and confusing because one of their design goals was/is to be similar to matlab (that's where the "mat" in it's name comes from) to allow people who are comfortable with matlab to switch more easily.
Matlab's plotting facilities are a mess of global state, so matplotlib has copied it.
> An 'elegant' language would provide a way to do so without all of these leaky abstractions.
It would have to do something else, first: Exist.
In 10+ years of programming, I've yet to ever see a implementation of a complex abstraction that was comprehensive and complete enough that I didn't find a corner case requiring me to reach through it and deal with platform specific something-or-other.
Earlier quoted context omitted.
I see the sort of perspective pervasively, but I don’t really understand it. I would guess that most people wouldn’t consider expunging c89 from gcc to be progress, yet this is almost universally the attitude towards python2. What am I missing?
You don't need to expunge c89 from gcc for progress to have happened - we've got c99 and c11 and whatever c17 is or isn't already there. Effectively, however, python2 and python3 are different languages. Since they're interpreted, there's now a problem with '#!/usr/bin/env python' in your script: which python version is being invoked? Which language version are modules targeting? It's a mess. But the poster child for…