News for hackers. Stuff that matters.
Re:Numpy: Plan for dropping Python 2.7 support by Figs on Wednesday November 15, 2017 @06:20PM (#15708970)
> 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.

Re:Numpy: Plan for dropping Python 2.7 support by skierscott on Wednesday November 15, 2017 @06:42PM (#15709110)
> 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

Re:Numpy: Plan for dropping Python 2.7 support by masklinn on Thursday November 16, 2017 @04:07AM (#15711229)
* 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.

Re:Numpy: Plan for dropping Python 2.7 support by philsheard on Thursday November 16, 2017 @04:44AM (#15711391)
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.
Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Thursday November 16, 2017 @04:33AM (#15711341)
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.

Re:Numpy: Plan for dropping Python 2.7 support by masklinn on Thursday November 16, 2017 @04:55AM (#15711437)
> 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.

Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Thursday November 16, 2017 @04:59AM (#15711458)
> 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.

Re:Numpy: Plan for dropping Python 2.7 support by OOPMan on Thursday November 16, 2017 @01:27PM (#15715161)
Er, maybe you never heard of Stackless Python (micro-threads) or PyPy (JIT)?
Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Sunday November 19, 2017 @03:01AM (#15732835)
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.
Re:Numpy: Plan for dropping Python 2.7 support by OOPMan on Thursday November 16, 2017 @01:25PM (#15715143)
Indeed. Not enough people seem to be aware of the new dict merge feature introduce:

  merged_dict = {
      **source_dict1,
      **source_dict2,
      **{
          'some_key': 'w00t!'
      }
  }
Re:Numpy: Plan for dropping Python 2.7 support by pfranz on Wednesday November 15, 2017 @09:15PM (#15709813)
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.
Re:Numpy: Plan for dropping Python 2.7 support by x14 on Wednesday November 15, 2017 @09:22PM (#15709837)
Don't forget how nice super().__init__() is.
Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Thursday November 16, 2017 @04:34AM (#15711346)
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.
Re:Numpy: Plan for dropping Python 2.7 support by m_mueller on Thursday November 16, 2017 @08:02AM (#15712300)
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__
Re:Numpy: Plan for dropping Python 2.7 support by speedplane on Sunday November 19, 2017 @03:05AM (#15732841)
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.
Re:Numpy: Plan for dropping Python 2.7 support by cdelsolar on Thursday November 16, 2017 @12:14AM (#15710407)
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.
Re:Numpy: Plan for dropping Python 2.7 support by goblin89 on Thursday November 16, 2017 @01:14AM (#15710576)
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.
Re:Numpy: Plan for dropping Python 2.7 support by JoBrad on Wednesday November 15, 2017 @09:12PM (#15709808)
pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.
Re:Numpy: Plan for dropping Python 2.7 support by takeda on Wednesday November 15, 2017 @09:22PM (#15709836)
> 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.

Re:Numpy: Plan for dropping Python 2.7 support by HelloNurse on Thursday November 16, 2017 @06:26AM (#15711844)
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".