Comment by rdtsc | Hacker News Reader

Comment by rdtsc | Hacker News Reader

That pretty much reiterates my points from last time we discussed (not many hours ago).

https://news.ycombinator.com/item?id=7801004

Besides what already was said. It is also important to emphasize that Python 2 is already pretty good. So it is not that Python 3 is bad, it is just that it is very hard to improve on 2.

Ironing out the warts is good, but this was not the right time. This should have happened 7-10 years ago.

Nowadays I can't imagine a lot of people discounting Python because of the print statement, unicode support, division rules, or lack of yield from statement.

It will be performance, concurrency, ability to create web back-ends, installing packages, testing frameworks, IDE support.

Apart from allowing optional type annotation syntax I just don't see Python 3 providing a good enough carrot to force many projects to switch to it.

Imagine you go to a manger and tell him. "Oh this 800K line project we have in Python 2 will be ported to Python 3, can we have 1 month to do that?". Ok then the manager might say "Well we have these features to implement but if you all say so. But what will we gain by it, to offset the time spent (opportunity cost) and risk of breakages". And if the answer if "oh you know print is not a statement anymore, and many dictionary and sequence methods are not iterators not returning values, and this new Twisted-like async library...' Well you can imagine many a manager might just say "well that is just not enough".

If in turn the dev team came back said "Oh yeah they integrated PyPy, STM module, requests module. Static type checking via annotations, 3x speed improvement, no more GIL so can do some CPU intensive work if need to.". I can easily see this proverbial manager OK-ing that.

I can tell that proper Unicode support is a reason to discounting a language/library if you're not a native English speaker and/or writing programs that have to be localized.

Python was created by a non-native English speaker.

Well, he's Dutch, his language uses an alphabet meaning that even with all the accents it's still a one byte language.

Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.

> Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.

Proper unicode support is not even close to being a priority when it comes to dealing with Japanese text. No one would store important Japanese text in unicode. http://en.wikipedia.org/wiki/Han_unification#Unihan_.22abstr...

One size doesn't fit all.

This makes me wonder about Ruby, whose creator is Japanese and Japanese is certainly not a language whose characters can be expressed in a single byte. Is Ruby better than Python for complex encodings? If so has it always been this way, or did Matz just deal with it in the early days?

Yes, Ruby has long had decent (i.e. comparable to Python 3) encoding support. But in the early days not much was made of this, perhaps because Rails was the driving force behind Ruby adoption in the west and Rails' encoding support was much worse than what Ruby could do.

I know that. I'm Italian, and Western European Languages can be expressed on a 1-byte character type. I also understand that the performance gain of 1 byte char was significant. But now is 2014 and not to have to wrestle with encodings definitely worth the performance and (somewhat) complexity hit.

As a unrelated (to Python) example of the encoding nightmare: have you ever tried to import text from CSV files generated on different OS/locales in Excel that don't support Unicode-encoded CSV files? It can be made, sure... but, man, if it can be avoided... ;)

I did this recently. I can't remember the details but it was absolutely insane.

Before Unicode existed

And Python3 was also endorsed by the same person, so?

Exactly. Python and JavaScript is a perfect demonstration of "worse is better". Python 2 is a vastly better language than JS, avoiding nearly all of its design misfeatures and having actually useful built-in types and standard libraries. Yet while Python spent a decade to go from 95 to 99 percent purity, JS took over the world through sheer ubiquity.

Javascript won the "language lottery" when it was created for the web browser, how would another language capitalize on that?

Exactly. JavaScript has attained ubiquity through convention only. It has nothing to do with its intrinsic qualities or deficiencies. A great many languages are preferable to JavaScript.

Given that the functional programming story in JavaScript is much more developed, "vastly better language" may be true as long as you only consider the object-oriented side of it.

How is it "much more developed", without providing generators, coroutines, or comprehensions?

Just having to use functions to emulate all of these (and many more) is not what functional programming is all about.

ECMAScript 6 has generators, and they are already available in Node.js.

Javascript seems to go the opposite way of python: instead of ironing the warts out, it adds them. The DOM-API is nonsensical and ugly? Why not add language features so we can implement it in pure JS? Sounds like a great idea.

How does that relate to ES6 generators?

While I agree mostly with your point, I think the DOM example isn't going to work. The DOM is a spec and doesn't really have anything to do with JavaScript.

The DOM API has nothing to do with JS.

So we need to get Python embedded into a couple of major browsers?

Edit: Asked on twitter for any work on this: https://twitter.com/alexchamberlain/status/47126815887225241...

There used to be something for Internet Explorer 4 and above. All you had to do was to set the language attribute of the <script> tag to Python. See "Python Programming On Win32: Help for Windows Programmers", page 437 [1].

[1]: http://books.google.ro/books?id=fzUCGtyg0MMC&pg=PA437

So, you'd want people to switch to PyPy, not Python 3.

I think you missed my point. I presented a hypothetical situation where in an alternative reality Python 3 happened to instead integrate something like PyPy in it (or say have any other mind blowing features of that caliber).

> So, you'd want people to switch to PyPy, not Python 3.

I personally would want Python to be used more because I like it. But I see how a community has been divided over what I see is an un-necessary backward incompatible change to the language.

To put it another way. I would rather not have backwards compatibility issues and just keep having 2.8, 2.9, 2.10, if all we got was what we got with 3.x

Reply on news.ycombinator.com