Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Python 3 Should Have Worked (2012)

aaronsw.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: How Python 3 Should Have Worked (2012)

#31

Post by philh »

sepeth wrote: post #30
philh wrote: post #25

> 3. In Python 2.c, warnings begun being issued when you tried to use the old way, explaining you needed to change or your code would stop working. > 4. In Python 2.d, it actually did stop working. I'm curious, what are some examples here? The `from __future__`s that I recall offhand are `print_function`, `division` (still need to be explicit) and the old `with_statement` (incompatible code broke as soon as this beca…

there is `unicode_literals` too. For the full list, see http://docs.python.org/2/library/__future__.html And there is one forgotten in that list: from __future__ import braces

So it looks like in Aaron's list, 2.a == 2.c and 2.b == 2.d, and the process has been completed only three times, and two of those times were just adding keywords.

Re: How Python 3 Should Have Worked (2012)

#32

Post by pak »

rdtsc wrote: post #20
overgard wrote: post #17

Earlier quoted context omitted.

Ok but... you could do unicode in python 2, it just wasn't ideal. The problem was, python 3 doesn't actually solve most peoples actual day to day problems. Here are real problems with python: * It's slow (excluding pypy) * The C interface sucks (compared to something like Lua) and holds back language progress * It can't handle multicore well outside of multiprocess hacks (which are sold as "the right way" -- bullshit…

I agree with your general point -- I haven't switched to Python 3 because it doesn't really solve anything I need solved at the moment. I would incur a significant time (=money) penalty for converting all my code to use it without a perceived benefit. I would have to get say a 30% speed increase or a 30% code # of lines decrease to get of my butt and start converting to Python 3. I want to in principle, don't get me…

>I hate implicit hidden defaults and assumptions.

Your implicit hidden default is my handy abbreviation.

Imagine if we didn't have contractions in English.

For that previous sentence, is it really at all frightening that the "didn't" meant "did not" but we haven't (ha) written it out? Could it possibly mean anything else? Wouldn't English be all the more stilted and ugly if there were only one explicit and verbose way (a Python design principle) of negating verbs?

If I redefined the "self" as any other name Pythonistas would hate on me for being unidiomatic. Most editors highlight "self" in anticipation of what it means. In fact, I have never seen code where specifying another name would be justifiable. The only conclusion from this situation is that it is a de facto keyword and re-specifying it every. single. time. is a waste of programmatic breath.

And for this reason, every time I tab between languages and get my favorite "function takes 1 argument (2 given)" error, (by the way: a completely bewildering message for a programmer from every other language, rereading the method definition and wondering where the second argument is coming from [1]), I mutter curses at my terminal for Python relentlessly carrying this wart into its third decade.

Implicit and explicit are relative to expectations. Python moves the implicitness into the way arguments are passed to methods. It is not any more explicit when placed in the context of all other OOP languages, but rather an eccentric convention.

[1]: 800 results on SO. Read them and weep. http://stackoverflow.com/search?q=Python+takes+arguments+giv...

Re: How Python 3 Should Have Worked (2012)

#33

Post by Freaky »

overgard wrote: post #21
d0mine wrote: post #12

Earlier quoted context omitted.

Unrelated: You do know that pypy also uses GIL. CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should implement Python C API).

I do know that; although they've done some interesting work with STM recently and hopefully that works out. I remember in the past hearing about someone actually submitting a patch to cpython remove the GIL about 10 years ago, but it was rejected because it made the language about 2-10x slower. IMO, that decision was INSANE. I have a 16 core machine right now and it can only really use 1/16th of it. Nobody uses pytho…

> Ruby is already about 10x slower than python on most of tasks

No it isn't - both are roughly in the same ballpark. Even before YARV it wasn't anywhere near an order of magnitude in the general case.

Re: How Python 3 Should Have Worked (2012)

#34

Post by dded »

overgard wrote: post #21
d0mine wrote: post #12

