5 ms·

What's use of Python 2 if you can't use libraries[1]? It will only get more difficult to maintain your app. [1] https://python3statement.org/ https://python3s

by takeda 7y ago

What's use of Python 2 if you can't use libraries[1]? It will only get more difficult to maintain your app. [1] https://python3statement.org/ https://python3statement.org/ - note many libraries weren't even waiting until 2020. It is a lot of work to maintain code with python 2 cruft. Not all packages are listed there, for example Django is Python 3 only, starting from 2.0 (currently at 3.0)

philwelch 7y ago
The problem isn't that Python 2 is bad. Python 2 is a fantastic language. The problem is that the maintainers of Python decided to break backwards compatibility and force library developers to support what are essentially two different programming languages.
- kstrauser 7y ago
  I don’t think there was any clear path around that, though. The single biggest change was that Python 2 pretended that text and binary data were the same datatype, where Python 3 correctly makes you distinguish between the two. There’s not really a great way to roll out that major change without breaking tons of stuff along the way. And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride.
  - someguydave 7y ago
    > correctly Sometimes it’s better to be correct and also yield to the common good.
  - afiori 7y ago
    some would say that the distinction was in the wrong places, like assuming that the command line arguments or file paths were utf8
    - int_19h 7y ago
      Python 3 does not make such assumptions; it uses the appropriate locale encoding. (IIRC it used to do that in 3.0, but they backtracked very quickly - and 3.0 was effectively treated as a beta by the community at large, anyway.)
    - ynik 7y ago
      Fundamentally, the "right place" here differs between Windows and Linux. On Windows, command line arguments really are unicode (UTF-16 actually). On Linux, they're just bytes. In Python 2, on Linux you got the bytes as-is; but on Windows you got the command line arguments converted to the system codepage. Note that the Windows system codepage generally isn't a Unicode encoding, so there was unavoidable data loss even before the first line of your code started running (AFAIK neither sys.argv nor sys.environ had a unicode-supporting alternative in Python 2). However, on Linux, Python 2 was just fine. Now with Python 3 it's the other way around -- Windows is fine but Linux has issues. However, the problems for linux are less severe: often you can get away with assuming that everything is UTF-8. And you can still work with bytes if you absolutely need to.
      - pdonis 7y ago
        > On Windows, command line arguments really are unicode (UTF-16 actually) No, they're not. Windows can't magically send your program Unicode. It sends your program strings of bytes, which your program interprets as Unicode with the UTF-16 encoding. The actual raw data your program is being sent by Windows is still strings of bytes. > you can still work with bytes if you absolutely need to In your own code, yes, you can, but you can't tell the Standard Library to treat sys.std{in|out|err} as bytes, or fix their encodings (at least, not until Python 3.7, when you can do the latter), when it incorrectly detects the encoding of whatever Unicode the system is sending/receiving to/from them. > AFAIK neither sys.argv nor sys.environ had a unicode-supporting alternative in Python 2) That's because none was needed. You got strings of bytes and you could decode them to whatever you wanted, if you knew the encoding and wanted to work with them as Unicode. That's exactly what a language/library should do when it can't rely on a particular encoding or on detecting the encoding--work with the lowest common denominator, which is strings of bytes.
  - philwelch 7y ago
    And that raises an obvious question: why didn’t every other programming language immediately break backwards compatibility when UTF-8 became a de facto standard? > And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride. Sorry, that doesn’t track. Treating quoted strings as UTF-8 by default instead of ASCII-or-arbitrary-bytes would have been a small migration that would not have taken over a decade to complete.
    - b2gills 7y ago
      The way Perl dealt with this was to have you declare when you are using UTF8. # declare that the code itself is written in utf8 use utf8; my $ā = 'ā'; If you need unicode strings to work, you turn on the unicode strings feature. use feature 'unicode_strings'; Another way to turn it on: use v5.12; (Declaring which version of the language you need is something you should do anyway.) Really mostly what you have to do is declare the encodings of the file handles. # change it for all files use open ':encoding(UTF-8)'; To change it per file handle, you would use `binmode`. (Which was originally added to allow binary code to work on Windows.) open my $fh, '<', 'example.txt'; binmode $fh, ':utf8'; (Declaring the encoding of an opened file is something you should do anyway.) --- Basically Perl just defaults to the old original ways. If you need a new feature which would break old code, you just declare that you need it. Because of that, most code that was written for an earlier form of Perl still works on the latest version.
    - takeda 7y ago
      Because many of these languages were created when Unicode already existed. Someone listed Java and Javascript, both of them started from the point that python 3 tries to bring. When python was written in 1989 Unicode didn't exist yet. As for your second argument, many people bring out Go, that had such amazing idea of using everything as UTF-8 and it works great. They don't realize that Go is pretty much doing the same thing that Python does (ignoring how the string is represented internally, since that shouldn't really be programmer's concern). Go clearly distinguishes between string (string type) and bytes ([]byte type) to use string as bytes you have to cast it to []byte and to convert bytes to string you need to cast them to string. That's the equivalent of doing variable.encode() to get bytes and you do variable.decode() to get a string. What python 3 inroduced is two types str and bytes, and blocked any implicit casting between them. That's exactly same thing Go does. The only difference is implementation detail, Go stores strings as utf-8 and casting doesn't require any work, they are just for having compiler catch errors it also ignores environment variables and always uses utf-8. Python has an internal[1] representation and does do conversion. It respects LANG and other variables and uses that for stdin/out/err. Initially when those variables were undefined it assumed us-ascii which created some issues, but I believe now that was fixed and utf-8 is the default. [1] Python 3 actually tries to be smart and uses UCS1 (Latin 1), UCS2 or UCS4 depending what characters are contained. If an UTTF-8 conversion was requested it will also cache that representation (as a C-string) so it won't do the conversion next time.
