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

New features you can't use unless you are in Python 3

asmeurer.com

Post reply on HN
Print view View original

201–210 of 264 posts

Re: New features you can't use unless you are in Python 3

#201

Post by sprash »

Fej wrote: post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

Yes. Following reasons:

* I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use cases. Also Unicode in 3.x support is rather flawed: http://www.cmlenz.net/archives/2008/07/the-truth-about-unico...

* Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. Everybody knows list, why not keep it simple. I can't count how often I list() all the things just to get things going and because I didn't bother to look up the API to check what types are returned.

* I have to convert a lot of clear text data formats and needing to use 'print(x, end=" ")' instead of a simple 'print x,' is really cumbersome. I think printing something is absolutely substantial and it is justified for "print" be a statement.

* There is a distinct performance loss if you directly compare 3.x to 2.x at least for all my use cases.

* The sudden harsh break of backwards compatibility was completely unnecessary and stupid. Why not introduce new features slow and mark old features as deprecated or allow to specify the version in the header. There are a lot of ways one could handle this better.

* Python 3.x may be a marginally better (e.g more consitent) language than 2.x. For me it only introduces inconveniences. It takes a huge amount of effort to port code from 2.x to 3.x (if you want to keep it clean and readable). The practical benefits are close to zero (and you even loose performance). This is why the community seems to agree to stay with 2.x for a very long time.

Re: New features you can't use unless you are in Python 3

#202

Post by evincarofautumn »

Animats wrote: post #104
dlbucci wrote: post #66

I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).

Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic ov…

Yup, overloading existing operators for new meanings is smelly. It’s better if the language allows creating new operators, so you’re not stepping on someone else’s semantics. For example, Haskell has “” in the “filepath” package as an alias of “combine”. Custom operators can certainly be abused, but most packages that define operators only do so for good reason, and crucially they’re still searchable with Hoogle.

Re: New features you can't use unless you are in Python 3

#203

Post by Animats »

evincarofautumn wrote: post #202
Animats wrote: post #104

Earlier quoted context omitted.

Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic ov…

Yup, overloading existing operators for new meanings is smelly. It’s better if the language allows creating new operators, so you’re not stepping on someone else’s semantics. For example, Haskell has “ ” in the “filepath” package as an alias of “combine”. Custom operators can certainly be abused, but most packages that define operators only do so for good reason, and crucially they’re still searchable with Hoogle.

You can even set the precedence of your new operator in Haskell, and confuse everybody. Maybe beyond +, -, *, and /, you should have to use parentheses.

Here's C's operator precedence.[1] All 15 levels.

Think of the maintenance programmer who will have to fix this.

[1] http://en.cppreference.com/w/c/language/operator_precedence

Re: New features you can't use unless you are in Python 3

#204

Post by dozzie »

dom0 wrote: post #133
dozzie wrote: post #68

Earlier quoted context omitted.

Oh my, it looks atrocious. Almost every time I see something introduced in Python 3 I have an impression that current Python envies Perl its baroque semantics, except that Perl usually tries to guess what the programmer meant, while with Python the relationship is reversed: the programmer needs to guess what the language wants. Python's main selling point was simplicity of syntax and semantics that preserved its high…

Python 2 is a vastly more complex language compared to Python 3. Just try to name the basic classes of types that exist in Python 2. Hint: Cannot be counted on two hands.

Well, try this for me, especially that you didn't use searchable terminology, so it's hard to confirm what you're saying. And then tell how much of that is important for typical code.

Re: New features you can't use unless you are in Python 3

#205

Post by jacobolus »

jacobolus wrote: post #173
jacquesm wrote: post #138

Earlier quoted context omitted.

> Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.

On the other hand, someone might just as well say “the cognitive overhead of reading domain-specific code is high enough without having to alias common operators”, where “common operators” here means within the domain, in the numpy example matrix algebra.

I guess s/alias/invent new names for/ in the above.

Re: New features you can't use unless you are in Python 3

#206

Post by ptx »

The slides on chained exceptions (feature 3) are missing one thing, I think. The "raise from" example is not really a way to "do this manually", but rather a way make explicit the relation between the two chained exceptions (as can be seen in the traceback messages), which is quite helpful.

The first example says that one error occurred, we tried to handle it, but then another error occurred in the handling. E.g. "Failed to find eggs in refrigerator. Tried to buy eggs, but tripped and broke leg."

The syntax in second example should be used when the exception in turn causes a larger process to fail, e.g. "Failed to make pancakes due to a failure to find eggs in refrigerator."

Re: New features you can't use unless you are in Python 3

#207

Post by evincarofautumn »

Animats wrote: post #203
evincarofautumn wrote: post #202

Earlier quoted context omitted.

Yup, overloading existing operators for new meanings is smelly. It’s better if the language allows creating new operators, so you’re not stepping on someone else’s semantics. For example, Haskell has “ ” in the “filepath” package as an alias of “combine”. Custom operators can certainly be abused, but most packages that define operators only do so for good reason, and crucially they’re still searchable with Hoogle.

You can even set the precedence of your new operator in Haskell, and confuse everybody. Maybe beyond +, -, *, and /, you should have to use parentheses. Here's C's operator precedence.[1] All 15 levels. Think of the maintenance programmer who will have to fix this. [1] http://en.cppreference.com/w/c/language/operator_precedence

Eh, I’ve gotten somewhat confusing type errors from mixing precedence levels in Haskell, but no bugs that I can recall. I’d like it if the levels were named instead of numbered, though—I have a hunch that the majority of operators fall into a family like “additive”, “multiplicative”, &c.

People have experimented with relative precedence levels (and I believe Perl6 does this?) where you can say “this is lower-precedence than that” and you have to use parentheses to disambiguate expressions that mix operators unrelated by that partial order.

Re: New features you can't use unless you are in Python 3

#208

Post by Volt »

mixmastamyk wrote: post #80
notsrg wrote: post #53

Earlier quoted context omitted.

You think someone is going to start a new project and use a 7 year old OS? I don't think it's "unfortunately my problem" when biz/client reqs for a 7 yo OS are completely out of my hands, unless of course the mindset is "use Python 3 or die trying".

And the other 96% of us can move on, no need to act like you're the majority. Py 2.6 is already EOL for almost five years.

>no need to act like you're the majority

Is he making that assumption, or are you?

Re: New features you can't use unless you are in Python 3

#209

Post by catdog »

rsj_hn wrote: post #76
Fej wrote: post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codeb…

> but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out.

Java contains a lot of ugly legacy bullshit because of that.

Re: New features you can't use unless you are in Python 3

#210

Post by iak8god »

baq wrote: post #181
iak8god wrote: post #164

Earlier quoted context omitted.

Can you expand on "mypy is a much better type system than Java"? I'd love it if that were true.

It has e.g. a proper Union type, generics and type inference. Lack of pattern matching hurts, but then, Java doesn't have that either. You can also configure how strict you want the checks to be. There are downsides though: type stubs are of... varying... quality, there are ugly hacks needed to resolve cyclic imports and the type annotation syntax gets yucky in places, even in 3.6. I'm using mypy seriously for about…

I'll check it out. Thanks!
Post reply on HN