Earlier quoted context omitted.

Unrelated: You do know that pypy also uses GIL. CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should implement Python C API).

I do know that; although they've done some interesting work with STM recently and hopefully that works out. I remember in the past hearing about someone actually submitting a patch to cpython remove the GIL about 10 years ago, but it was rejected because it made the language about 2-10x slower. IMO, that decision was INSANE. I have a 16 core machine right now and it can only really use 1/16th of it. Nobody uses pytho…

Not everyone's needs are the same. I'll not say that my concerns are better than anyone else's (of course), but they're certainly different than yours.

If Python were 10x slower than it is, I'd use Perl. When I started using Python for real (2004), I'd have stuck with Perl if Python had been 2x slower. (Note that I very much dislike Perl, and thought of Python as a nicer Perl when I first learned it.) I care about speed, and I also care about convenience. Python has a very nice balance of the two for me.

On the other hand, I only use threads in one script that I've ever written (and the GIL isn't a problem with it). So I just don't care about the GIL.

(Edit: re-worded second paragraph)

Re: How Python 3 Should Have Worked (2012)

#35

Post by zanny »

overgard wrote: post #17
nostrademons wrote: post #11

This misses the point of why Python 3 was invented: Unicode. Python 2's string handling is broken in the presence of unicode characters, often leading to subtle errors that wouldn't cause exceptions until far away from the place where the error was introduced, and oftentimes didn't produce exceptions at all, just wrong data. Strings were defined as sequences of bytes, and then provided a .decode method to convert the…

Ok but... you could do unicode in python 2, it just wasn't ideal. The problem was, python 3 doesn't actually solve most peoples actual day to day problems. Here are real problems with python: * It's slow (excluding pypy) * The C interface sucks (compared to something like Lua) and holds back language progress * It can't handle multicore well outside of multiprocess hacks (which are sold as "the right way" -- bullshit…

> Sometimes threads are useful).

I would never in a million years look at a performance problem and given these two options:

1. Write the critical section in a faster language in serial (ie, rather than dynamic interpreted script, maybe compiled bytecode, or maybe even native machine code). 2. Write the critical section multithreaded in the script language.

I would never think to use #2 first. I would always just move my CPU bound code into a tiny C++ library and only worry about threading as a matter of last resort. You get so many huge leaky problems (even if you got rid of the GIL you would be looking at variable synchronization, atomic timings, and cache coherency) from going to multithreading it is never worth it over just writing the same code section in native code and using a native call API, even the default way of writing your native code with Python.h involvement.

Re: How Python 3 Should Have Worked (2012)

#36

Post by pyre »

overgard wrote: post #22
rdtsc wrote: post #20

Earlier quoted context omitted.

I agree with your general point -- I haven't switched to Python 3 because it doesn't really solve anything I need solved at the moment. I would incur a significant time (=money) penalty for converting all my code to use it without a perceived benefit. I would have to get say a 30% speed increase or a 30% code # of lines decrease to get of my butt and start converting to Python 3. I want to in principle, don't get me…

Don't get me wrong. I use python professionally. I like it. I know about CFFI. I'm just saying, it has its warts.

> I'm just saying, it has its warts.

That statement is too broad to be useful though. All languages have warts.

Re: How Python 3 Should Have Worked (2012)

#37

Post by pyre »

pak wrote: post #32
rdtsc wrote: post #20

Earlier quoted context omitted.

I agree with your general point -- I haven't switched to Python 3 because it doesn't really solve anything I need solved at the moment. I would incur a significant time (=money) penalty for converting all my code to use it without a perceived benefit. I would have to get say a 30% speed increase or a 30% code # of lines decrease to get of my butt and start converting to Python 3. I want to in principle, don't get me…

>I hate implicit hidden defaults and assumptions. Your implicit hidden default is my handy abbreviation. Imagine if we didn't have contractions in English. For that previous sentence, is it really at all frightening that the "didn't" meant "did not" but we haven't (ha) written it out? Could it possibly mean anything else? Wouldn't English be all the more stilted and ugly if there were only one explicit and verbose wa…

