4 ms·

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

> 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

JoBrad 9y ago
pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.
pfranz 9y ago
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 9y ago
Don't forget how nice super().__init__() is.
- speedplane 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
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 9y ago
  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.
masklinn 9y ago
* 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.
- speedplane 9y ago
  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 9y ago
    > 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 9y ago
      > 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.

JoBrad 9y ago

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

pfranz 9y ago

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 9y ago

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

speedplane 9y ago
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 9y ago
  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 9y ago
    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 9y ago

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 9y ago
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.

masklinn 9y ago

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

speedplane 9y ago
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 9y ago
  > 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 9y ago
    > 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.