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

41–50 of 80 posts

Re: How Python 3 Should Have Worked (2012)

#41

Post by glynjackson »

quote from python.org: "New to Python or choosing between Python 2 and Python 3? Read Python 2 or Python 3." "Which version you ought to use is mostly dependent on what you want to get done."

No other language I have ever worked with speaks like this. "New to Rudy? You could use version 2.1 or why not try version 1.0, it still works ok"

Python.org treats version 2 and 3 as completely different things, newbies to the language like myself don't see it as a update to Python 2.x because thats not how it's sold to us.

Re: How Python 3 Should Have Worked (2012)

#42

Post by jdiez17 »

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…

You are right, this is exactly what's wrong with Python. I use Python as my "daily driver" in terms of programming but I have some pet peeves, which you enumerated for the most part.

Special emphasis on the multicore stuff. It's just dreadful. I tried to build a complex processing system on top of `multiprocessing` and friends but just had to give up because it doesn't work half the time for obscure reasons (here's a fun one: you can't call a function from a `multiprocessing.Pool` if the function had been defined after the pool was instantiated. wat.) I just drank the kool-aid and used Celery, which is awesome, but I shudder every time I think about how many sacrifices must've been made to make it work.

Re: How Python 3 Should Have Worked (2012)

#43

Post by pak »

pyre wrote: post #37
pak wrote: post #32

Earlier quoted context omitted.

>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.

It's not flamewar material. GVR himself has acknowledged everything (edit in response to @EdwardDiego: most of what) I said. (http://neopythonic.blogspot.com/2008/10/why-explicit-self-ha...) The main contention holding back GVR and 3.1 from fixing this once and for all is that decorators currently need to manipulate the explicit self. From my perspective, it seems like Python decorators are [ab]used to reimplement basic features in other OOP systems, like class methods, and there are elegant ways of getting around this given a shift in certain concepts (like class << self in Ruby). It's odd to me that they were willing to break so much code with 3.0 (by "fixing" strings and Unicode) but a couple decorators held this one back.

Re: How Python 3 Should Have Worked (2012)

#44

Post by jdiez17 »

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…

Just for the record, you can do cool stuff that you couldn't do (as easily) if you had implicit `self`. Here's an example[1] that I'm moderately proud of.

[1] https://github.com/MediaCrush/PyCrush/blob/master/pycrush.py...

Re: How Python 3 Should Have Worked (2012)

#45

Post by alberth »

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…

These all sound like reason to use Lua over Python then (and especially LuaJIT for FFI).

Re: How Python 3 Should Have Worked (2012)

#46

Post by EdwardDiego »

pak wrote: post #43
pyre wrote: post #37

Earlier quoted context omitted.

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.

It's not flamewar material. GVR himself has acknowledged everything (edit in response to @EdwardDiego: most of what) I said. ( http://neopythonic.blogspot.com/2008/10/why-explicit-self-ha... ) The main contention holding back GVR and 3.1 from fixing this once and for all is that decorators currently need to manipulate the explicit self. From my perspective, it seems like Python decorators are [ab]used to reimplement…

> GVR himself has acknowledged everything I said

I hate to be picky, but he only acknowledged portions of what you said.

> but a couple decorators held this one back.

@classmethod and @staticmethod are somewhat important language features to not break.

Re: How Python 3 Should Have Worked (2012)

#47

Post by m_mueller »

zanny wrote: post #35
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…

> 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 mov…

While your approach works most of the time, there are many cases where there isn't such a thing as a 'critic section' or a 'hotloop'. Performance relevant sections can be spread out into hundreds of places and reimplementing all of them can be less efficient than a complete rewrite. Guessing the performance characteristics of complex programs (e.g. not just computational in nature) is hard, and therefore so is the language choice.

Re: How Python 3 Should Have Worked (2012)

#48

Post by digisign »

jerf wrote: post #38
pak wrote: post #28

Earlier quoted context omitted.

> 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", whi…

There's a new alternative to pyqt, though its name escapes me now.

Re: How Python 3 Should Have Worked (2012)

#49

Post by digisign »

pak wrote: post #43
pyre wrote: post #37

Earlier quoted context omitted.

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.

It's not flamewar material. GVR himself has acknowledged everything (edit in response to @EdwardDiego: most of what) I said. ( http://neopythonic.blogspot.com/2008/10/why-explicit-self-ha... ) The main contention holding back GVR and 3.1 from fixing this once and for all is that decorators currently need to manipulate the explicit self. From my perspective, it seems like Python decorators are [ab]used to reimplement…

They said they weren't going to fix everything with Py3.

Re: How Python 3 Should Have Worked (2012)

#50

Post by ak217 »

bdarnell wrote: post #24
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…

The Unicode solution chosen by Python 3 required a major backwards incompatibility, but that wasn't the only possible solution to Python 2's Unicode problems. The biggest problem in Python 2 was simply that the implicit conversion between bytes and characters used the ascii codec and would fail if any non-ASCII characters were found. Python 3 chose to solve this problem by forcing the developer to specify a codec exp…

This! Exactly this. The stupid decision to use ascii as the default codec (and to disobey the system locale while doing so!), combined with silent Unicode coercion, doomed Python 2 to a lifetime of i18n pain. Just changing those two behaviors would have provided a much more evolutionary path forward without opening the Python 2 to 3 chasm.
Post reply on HN