Hacker News Reader

> Suddenly print is a function?

from __future__ import print_function

Now you've got print function in python2.

> 'yield from' won't be available on the py2 branch?

And 2.6 doesn't get set literals. And 2.5 doesn't get "with" statements. And ... There's got to be a cutoff somewhere. Or we'd just have an eternal 1.0 with all the features backported to it.

Well no. The problem is that py3 breaks backwards compatibility, without really a good reason. What's so much better about it? Why couldn't they sort py2 at least for module imports?

Which is exactly opposite for c++11 - it doesn't break backwards compatibility, but I really want those new features. I think if it broke backwards compatibility, I'd still switch to the new c++.

At work we use py2 and c++11...

The most visible changes, such as print being a function, are the easiest and most trivial to adapt to. They clean up the language, and can be automatically converted from one to the other. This can be pulled into python 2 with "from __future__" imports.

The harder part is the string handling. In Python 2, you have one class, string, which is performing two different jobs. It is acting both as a holder for text, and as a holder for binary data. This sort of works, because ASCII looks like binary data if you squint it. If your users are English-only, then this probably sounds like a reasonable thing. Once you need to start supporting Unicode, this ambiguity causes a world of pain.

On python 3, this ambiguity is removed. You have bytes, which are binary data, and strings, which are encoded text. No longer is there one class trying in vain to represent both concepts. This is also why automatic translation doesn't work, because the translator doesn't know which concept you were trying to user when you used a python 2 string. This is a rather low level change, which is why it took libraries so long to update, and why it couldn't be done without breaking backwards compatibility.

> In Python 2, you have one class, string, which is performing two different jobs.

What? Have you used Python 2? No: in Python 2, you have two classes; one is called "str" and represents a sequence of bytes, and one is called "unicode" and represents text. The former is used while interacting with network protocols and files, and the latter is what you use internally in your program: at the boundaries you use .decode and .encode to convert using character encodings. (BTW: Python 3 actually got this wrong for years, and even now I think it is only fixing the problem with a mitigation :/ filenames do not have an encoding: they should be of type "bytes", not of type "unicode", and Python 3 seriously shipped with an implementation of "list files in directory" which returned names as "unicode" and any names which failed to convert were just skipped.)

Then, Any text in your program should use a syntax u"" to indicate it is program text of type unicode. Sure: there are some really annoying implicit conversions in place that allow mistakes to be made, but WTF: they absolutely didn't need to rename "str" to "bytes" and "unicode" to "str" while simultaneously not only changing tons of other things in the language (the ability to pick and choose is amazing for porting) and making pointless related changes like removing the u"" syntax (which yes, I realize they added back later... years later... many many years too late). They should have just given me a way to "poison" str/unicode objects so they refuse to participate in implicit conversions, which would have let me find the corner cases in the libraries I use that are doing things wrong so I can report them to their maintainers and get them patched; after a couple years of people throwing .poison in a bunch of places users would have been ready to flip a VM-level "just don't convert them anymore".

