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

71–80 of 80 posts

Re: How Python 3 Should Have Worked (2012)

#71

Post by jerf »

digisign wrote: post #48
jerf wrote: post #38

Earlier quoted context omitted.

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.

PySide (thanks lambda) appears to be LGPL; "better" than PyQT, but still not shippable in the core Python distro without changing the license of the core distro.

I think that's as "good" as a QT binding can be, too; QT itself is LPGL (or commercial license).

Re: How Python 3 Should Have Worked (2012)

#72

Post by pcwalton »

skywhopper wrote: post #52
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…

I'll agree with this entirely. As a newcomer to Python, I found the explicit "self" argument to be confusing. And now I just find it irritating. It breaks convention with every other OO language; it's additional meaningless noise in method definitions; and most importantly it violates the convention used by nearly every other programming language I'm aware of, which is that method definition argument lists and method…

> It breaks convention with every other OO language

Lua, Go, and Rust all have explicit self.

Re: How Python 3 Should Have Worked (2012)

#73

Post by geocar »

nostrademons wrote: post #63
neild wrote: post #56

Earlier quoted context omitted.

It's exceedingly rare that you need a sequence of codepoints. As evidence, consider that the native string types in many languages with pervasive Unicode support, such as Java and C#, do not provide a codepoint sequence. Programs generally need to deal with textual data at one of three levels: 1. Manipulate strings and substrings. e.g., "does string x contain substring y"? Byte sequences of utf8 data are fine for thi…

The problem isn't access to individual codepoints, it's mixing strings with different encodings without any way of tracking the encoding or knowing that you're doing something wrong. UTF-8 everywhere works great when you can enforce it. On the level of an individual project, you can enforce it. On the level of a language ecosystem, you can't, and you need to . Otherwises you end up with some libraries who assume thei…

> it's a social one of how to get all the library authors on a language to agree on a convention of how to handle encoding.

Ok, but the solution isn't to make everyone rewrite their libraries by holding the future ransom if they do not.

It could have been real simple: let python track encoding when it's known and throw an exception if they mix oldstr(unknown) with newstr(py3).

In py3 modules newstr is str, and in py2 modules oldstr is str. Now you only have to fix the bits where they mix and the programmer can always choose to fix it in the new code.

Re: How Python 3 Should Have Worked (2012)

#74

Post by gbog »

EdwardDiego wrote: post #46
pak wrote: post #43

Earlier quoted context omitted.

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.

>> GVR himself has acknowledged everything I said

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

Read it and for me he did not acknowledge anything at all.

Re: How Python 3 Should Have Worked (2012)

#75

Post by winstonian »

pessimizer wrote: post #10
jfaucett wrote: post #3

This strategy makes a lot of sense to me. I really like the "deprecated warnings" to "explicit failure" transitions, IMO this works really well, though I only have experience with it at a library level using semver. So cant say much about point #1, except that this is essentially what you're doing when you test agains xlib-head branch. Aaron implies that this approach was not taken with Python (non-py guy here), coul…

This link is posted from the [dead] winstonian: http://python-future.org/

Why am I listed as [dead]?

Re: How Python 3 Should Have Worked (2012)

#76

Post by overgard »

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…

Well sure, I wouldn't go with #2 either, but the GIL blocks you from doing fast processing in your C thread while the rest of the program continues because it's locked the entire process. So whether you write native code or not, you're stuck to one processor.

Re: How Python 3 Should Have Worked (2012)

#77

Post by overgard »

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 needs more upvotes. You're exactly right.

Re: How Python 3 Should Have Worked (2012)

#79

Post by crdoconnor »

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…

The solution is to stop shipping with batteries included and let people install via pip. Python could have an official opinion on what the best libraries are (might not be such a bad idea, actually), but they shouldn't bundle them unless they're very, very stable, tested and almost unchanging.

Requests might make a good addition to the standard library at some point. PyQT definitely shouldn't though.

Re: How Python 3 Should Have Worked (2012)

#80

Post by fulafel »

overgard wrote: post #76
zanny wrote: post #35

Earlier quoted context omitted.

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

Well sure, I wouldn't go with #2 either, but the GIL blocks you from doing fast processing in your C thread while the rest of the program continues because it's locked the entire process. So whether you write native code or not, you're stuck to one processor.

No, even Python's own C code releases it when doing things like IO.
Post reply on HN