Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

361–370 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#361

Earlier quoted context omitted.

> 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 be…

* 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 ab…

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

#362

Earlier quoted context omitted.

* 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 ab…

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…

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

Re: Numpy: Plan for dropping Python 2.7 support

#363
post #359
post #292

Earlier quoted context omitted.

Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues…

Let's be honest, A lot of peoples experience with Python is restricted to the North America. For these folks encountering anything other than ASCII is pretty uncommon. Personally, I've worked on a Python 2.x project deployed in heavy industry across the globe including Japan and the number of times we had Python 2 unicode nightmare issues was too many to mention.

For these folks encountering anything other than ASCII is pretty uncommon.

Hmmm... [THINKING FACE (U+1F914)]

Re: Numpy: Plan for dropping Python 2.7 support

#364
post #360
post #348

Earlier quoted context omitted.

You're mixing up two things: separating string types in the language, and using prefix literals. Completely orthogonal concerns. As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.

I don't think I am. In this thread you're repeatedly making the point that 2.7 supported Unicode and the difference is mostly technical details of things like internal representation and/or a matter of prefixes or whatnot. This just isn't true. The fundamental change is - in Python 2, strings are bags of bytes and in Python 3 strings are collections of Unicode codepoints and you need to go through an encoding to conv…

What I said:

1. BOTH Python 2 and Python 3 come with built-in support for BOTH bytestring and unicode (contrary to OP's claims I responded to)

2. That mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO)

3. Unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail)

4. It's good practice to be explicit about the type of literals, and write b"" and u"" always

5. That Python 2.7 doesn't support unicode is simply FUD.

Can you articulate which point you're actually contesting? I'll be happy to clarify, but I'm honestly unsure what you're responding to.

Re: Numpy: Plan for dropping Python 2.7 support

#365
post #281
post #122

I am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions. Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life. https://en.wikipedia.org/wiki/History_of_Python So what will happen when python 4 comes out?

GIL :) Larry is surely working on it.

For anyone interested: https://www.youtube.com/watch?v=pLqv11ScGsQ

Re: Numpy: Plan for dropping Python 2.7 support

#366
post #165

Earlier quoted context omitted.

Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewri…

There's also no push, whatsoever, to "get with the parrot program". Larry Wall is not holding a gun to Perl 5's head.

Unlike Python 3's relation to Python 2, Perl 6 is genuinely a new language. It would make little sense for the community to discontinue Perl 5 and push for Perl 6.

In retrospect it probably would have been better for the community if they'd given Perl 6 a new name.

Re: Numpy: Plan for dropping Python 2.7 support

#367
post #164

Earlier quoted context omitted.

>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…

Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…

Perl6 has nothing to do with perl5, it's a completely different language. I would call the transition fatal, not painful.

Re: Numpy: Plan for dropping Python 2.7 support

#368

Earlier quoted context omitted.

Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.

Wont they have a naming/versioning problem?

They have it already. Perl6 is about 10 years old, had at least 4 virtual machines. When it was announced people thought perl 5 was obsolete. And in the same time came RoR. A few years(like 7 maybe?) ago a some new developers took over perl5 and added some really interesting new features. That made some perl6 developers unhappy, wanting to focus community around perl6. Perl5 developers believe a completely new language should have a different name. Some suggested renaming perl5 perl7. Then there was a website perl11.org redirecting visitors to scala-lang.org. That was about 3 years ago. Since then - I don't care:) Perl6 will have to find itself a niche. The one once occupied by perl5 - a ducktape of the web is now taken by js. So, a long transition is better than a remote perspective of unknown transition.

Re: Numpy: Plan for dropping Python 2.7 support

#369
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Python is the ecosystem :)

Re: Numpy: Plan for dropping Python 2.7 support

#370
post #344
post #321

Earlier quoted context omitted.

I have moved away from Python 2.7 because unicode support was not good enough. Not good enough means I had to prefix every single string with "u" to make sure it's unicode. It was especially painful with code like this : logger.debug("Name of the person I'm debugging {}".format(name)) forgetting the "u" simply lead to various crashes if the name had characters that could not be encoded in whatever the debug was piped…

Well now you have to prefix b"" instead for bytestrings. The argument works both ways -- there's no magical improvement that happened in Python 3 (except that nice storage optimization in 3.3 that I mentioned above). It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.

u"" was reintroduced to avoid people of fixing all their strings (see PEP 414 rationale).

that was my point, by moving to python 3, I removed all my "u", the thing other developers not wanted (see PEP-414 again); I loved the "purity".

but removing u was tedious (at best).

In my use case, strings are "string" and binary are "bytes". Which I think is much safer.

Post reply on HN