Hacker News Reader

I don't think people are used to backwards compatibility breaks in languages.

Nor do they like it, because most if not all developers are using these languages for a practical purpose: to get things done. Having to relearn and "fix" things which otherwise wouldn't need to be has a cost, and this is on top of what they already have to do.

I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go. Outside of the software industry this is the norm; think of all the "interfaces" that we use in the physical world that have remained backwards-compatible and relatively stable over long periods of time. Software is different because it can change quickly and (by itself) easily, but just because it can doesn't mean it should, as if it is well-established, there is certainly a large number of dependencies on it too.

"I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go."

I'm gonna guess that you're not new to C++. I say new because people who have been following it and picking up all the changes along the way often can't see the forest for the trees. That forest is ugly.

I'd argue C++ is doing it really well. They took their shitty awful C++03 base that made developers around the globe cry at night, and tried appending on top of that mess less terrible concepts.

And now, modern C++11/14 doesn't look anything like C++03. Which is a blessing and a curse - they effectively depreciated a huge swathe of old practices for better new ones (refs over pointers, smart constructs over raw new / delete, lambdas and auto over void* function pointers, soon were going to have concepts and static if instead of preprocessor ifdefs).

But that comes with a price. The price is that C++ is huge, the compilers are slow due to the complexity, and it is really analogous to per project technical debt.

D exists because C++ was too slow. Walter (and Andre) saw this huge shortfall in standard C++03 and this entire class of functionality that should be there, because it doesn't have a performance overhead, but wasn't. Maybe they also saw how C# and Java were useful and popular, but they put this massive VM under them to simplify the implementation and standardization.

Go exists because C++ was too big - for its purpose, of web server development, you wanted native performance with natural asynchrony and multi processing. It still doesn't have generics because it is pretty much a domain language, I think.

Rust exists because C++, in the wake of C++11, is still a complicated mess of syntax. And in order to maintain backwards compatibility, C++ is terribly unsafe and every line of code can destroy your program. I think Rust is as close to the future of native languages, because it does the C++ thing - a general purpose language, where everything is deterministic and predictable because it is direct binary translation between language constructs and assembler with limited magic - and does that backwards compatibility break to fix the significant flaws.

I still don't like the Rust syntax much, but it might one day grow on me. I don't think its really approachable though, I'd definitely be interested in trying a "pythonic" static typed language that emphasizes safety and productivity while maintaining the poster C++ ideology of providing reasonable abstractions that don't hide the details, but let the expert more intuitively interact with them.

Have you looked into Nimrod? It is different from Python in that it embraces some concepts that Python rejects (e.g., AST macros, which are actually quite brilliant in Nimrod) but it's the most pythonic programming language that I know of that compiles to native code.

Thank you for recommending Nimrod; I'd never really looked into it before. Nimrod looks like a cute little language, but it seems to lack a staple of many other languages: support for the '\t' character in indentation.

If the python developers wanted to spend the time to reimplemented bad behavior, they could have create a reverse "import from deprecated ...".

It would solve most of the problem, while encouraging a switch to the new'er version by forcing every user to type in "import from deprecated" in top of their script.

I just think they didn't want to do that, given the massive work and non-existent personal gain. However, any company that want to invest their money on it can since its open source.

This is a great idea!

The problem is not only Unicode.

If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3.

I guess, you don't mean what you said in the last paragraph? Was it just a joke?

Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like.

Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.

> Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2. >

Actually, it's trivial nowadays with projects like pyenv. You can even have different python versions in a per-project-directory basis.

