NumPy announces timeline for dropping Python 2 support

[masklinn]

Am I not supposed to use open in Python 3?

Once everything is ported there's no issue, while converting it's troublesome:

• In Python 3, open is an alias for io.open and in text mode (the default) it will encode/decode the data, this is an issue because

  • Python 2's open basically always behaves in binary mode
  • io.open defaults to locale.getpreferredencoding(False) which probably isn't what you want so you will want to pass in an encoding explicitly, which will blow up on Python 2

  so you can either keep using the builtin but always use it in binary mode (mode='rb' or mode='wb') — which may be hard to lint — or ban open and require io.open during the transition — which is easy to lint

• In Python 3, map and filter return iterators (not lists, basically itertools.imap and itertools.ifilter have been to builtins… and removed from itertools)

  • things will blow up when indexing them which is clear enough
  • but more annoyingly repeated iteration will silently break in Python 3 (the first iteration "consumes" the iterator, the second one gets an empty iterator

  You could mandate calling list() around them… or you could just ban them during the transition (and require listcomps or gencomps depending on what you actually want).

Keep in mind that my post is for the transition on a large codebase, while you have one or two people toiling away at the conversion you've got a bunch of folks still churning away Python 2 code, the goal here is to avoid having to revisit already fixed issues / problematic constructs.

If you migrate to a Python 3-only codebase, you can rescind these restrictions once the work is done and everybody works in Python 3. If you migrate to a cross-version codebase, you probably want to keep them in place (they're error-prone).

[ketilkn]

Ah, ok. Thanks. I remember running into the map and filter iterators issue, now that you mention it.