This just seems like flamewar material, much in the same vein as programmers (brogrammers?) that get red in the face over Python cramping their style by forcing structure via whitespace.

Re: How Python 3 Should Have Worked (2012)

#38

Post by jerf »

pak wrote: post #28
crag wrote: post #18

Earlier quoted context omitted.

"... they should have had at least one killer feature" Or if Python 3 had included reliable (and updated) package and environment managers; and/or a default GUI framework (QT maybe) - out of the box. The fragmentation between Python 2 and Python 3 is killing the language. Not to mention the community. Python needs a united front.

> a default GUI framework Tkinter is Python's "default GUI framework". At least, that's what they continue to claim ( https://wiki.python.org/moin/TkInter ), and it's the GUI library I ran into first when I first learned Python. How does it look and feel once you get started? Well, let's just say it's a bad sign if a GUI framework website has no screenshots. Even with increasingly hacky theming engines layered on top…

People have been making the argument that QT or Wx should be the default for a while, the problem is and remains A: licensing or B: complexity of shipping "batteries included" distributions. For A, PyQT's license might surprise you: [1]. Python can not distribute this with the rest of the essentially-BSD-licensed Python distribution. For B, for instance, none of the linux distributions particularly want "Python", which is often a base requirement, to pull in either of Wx or QT, both of which are quite sizable, and require their own stack of other things to come piling in too.

It's sad, but I'm not sure how to resolve the problem, and nobody else has been either in the past 10 years.

[1]: http://www.riverbankcomputing.com/software/pyqt/license

Re: How Python 3 Should Have Worked (2012)

#39

Post by PythonicAlpha »

nostrademons wrote: post #11

This misses the point of why Python 3 was invented: Unicode. Python 2's string handling is broken in the presence of unicode characters, often leading to subtle errors that wouldn't cause exceptions until far away from the place where the error was introduced, and oftentimes didn't produce exceptions at all, just wrong data. Strings were defined as sequences of bytes, and then provided a .decode method to convert the…

About Unicode: It might be right, that this one would not be easy provided in compatible way. But what they did, was worse. They made it unnecessary difficult to change from Py2 to 3 -- one reason were the literals. In Py2 it was common to use u" for Unicode literals. Py3 did not accept that syntax at all, since every literal was Unicode -- logical, right? Wrong! Just stupid! Thus laying one roadblock for Py3. Many Unicode programs had thousands of places with these literals (syntax error!) -- change every one, and even worse, when you change it, then Py2 will not accept it any more, because in Py2, literals without u are not Unicode any more (and will raise a different error!).

In Py3.3 or so, they at last detected the problem and fixed at least this one ... but very late! Many programmers might have turned their backs to Py3 already.

Re: How Python 3 Should Have Worked (2012)

#40

Post by ambrop7 »

nostrademons wrote: post #11

This misses the point of why Python 3 was invented: Unicode. Python 2's string handling is broken in the presence of unicode characters, often leading to subtle errors that wouldn't cause exceptions until far away from the place where the error was introduced, and oftentimes didn't produce exceptions at all, just wrong data. Strings were defined as sequences of bytes, and then provided a .decode method to convert the…

Personally I dislike how Python3 is infected with Unicode. It introduces quite some complexity (and probably inefficiency) when all you want to do is work with bytes. Even if I am actually dealing with UTF-8, I should have a choice to treat it transparently, and basic logic says that it should be easier not harder than working on code point level. In particular what I dislike most is the complete removal of formatting on bytes (% and .format()).

I also believe that dealing with unicode more transparently is a very reasonable strategy. There are not many places where you actually have to deal with code points. Text formatting and rendering is one of those few places. Having the file i/o and standard streams do encoding/decoding by default goes against that design.

Post reply on HN