Check out the installation guide (https://github.com/yyuu/pyenv#installation) and a commands reference (https://github.com/yyuu/pyenv/blob/master/COMMANDS.md)

There's also an extension that provides virtualenv integration - https://github.com/yyuu/pyenv-virtualenv

Thanks, that looks interesting. I will note it for the time, I have the problem.

This is the same problem addressed by the ancient, universally known tool named virtualenv. How are you delivering pronouncements about the unsuitability of Python 3 when you don't have solid knowledge of how things are done in Python?

I did not "deliver pronouncements about the unsuitability of Python 3". I did only say, that it is not trivial to have both versions on one installation.

And who are you, something like the "Python purity police"?

I will ask you something, that you did not work with till now -- and when you give a wrong or incomplete answer, I will also say "how dare you"!

In what distros is that a problem? I have Python2+3 on Debian running fine side-by-side.

When you have several Python programs, where does /usr/bin/python point to?

I must admit, that I did not think to much about it until now, but normally there is only /usr/bin/python in the scripts.

Of course, if everybody has /usr/bin/python3 inside his Python3 programs, everything could work (unless some of your apps need special environment vars like PYTHONPATH, what could make it troublesome again).

But still, the standard installation of Debian (and others, as much I know) does not include Python3 by default, you at least have to add it to your installation. That is something, you must tell your customers, when you ship Python3 programs.

/usr/bin/python should never point to Python 3. Because of the compatibility break, the convention (and default for the Python build scripts) is to always name the Python 3 binary python3, so there should be no conflict. It's understood that during the (very long) transition period there will be need to run both side by side.

A handful of ditros have gone ahead and named it python anyway. A stated motivation has been to encourage adoption of Python 3, but practically they're just shooting themselves and their users in the foot, and ensuring incompatibility with the shebangs defined for every other OS. (I don't think there's any plan to ever switch the default binary name from python3 to python, so this incompatibility may never be resolved.)

Arch switched from Python 2 to Python 3, keeping the /usr/bin/python binary as pointing to their newest version of Python before the convention of naming it /usr/bin/python3 was standardised.

It was specifically in response to the troubles caused by having /usr/bin/python be python3 in Arch that the guideline came about: http://legacy.python.org/dev/peps/pep-0394/

Thanks for the reference; I somehow failed to find the origin of this convention in previous searches.

Most package managers allow you to specify a dependency on Python 3, so you shouldn't even need to tell your customers. Otherwise, you can always use virtualenv and ship Python with your code.

And yes, if you're targeting Debian or Debian-like systems, make a deb. It's really not that hard, especially with newer tools like fpm.

Thank you for mentioning fpm, I'd never heard of it and often wished for something like it. Commenting to bring attention to it, and so I don't forget!

> When you have several Python programs, where does /usr/bin/python point to?

/usr/bin/python should always point to python 2 (or nothing) /usr/bin/python2 should always point to python 2 (or nothing) /usr/bin/python3 should always point to python 3 (or nothing)

scripts using a shebang line should not, however, rely on /usr/bin/python pointing to python2, and should only use it when they are source-compatible with both python2 and python3.

http://legacy.python.org/dev/peps/pep-0394/

> (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already)

Actually, the name really is taken and by programming language: http://cobra-language.com/ - looked nice when I last looked.

I didn't know about Cobra Toolbox, however.

Was going to reply to the parent of your comment, but since you beat me to it:

>Actually, the name really is taken and by programming language: http://cobra-language.com/ - looked nice when I last looked.

The Cobra language does look interesting [1]. Checked it out a little a few weeks ago. I think it only runs on .NET and Mono, though.

[1] It uses ideas from several languages, including Python. On the Cobra site, there are a few short comparisons between it and other languages, including Python:

http://cobra-language.com/docs/python/

Also, it has a feature similar to Design By Contract like Eiffel does:

http://cobra-language.com/docs/quality/

Cobra is worth a look, and keeping eye on as it evolves, IMO.

I especially like optional static typing and compile-time protection from nil/None very much. It's type system doesn't look very sophisticated, but since you get fully dynamic variables with no (syntactic) overhead it's not that important. requires and ensures are very nice (as are tests), especially because the only other language with real contracts (Racket) focuses on functions and is a bit lacking when it comes to contracting methods with side-effects.

It generally looks quite nice for a niche language and it's nice that it seems to be maintained. It seems that there is a JVM underway, by the way. Boo was the other similar, interesting language I checked out some time ago, but it seems to be under less active development (if at all).

Anyway, if Python 3 is such a problem, then maybe let's port everything over to Cobra. It has snake in the name and familiar syntax and lots of goodies; imagine how far it could get if hundreds of thousands Python users would start working with it! (Just joking, although I'm wishing Cobra (and all other new or unpopular) languages the best of luck, of course)

Interesting points, thanks, and good to know about the JVM support.

OMF, I have been looking for Cobra's home page for years! I saw it a few years ago, and was quite impressed by it, bookmarked it and then forgot all about it. Then spent the next few years searching through Lambda the Ultimate, the Internet, etc to try and find it again. And now it's in front of me again, and more mature to boot! Whoot! :)

To be fair Anaconda is the name of a leading python distribution focusing on scientific python. Note, I work for Continuum.

Ruby did it and we're not wringing our hands about how Ruby is dead. It's just that the whiners feel particularly empowered in Python, they believe they have a chance of getting Python 3 erased.