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

181–190 of 264 posts

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

#181

Post by baq »

iak8god wrote: post #164
baq wrote: post #148

Earlier quoted context omitted.

if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.

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 a year and it's progressing very well. I see very good ROI even with the uglification of the code.

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

#182

Post by soperj »

chestervonwinch wrote: post #32
Fej wrote: post #20

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

Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be…

I was the same, and switched to py3 last year because i felt like it didn't really matter, so might as well get off of python2.

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

#183

Post by jacquesm »

dragonwriter wrote: post #144
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.

> The cognitive overhead of reading code is high enough without having to alias common operators. The cognitive overhead of reading code is, IME, often lower with context-approprate operator overloading (just as it is with well-chosen vs. poorly-chosen method names.) There is a reason human languages (and, yes, even the notation of mathematics) develops context-specific dialects, and it is to reduce the cognitive ove…

The difference between an operator and an appropriately named function is small enough that in most (but not all, I'll give you that) cases overloaded operators tend to confuse more than they enlighten.

I've worked for a while on a C++ vector/matrix library which made good use of C++'s capabilities to overload operators. It all made sense, in the beginning. But as time wore on and more and more exceptions crept in you'd get very confusing bits of code where in the same fragment '+' would mean one thing, then another, ditto for '*' and endless frustration when no free operator could be overloaded and in the end you'd end up having to call a function anyway.

Maintaining that over the years got less and less pleasant, even if at the start it was probably some of the cleanest code for the limited purpose that it had.

Personally, I avoid operator overloading, just as I try to avoid reader macros and other clever bits. It's not that I don't know how to use them or how they work, it's that I love being able to look at a piece of code without also having to study the environment it operates in in order to know what it does.

KISS. Though, adding two vectors or multiplying a vector and a matrix with just an operator looks very good. Better than:

   result_matrix = vec_mat_mul(some_vec, some_matrix);

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

#184

Post by ethbro »

Diederich wrote: post #176
dragonwriter wrote: post #144

Earlier quoted context omitted.

> The cognitive overhead of reading code is high enough without having to alias common operators. The cognitive overhead of reading code is, IME, often lower with context-approprate operator overloading (just as it is with well-chosen vs. poorly-chosen method names.) There is a reason human languages (and, yes, even the notation of mathematics) develops context-specific dialects, and it is to reduce the cognitive ove…

I'm pleased to see this perspective represented; it's the main reason I still really love the Perl programming language. The idea that context is useful and can actually help with clarity is a core concept.

The problem is that a reasonable context response is different from person to person and culture to culture.

I feel like this makes things like using operator overloading to clean up code incredibly dangerous, especially in popular libraries.

Best: Context-appropriate overload that makes sense to me

Good: Standard language meaning that may not fit cleanly in context, but has the same definition always

Worst: Context-appropriate overload that doesn't make sense to me

So if you aren't sure whether or not your clever idea will actually fall in the third category for some people, go with the second instead of pushing for the first.

Aka, "for every story someone can tell of a magical operator overloading that makes code more readable, I can come up with some dumbass architect who did the most counterintuitive thing you can imagine."

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

#185

Post by dragonwriter »

jacquesm wrote: post #183
dragonwriter wrote: post #144

Earlier quoted context omitted.

> The cognitive overhead of reading code is high enough without having to alias common operators. The cognitive overhead of reading code is, IME, often lower with context-approprate operator overloading (just as it is with well-chosen vs. poorly-chosen method names.) There is a reason human languages (and, yes, even the notation of mathematics) develops context-specific dialects, and it is to reduce the cognitive ove…

The difference between an operator and an appropriately named function is small enough that in most (but not all, I'll give you that) cases overloaded operators tend to confuse more than they enlighten. I've worked for a while on a C++ vector/matrix library which made good use of C++'s capabilities to overload operators. It all made sense, in the beginning. But as time wore on and more and more exceptions crept in yo…

> But as time wore on and more and more exceptions crept in you'd get very confusing bits of code where in the same fragment '+' would mean one thing, then another, ditto for '*' and endless frustration when no free operator could be overloaded and in the end you'd end up having to call a function anyway.

The problem here seems to me to be “having too small a space of valid operators in the host language for the problem domain” more than “operator overloading”, as such. But it's true that the space of available operators is a factor in whether you should use operators over functions for a particular use, because it definitely impacts clarity.

IMO, ideally a language should support a wide range of operators, a d programmers should be very selective in how they use them; additionally, overloaded operators in libraries intended for reuse should usually have equivalent text-named functions/methods, for when the library is used in contexts where using the overloaded operators would be confusing. (Ideally, you'd be able to import selectively so that you don't even bring the operators in scope where you don't want to use them.)

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

#186

Post by nayuki »

iak8god wrote: post #164
baq wrote: post #148

Earlier quoted context omitted.

if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.

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

mypy can help you ensure that a variable is never None, whereas it's still tedious to manually check for null in Java.

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

#187

Post by jacquesm »

dragonwriter wrote: post #185
jacquesm wrote: post #183

Earlier quoted context omitted.

The difference between an operator and an appropriately named function is small enough that in most (but not all, I'll give you that) cases overloaded operators tend to confuse more than they enlighten. I've worked for a while on a C++ vector/matrix library which made good use of C++'s capabilities to overload operators. It all made sense, in the beginning. But as time wore on and more and more exceptions crept in yo…

> But as time wore on and more and more exceptions crept in you'd get very confusing bits of code where in the same fragment '+' would mean one thing, then another, ditto for '*' and endless frustration when no free operator could be overloaded and in the end you'd end up having to call a function anyway. The problem here seems to me to be “having too small a space of valid operators in the host language for the prob…

> additionally, overloaded operators in libraries intended for reuse should usually have equivalent text-named functions/methods, for when the library is used in contexts where using the overloaded operators would be confusing.

Ok, but in that case you need two systems to access the same code, that only adds to the confusion and really negates all upside from having the overloaded operator in the first place.

That violates DRY in a very ugly way.

Anyway, I think we can agree on one thing: operator overloading is something that one should not do just because it is possible, but only for very good reasons.

Does that work?

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

#188

Post by nayuki »

deathanatos wrote: post #96
seanp2k2 wrote: post #49

Earlier quoted context omitted.

Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.

I don't think print() is what I'd call "compelling", but I for one am quite glad to see this go: print "Text", For those not familiar with Python 2's syntax: that trailing comma is significant. And it's pure syntax; it's not the creation of a tuple either…

It gets weirder in the old syntax when you specify an output stream:

    print >>sys.stderr, "Spam"
Whereas in the new print function it's a keyword argument:

    print("Spam", file=sys.stderr)

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

#189

Post by dragonwriter »

jacquesm wrote: post #187
dragonwriter wrote: post #185

Earlier quoted context omitted.

> But as time wore on and more and more exceptions crept in you'd get very confusing bits of code where in the same fragment '+' would mean one thing, then another, ditto for '*' and endless frustration when no free operator could be overloaded and in the end you'd end up having to call a function anyway. The problem here seems to me to be “having too small a space of valid operators in the host language for the prob…

> additionally, overloaded operators in libraries intended for reuse should usually have equivalent text-named functions/methods, for when the library is used in contexts where using the overloaded operators would be confusing. Ok, but in that case you need two systems to access the same code, that only adds to the confusion and really negates all upside from having the overloaded operator in the first place. That vi…

> That violates DRY in a very ugly way.

I don't think aliasing (or the moral equivalent, where operator vs. method/function can't be an alias from an implementation point of view) violates DRY. Presenting an alternative API for different use cases isn't repetition.

> Anyway, I think we can agree on one thing: operator overloading is something that one should not do just because it is possible, but only for very good reasons.

We agree on that.

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

#190

Post by rsj_hn »

worldeight wrote: post #141
rsj_hn wrote: post #76

Earlier quoted context omitted.

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…

As an independent contractor maintaining large Python 2 codebases, your comments really hit home for me. I only have a portion of my time each month to maintain and develop features for them. If the Python 2 floodgate ever breaks, I am more likely to rewrite the system in a statically typed language. Even today, I am tempted. I know that a sibling mentions the ridiculousness of the situation, but a forced depreciatio…

This. I don't think people realize that there are fixed costs that are born in making these kinds of migrations so that migrating to Java from python is not 100x more work than migrating from python 2 to python 3. There is no such thing as a small breaking change to a runtime.

Maybe one way of thinking about it is to take a hard drive full of data and randomly flip a few bits. Then ask what the effort is to find and fix all the errors, and whether this effort is a function of the number of bits flipped or the size of the drive. The people who don't understand/have sympathy with my concerns are saying -- it will only introduce a few breaking changes -- but I'm looking at the size of the project.

But this condescending attitude coming from some in the python community really isn't helping the language any. I am not saying that everyone has to share my concerns, but they certainly aren't "nonsense" or "ridiculous".

Post reply on HN