As for renaming the classes, "bytes" should have been left as an alias for "str" (as it was/is "temporarily"/forever in Python 2.7), "str" should have generated a warning... I mean, "str" isn't even a good name :/... it's a silly three character abbreviation of a concept that is ambiguous in the minds of most developers already due to other languages, whether they be like C or JavaScript). They certainly had absolutely no good reason to get rid of the "unicode" type name (and this one still isn't back). The set of decisions they made were so annoying that even people who know what they are doing have to do a ton of fidgety and easily-broken work in a dynamically typed language where you are more than likely to just break something and not realize it until a month later.

Seriously: I've been programming in Python (2, not 3000) since 2007 as one of my primary programming languages; I do all of my web development in Python, for a website which is used around the world by millions of people and is not only itself translated into tons of languages (by both professionals and volunteers) but deals with tons of user-generated content that is accessed via tons of different channels (APIs from various websites, native network protocols, and tons of file formats as all the content indexing is also written by my, in Python), and dealing with these issues in Python 2 is simply a non-issue: in fact, I would say it is almost trivial (and in fact, the ways it tends to break in Python 2 are often quite similar to the way things break in Python 3, as it is easy to set up situations where the implicit conversions essentially fail).

Yes, I have used python 2 quite often, as well as python 3. Python 2 is sloppy in this regard. You can use a "str" to represent text, and it will work perfectly, so long as you stay within the ASCII character set, setting up hidden bugs later. Telling everybody to just use u"", while correct, sets up "" as something that looks correct, but isn't. In addition, suggesting that "str" is a sequence of bytes, rather than a string, is rather inappropriate. The documentation refers to them as strings, they are created in similar manner to strings in other languages, and they are generally accepted by library methods that set text properties.

I agree that there were some changes that were unnecessary, like the removal of the u"" syntax. That said, I think that the fundamental change, which was to have the thing named "string" be a string, was the right choice. Python has always been about having the obvious choice be the correct choice. Telling everybody that "quoted text" is not text runs counter to this.

I totally agree with you.

> ... one is called "str" and represents a sequence of bytes ... The former is used while interacting with network protocols and files ... Python 3 actually got this wrong for years ...

Actually some Japanese have suffered from this wrong design of Python 3. If you read Japanese, please see http://www.oki-osk.jp/esc/python/upload-cgi/v2.html#3

> Which is exactly opposite for c++11 - it doesn't break backwards compatibility

Yes it does:

https://stackoverflow.com/a/6402166/31667

> At work we use py2 and c++11...

As do most corporations. If you want a job in Python, you had best know 2.7.

for native unicode support I would break the world.

2.7 does Unicode quite well. Not as well as it should, certainly, but arguably better than 3.3 did. I haven't played with anything since, and given the long history of this project going off the rails, I will require some serious convincing before I waste more time in it.

Yes I do multilingual string processing a LOT. I worked in SMT for about 3 years. Python 2.7 was the only practical option.

Python 3 does not fix the GIL. That would be enough to get me interested again.

A language must change, or it will be left behind, and become an esoteric toy. Even C has to deal with this. The only reason C is still popular is because of it's grandfathered status in so much of our infrastructure, and in many of the popular OS choices.

A language that changes will alienate people, and lose people. Perl saw this. Python is seeing this. The way to guard against this is to keep backwards compatibility. That generally doesn't allow enough change in languages that provide enough constraints to make them popular for large engineering projects, whether open source or commercial. Lisp doesn't need to change much, it's malleable enough in many respects that you can implement whatever you need, but good luck getting large engineering projects done and maintained using it. Perl has the same problem.

The only solution I see to stay relevant is to allow alienating users, but make sure those changes that alienate users are good enough to draw substitutes, enough to keep steady state, or preferably still grow slowly. Maybe prior users will even swing back in occasionally, and without the false sense of betrayal, they'll actually find they like the state of the language a few years later. For a while, at least.

This seems like the end of the world to Python community members, and it seemed like the end of the world to Perl community members because of the prior status those languages held, where they are or were at the top of their respective niches. I doubt the Scala community worries about exactly the same things.

Put another way, did you expect to still be writing Python the same way in 20 years, with only the popular libraries changed? If you did, did you think about what that would mean for the language, and what the community would look like at that time? I'll tell you. Perl. That's not necessarily a bad thing. I write Perl professionally, every day. I love it. It's not the worst thing, being stable and reliable. But you don't get to be top language in your niche and sit on your laurels at the same time.

Change is good. Embrace the change. If you're lucky, you'll use many languages to program in your life and be happy. The only way I see anyone being happy using any single language forever is to bury their head in the sand and ignore everything else going on around them.

Even C has to deal with this.

But is there any C11 compiler out there that will refuse to compile C99?

I used C as an example of what happens when you don't change, not what happens when you do. C is used decades later with little change because of momentum and history, not because it's the pinnacle of computer languages.

C is not a good language. It was a good language, but that was a few decades ago. We've progressed past the point where C's shortcomings are excused by there not being alternatives that address those shortcomings while offering comparable features. At this point, we're just finally edging past of the local maxima created by C's exceptional popularity and the knock-on effects of that popularity, such as most operating systems (and all popular open source ones) being written in C.

What's replacing C? I can see languages like go/rust/crystal replacing C++ for application development, but what's producing stable binaries that other languages can consume in the same way the do C ones?

Rust can produce C compatible libraries. Go apparently can too. I suspect a little googling would show me that Nim and D can as well. I'm sure there are at least a few more.

Go can use C libraries, but AFAIK it cannot be compiled into a shared library to be used by a C program. Go needs control of the program flow to orchestrate its runtime (esp. the GC).

Nim can definitely produce C-compatible libraries, seeing how it compiles to C itself.

>but AFAIK it cannot be compiled into a shared library to be used by a C program.

Go 1.5 added support for this.

Interfacing D to C and C++ is failry easy as it was built with excellent C/C++ interop in mind. It's also compatible with C ABI and has limited compatibility with C++ ABI.

I didn't know rust could, I just checked it out. I didn't realize rust was that low level.

Python is an interpreted language, so the comparison is meaningless.

It is cheap to deal with the ambiguity in the compiler using compile options. You could go the Java way and have separate class path (e.g. In PyPy, as CPython 2.x is dead).

But this does not allow you to mix and match code for older version anyway. Java was designed from start to allow this and it is why it's so stagnant.

Python is an interpreted language, so the comparison is meaningless.

Bash has no problem running old Bourne shell scripts from ancient history. Browsers have no problem running JavaScript from the mid-90s. I fail to see how being an interpreted language is a valid reason for breaking backwards compatibility.

being interpreted is not a valid reason, but the string class for both bytes and text is a valid reason.

>I doubt the Scala community worries about exactly the same things.

Why do you single out Scala as being particularly different to Python and Perl?

Because Scala isn't nearly as popular as Perl was or Python is. I imagine losing some perceived status is less important to them than just doing the best they can to provide a good product and address people's needs.

Scala work sure pays a heck of a lot better.

The term 'C++ community' feels strange. It's like saying 'the combustion vehicle community' or something like that. As a software engineer I don't want a community or someone to bond over the tools I use, I just want my stable tool with a large industrial user base.

It's an industrial tool, with an ecosystem provided by an industry, used to solve industrial problems.

C++ can't change. It's a feature. Unless the code uses some non-standard extension it is guaranteed that the code you write today will compile tomorrow.

Refactoring? Rewriting? We are talking of decades old codebases with millions of lines, filled with bugfixes to handle odd-but-critical cornercases.

Software that is sold for hundreds of millions, that run businesses that execute billion dollar projects.

Stability, utility man.

Not so graceful, perhaps, or cuddly. But it works.

Yeah, the language is still a bitch but it's at least a stable one with support from several industrial vendors.

From cognitive or software design point of view it's a disaster though - people should be thoroughly vetted in some other more sane language before allowed to write C++ :)

> Let's hope python can be saved.

Can you explain why Python would need to be saved? I mean every week on r/MachineLearning there is at least one new Python deep learning framework being launched[1], I wonder if you can mention any other language which is that healthy.

[1] https://www.reddit.com/r/MachineLearning/search?sort=new&res...

All stable versions of the big ML frameworks are still 2.7.

Even if your statement was true (it's not)[1][2][3][4], how would that be a sign that Python is dying?

[1] http://www.deeplearning.net/software/theano/install.html

[2] https://www.tensorflow.org/versions/r0.11/get_started/os_set...

[3] https://keras.io/#you-have-just-found-keras

[4] https://lasagne.readthedocs.io/en/latest/user/installation.h...

I think the author's point was not that python3 is dying. His point was that it deserved death, that 2.7 is flourishing, while 3 is failing to thrive, and reasons for this were postulated.

Are there many ML frameworks that only work in 2.7? Scipy and numpy work in both 2.7 and 3.x, so I'd imagine (without being heavy in the field) that any new development using these scientific computing packages could be Python version agnostic as well. Is this generally not the case?

Not true. Please specify which ML library authors are obtuse.

About the only thing that is dead like that seems to be Enthought project for drawing and creating UI for graphs.

Sorry, should have said run better. There is support for latest 3.x branch, but everyone uses 2.7 as it's less bugguy.

Every week on HN a new JS framework is launched. I'd say it's pretty healthy.

Too bad JS lacks a standard library.

I don't really hear that many complaints from the C++ community about what you're talking about. All those older libraries that pre-date C++11 still work fine and interoperate with no difficulties with even C++1z libraries. C++ is the language that has done feature adoption correctly in my opinion. Standardized, by committee, with forwards and backwards compatibility in mind.

I'm with you. I like some of the changes in the C++ language. But I don't love the C++ 3rd-party ecosystem. Python's is very healthy.

C++ is so unconcerned with modules they've been kicking the feature down the road spec by spec. I think it's now 'post-17'. (could be wrong).

Rust is a language that's in the perf class of c++ but has built-in lifetime support and built in modules. It's ten times easier to do database or, say, SDL interaction in rust. And rust is barely 1.0!

I don't know anyone who programs who doesn't use a ton of libraries. C++ just hasn't prioritized this part of programming.

Python still has the best libraries of any language, and almost every library has full Python 3 support. The real issue is with legacy codebases that are going to need to upgrade from Python 2.7 to 3.5 or else switch to PyPy by 2020

Errr... what?! C++ is a positive example of language change, because it keeps backwards compatibility, unlike Python where we're still having discussions about 2vs3 after 8 years.

Nobody is having discussions about C++14 vs C++98, the latter is better period. A C++14 compiler will compile C++98 code just fine in most cases. If it doesn't you get a compile time error.

People are complaining about the opposite, that C++ is keeping compatibility for too long and that it has too many features. Both strategies have their pros and cons, but breaking seems to have more negative effects.

C has done a great job of supporting buffer overflows on lots of platforms and injecting safety errors in all software that uses those libraries.

>C++ is an example of the serious negative consequences of language change.

From the outside looking in (as a non-C++ developer), for me the bigger problem is honestly that they left in the warts rather than just paving around them. Those who have followed C++ for its entire life cycle have probably been able to mostly keep up with what language features were mistakes and what the best way to do things is, but I can't imagine myself ever picking up C++ now and hoping to have any clue at all what to avoid without spending years learning the hard way (no pun intended).

As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets?

> As a very basic example from C# (which I do use professionally), the fact that untyped collections still exist (and things like IEnumerable with explicit casts instead of IEnumerable<T>) is just pointless cruft that we'd be better off without. As far as I'm concerned, no code should ever depend on them, and any code that does should be forcibly broken to force people to fix it. We treat security flaws seriously by forcing people to fix things, why should we not do the same with features that are essentially bug-magnets?

I mean this is an age-old argument but MS comes down very strongly on the other side because, like... what if nobody is working on that C# 3.0 code anymore but you need it for whatever reason? Well, I guess you're out of luck in the world where they just break ArrayList.

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

On c#, the numerous core libs that don't meaningfully support nullable primitives is the most infuriating thing.

Don't hitch your wagon this this garbage. If you think the 2 to 3 transition is a harbinger of doom, write your own blog post about it.