josefx 7y ago
> What's use of Python 2 if you can't use libraries[1]? Unless some python 3 fanatic goes out of his way to write a python 2 library deleting virus the existing code wont disappear. Also some of these pledges only limit feature releases, afaik numpy planned to still provide a long term support version with bugfixes for python 2. It also helps that python already comes with a lot of build in bells and whistles so third party libraries aren't always necessary either.
- takeda 7y ago
  Sorry I wasn't clear nothing happens if your application doesn't change, but if you do sooner or later you'll be forced to upgrade your dependencies (could be a bug that you just found, maybe a bug, or maybe a performance improvement) if the updated version won't work on your python it will be tough. You'll have choice to either migrate your app to python 3 or fork the library and backport fixes. You might be lucky and someone else might do that for you, but it will be harder and harder with time. Already according to JetBrains survey in 2019 (I believe) about 80% of people surveyed they already use python 3. As for numpy I just checked[1] and the only wheels they are providing for the latest version are 3.5+ the package also says that it is 3 only. [1] https://pypi.org/project/numpy/#files https://pypi.org/project/numpy/#files
adrianN 7y ago
You can keep using the libraries you're already using. That's totally fine for many applications.

by takeda 7y ago

philwelch 7y ago

The problem isn't that Python 2 is bad. Python 2 is a fantastic language. The problem is that the maintainers of Python decided to break backwards compatibility and force library developers to support what are essentially two different programming languages.

kstrauser 7y ago
I don’t think there was any clear path around that, though. The single biggest change was that Python 2 pretended that text and binary data were the same datatype, where Python 3 correctly makes you distinguish between the two. There’s not really a great way to roll out that major change without breaking tons of stuff along the way. And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride.
- someguydave 7y ago
  > correctly Sometimes it’s better to be correct and also yield to the common good.
- afiori 7y ago
  some would say that the distinction was in the wrong places, like assuming that the command line arguments or file paths were utf8
  - int_19h 7y ago
    Python 3 does not make such assumptions; it uses the appropriate locale encoding. (IIRC it used to do that in 3.0, but they backtracked very quickly - and 3.0 was effectively treated as a beta by the community at large, anyway.)
  - ynik 7y ago
    Fundamentally, the "right place" here differs between Windows and Linux. On Windows, command line arguments really are unicode (UTF-16 actually). On Linux, they're just bytes. In Python 2, on Linux you got the bytes as-is; but on Windows you got the command line arguments converted to the system codepage. Note that the Windows system codepage generally isn't a Unicode encoding, so there was unavoidable data loss even before the first line of your code started running (AFAIK neither sys.argv nor sys.environ had a unicode-supporting alternative in Python 2). However, on Linux, Python 2 was just fine. Now with Python 3 it's the other way around -- Windows is fine but Linux has issues. However, the problems for linux are less severe: often you can get away with assuming that everything is UTF-8. And you can still work with bytes if you absolutely need to.
    - pdonis 7y ago
      > On Windows, command line arguments really are unicode (UTF-16 actually) No, they're not. Windows can't magically send your program Unicode. It sends your program strings of bytes, which your program interprets as Unicode with the UTF-16 encoding. The actual raw data your program is being sent by Windows is still strings of bytes. > you can still work with bytes if you absolutely need to In your own code, yes, you can, but you can't tell the Standard Library to treat sys.std{in|out|err} as bytes, or fix their encodings (at least, not until Python 3.7, when you can do the latter), when it incorrectly detects the encoding of whatever Unicode the system is sending/receiving to/from them. > AFAIK neither sys.argv nor sys.environ had a unicode-supporting alternative in Python 2) That's because none was needed. You got strings of bytes and you could decode them to whatever you wanted, if you knew the encoding and wanted to work with them as Unicode. That's exactly what a language/library should do when it can't rely on a particular encoding or on detecting the encoding--work with the lowest common denominator, which is strings of bytes.
