Hacker News Reader

Comment by Figs | Hacker News Reader

> Isn't that a bigger problem for Python 2.7 hold outs?

Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?

I've gotten a couple interesting responses here, and I hope for more. I wasn't really aware of f-strings -- that does seems like a nice-to-have feature -- and I wasn't aware of improved JSON serialization performance either.

> If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.

I may do that.

View on HN

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?

Most of mine have to do with developer productovity and I didn’t find until Python 3.5.

– @, the matmul operator

– fstrings (f”{foo}”)

– parameter typing (foo: int = 0) which has exciting work with Cython

– other async features. I forget what library it was (tensorflow?) but for Python 3 it had better async support

pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.

I haven't jumped into Python3 yet (for work/legacy reasons), but I'm really looking forward to nested exceptions and pathlib. Also, even when just working in English, unicode (or special classes for strings) were really annoying when interfacing with other libraries like Qt or databases.

Don't forget how nice super().__init__() is.

The double underscore methods are some of the ugliest parts of Python. If they were going to break compatibility, I'd get rid of them too.

I think you're right, only this wouldn't require breaking compatibility. It doesn't even require a python upgrade, you could just make a base class that remaps nicer named functions to the standard ones, like baseclass.is_lower_than = baseclass.__lt__

You're probably right. Sadly, the vast majority of the python upgrades probably did not require breaking compatibility. Or if they did, they weren't worth it. I understand that iterators are arguably better than lists and print should arguably be a real function, but those advantages are far too small to justify breaking compatibility.

Why is the super().__init__() comment dead below me? In Python 2 you had to do something like super(ClassName, self).__init__(), which is more ridiculous.

This could be because someone flagged the comment. If you believe there’s been a mistake you can vouch for a comment from comment’s page. I did vouch for x14 already—being able to shorten parent’s method calls into super().methodname() minor syntax sugar though it may be is one of the things I’m really looking forward to when I switch to Python 3 at my agency.

* Not only is print better as a function (I can now call print in a lambda!) doing anything beyond just printing variables (e.g. printing to a stream/file or suppressing the final newline) is both more straightforward and more readable. Also print(xxx, end="", flush=True) is my bae.

* API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params.

* Extended unpacking, and the ability to unpack in collection literals, make the language much more "expressive" (in the sense there are more cases where you can make do with just expressions) which is very convenient.

There are some great things about Python 3, and then there are some things that are more subjective. But we have to ask at what cost? Breaking compatibility has required developers to spend huge amounts of time porting and worrying about compatibility that they could have spent on other things. Many of the best features of Python 3 could be introduced in a backwards compatible way. Further, the language itself could have advanced much faster if it stuck with compatible changes. We could have had microthreads or a JIT by now.

Even if you like "print" as a function, is it really so important to wipe out the huge inventory of working Python 2 code and stall Python development for a decade? Python 3 is a tragedy.

> the language itself could have advanced much faster if it stuck with compatible changes. We could have had microthreads or a JIT by now.

That is asinine bullshit and you should be ashamed.

> stall Python development for a decade?

The development of Python never stalled, it barely even slowed.

> That is asinine bullshit and you should be ashamed. ... The development of Python never stalled, it barely even slowed.

Thanks for the language, but the only thing I'm ashamed of is Python's lost opportunities. How many thousands or perhaps millions of hours of developer time was spent on compatibility or maintaining two versions? What if that energy was directed on the improving the language instead. There's no question that it would be further along than it is now.

Er, maybe you never heard of Stackless Python (micro-threads) or PyPy (JIT)?

Of course I have, they were what I was referring to. If we didn't have to deal with this python 2/3 schism, there's a solid chance they'd be part of mainline python by now.

Thanks for the keyword-only parameters mention. I'm a Py3 fan so have been looking down this thread for inspiration of features I've missed. I've often wanted to use keyword arguments for readability but without supplying a default - this is just the ticket.

Indeed. Not enough people seem to be aware of the new dict merge feature introduce:

  merged_dict = {
      **source_dict1,
      **source_dict2,
      **{
          'some_key': 'w00t!'
      }
  }

> Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3.

Actually if you ever wrote code that you wanted to make backwards compatible with Python 2.7 is a nightmare. The fact that they did not even wait until 2020 before depreciating it is a testament to that.

> I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?

I don't know about others, I always been supporting Python 3 since 3.4. I feel like many people were complaining about Python 3, but never used it, then eventually started using and realized that it is not so bad.

> I may do that.

You should, is much more enjoyable experience. Perhaps because you're so used to Python 2, you don't notice, but Python 2 has a lot of warts that accumulated over the years.

There should have been more innovation, making Python 3 compelling enough for Numpy use to deprecate Python 2 in 2010 for obvious, noncontroversial technical reasons. Instead there has been a thoroughly unpleasant and glacially slow transition between "we have to support Python 3 for bleeding edge users" to "we have to support Python 2 for retro users".

Reply on news.ycombinator.com