4 ms·
Migrating where there’s a 1-1 mapping of old API to new API is easy, such as the print to print() change. The hard part is when there’s a 1-N mapping, where a
by MereInterest 4y ago
Migrating where there’s a 1-1 mapping of old API to new API is easy, such as the print to print() change. The hard part is when there’s a 1-N mapping, where a single name in the old API becomes multiple names in the new API. These are the most useful changes to make, because they can split apart unrelated concepts that had been erroneously represented by the same object, but require a human to determine which use case applies.
For python2, the str class could either contain a sequence of characters, or could contain a sequence of bytes. These are often conflated when using ASCII encoded text, but are very different for any other encoding. In python3, these are represented by the str class for a sequence of characters, and by the bytes class for a sequence of bytes. It’s so much nicer to work with, but required manually separating out the earlier use case.
- otabdeveloper4 4y agoPython2 had the 'unicode' class for characters, and the 'str' class for bytes. The whole 2 to 3 debacle was only because somebody thought that naming your string class 'unicode' doesn't sound nice enough or something.
- Izkata 4y agoAlso the default, what a no-prefix string like "foo" meant changed between the two versions.
- someguydave 4y agoRight, essentially the Python developers decided to define a sizable portion of their developer base as "bad people" due to their particular use of the string API and then spent years going to war with them. The war continues to this day apparently with this Debian news. Somehow you can use fortran77 compilers without people getting angry but you can't use Python2
- acdha 4y agoIt’s not that simple: as the person you’re responding to explained, this was leaky because in simple cases you could pretend those were equivalent but then things would break around interface points when someone introduced things like filenames with Unicode. I had clean Python 2 codebases which had been Unicode-safe for years and had good test coverage, so porting to Python 3 was trivial and mostly automated. The projects which were hard were the sloppy ones which conflated bytes and Unicode, and the poor development culture which lead to that also tended to mean they had limited testing, orphaned dependencies, monkey patching, etc. which made the migration hard. I also found a fair number of cases where that process fixed other bugs which had been ignored for years.