- philwelch 7y ago
  And that raises an obvious question: why didn’t every other programming language immediately break backwards compatibility when UTF-8 became a de facto standard? > And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride. Sorry, that doesn’t track. Treating quoted strings as UTF-8 by default instead of ASCII-or-arbitrary-bytes would have been a small migration that would not have taken over a decade to complete.
  - b2gills 7y ago
    The way Perl dealt with this was to have you declare when you are using UTF8. # declare that the code itself is written in utf8 use utf8; my $ā = 'ā'; If you need unicode strings to work, you turn on the unicode strings feature. use feature 'unicode_strings'; Another way to turn it on: use v5.12; (Declaring which version of the language you need is something you should do anyway.) Really mostly what you have to do is declare the encodings of the file handles. # change it for all files use open ':encoding(UTF-8)'; To change it per file handle, you would use `binmode`. (Which was originally added to allow binary code to work on Windows.) open my $fh, '<', 'example.txt'; binmode $fh, ':utf8'; (Declaring the encoding of an opened file is something you should do anyway.) --- Basically Perl just defaults to the old original ways. If you need a new feature which would break old code, you just declare that you need it. Because of that, most code that was written for an earlier form of Perl still works on the latest version.
  - takeda 7y ago
    Because many of these languages were created when Unicode already existed. Someone listed Java and Javascript, both of them started from the point that python 3 tries to bring. When python was written in 1989 Unicode didn't exist yet. As for your second argument, many people bring out Go, that had such amazing idea of using everything as UTF-8 and it works great. They don't realize that Go is pretty much doing the same thing that Python does (ignoring how the string is represented internally, since that shouldn't really be programmer's concern). Go clearly distinguishes between string (string type) and bytes ([]byte type) to use string as bytes you have to cast it to []byte and to convert bytes to string you need to cast them to string. That's the equivalent of doing variable.encode() to get bytes and you do variable.decode() to get a string. What python 3 inroduced is two types str and bytes, and blocked any implicit casting between them. That's exactly same thing Go does. The only difference is implementation detail, Go stores strings as utf-8 and casting doesn't require any work, they are just for having compiler catch errors it also ignores environment variables and always uses utf-8. Python has an internal[1] representation and does do conversion. It respects LANG and other variables and uses that for stdin/out/err. Initially when those variables were undefined it assumed us-ascii which created some issues, but I believe now that was fixed and utf-8 is the default. [1] Python 3 actually tries to be smart and uses UCS1 (Latin 1), UCS2 or UCS4 depending what characters are contained. If an UTTF-8 conversion was requested it will also cache that representation (as a C-string) so it won't do the conversion next time.

josefx 7y ago

> What's use of Python 2 if you can't use libraries[1]? Unless some python 3 fanatic goes out of his way to write a python 2 library deleting virus the existing code wont disappear. Also some of these pledges only limit feature releases, afaik numpy planned to still provide a long term support version with bugfixes for python 2. It also helps that python already comes with a lot of build in bells and whistles so third party libraries aren't always necessary either.

takeda 7y ago
Sorry I wasn't clear nothing happens if your application doesn't change, but if you do sooner or later you'll be forced to upgrade your dependencies (could be a bug that you just found, maybe a bug, or maybe a performance improvement) if the updated version won't work on your python it will be tough. You'll have choice to either migrate your app to python 3 or fork the library and backport fixes. You might be lucky and someone else might do that for you, but it will be harder and harder with time. Already according to JetBrains survey in 2019 (I believe) about 80% of people surveyed they already use python 3. As for numpy I just checked[1] and the only wheels they are providing for the latest version are 3.5+ the package also says that it is 3 only. [1] https://pypi.org/project/numpy/#files https://pypi.org/project/numpy/#files

adrianN 7y ago

You can keep using the libraries you're already using. That's totally fine for many applications.