[skierscott]

> 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

[masklinn]

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

[philsheard]

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.

[speedplane]

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.

[masklinn]

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

[speedplane]

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

[OOPMan]

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

[speedplane]

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.

[OOPMan]

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

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

[pfranz]

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.

[x14]

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

[speedplane]

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.

[m_mueller]

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__

[speedplane]

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.

[cdelsolar]

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.

[goblin89]

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.

[JoBrad]

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