Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Port from Python 2 to Python 3 (2019)

stxnext.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: How to Port from Python 2 to Python 3 (2019)

#41

Post by baq »

ggregoire wrote: post #29
zojirushibottle wrote: post #9

Earlier quoted context omitted.

that's correct. sentry itself is on python 2.7, not the python client. not to pick on sentry here, but you know, my experience is that people are having a hard time migrating due to them using obscure tricks and features of python 2.7. so their code is breaking because the language evolved. the saying goes write dumb code or something because debugging is twice as hard. if there is anything to learn from all this, it…

Why would you even build a logs collector in python? Especially if it’s your core business and you know you will need scale and reliability. You kinda shoot yourself in the foot.

they're using python 2.7. perhaps started on an earlier one. maybe there was nothing except java 1.4 when they started.

Re: How to Port from Python 2 to Python 3 (2019)

#42

Post by lizmat »

segmondy wrote: post #13
ryandvm wrote: post #5

Python 3 and IPv6 are the poster-children of how _not_ to do a major upgrade. I'm not sure what the right way is, but if the short-term advantages of the upgrade do not outweigh the immediate pain, prepare for the matter to drag out for _decades_.

Upgrades are just hard. See perl5 to perl6 GWbasic to Qbasic to VB to VB.net you either make a clean break or keep all the warts, Either way folks are going to be unhappy. Keep the warts, COBOL, Fortran, C, C++, PHP, Excel

Rename Perl 6 to Raku. People happier.

Re: How to Port from Python 2 to Python 3 (2019)

#43

Post by zdw »

mixmastamyk wrote: post #35
zdw wrote: post #17

I've been doing a lot of Python 2 -> 3 lately, and found this to be one of the best actionable guides: https://portingguide.readthedocs.io/en/latest Also, using tox on the project to run tests against both python 2.7 and multiple versions of 3 and the work goes pretty quickly.

Looks like a lot of the guide assumes you want to run on Py2 and 3 concurrently. The time for that has passed to be honest. A clean port is easier to do.

For larger code bases making direct jump straight to Py3 that breaks Py2 compatibility without a transitional period can be problematic especially if it's a library.

The time may have passed, but lots of code is still out there that needs to be updated.

Re: How to Port from Python 2 to Python 3 (2019)

#44

Post by mixmastamyk »

zdw wrote: post #43
mixmastamyk wrote: post #35

Earlier quoted context omitted.

Looks like a lot of the guide assumes you want to run on Py2 and 3 concurrently. The time for that has passed to be honest. A clean port is easier to do.

For larger code bases making direct jump straight to Py3 that breaks Py2 compatibility without a transitional period can be problematic especially if it's a library. The time may have passed, but lots of code is still out there that needs to be updated.

Maintaining two branches shouldn’t be a problem. If you waited this long to port, velocity on the legacy branch can’t be especially high.

Now that I think of it the legacy branch should be eol soon.

Re: How to Port from Python 2 to Python 3 (2019)

#45

Post by MaxBarraclough »

badsectoracula wrote: post #8
ryandvm wrote: post #5

Python 3 and IPv6 are the poster-children of how _not_ to do a major upgrade. I'm not sure what the right way is, but if the short-term advantages of the upgrade do not outweigh the immediate pain, prepare for the matter to drag out for _decades_.

> I'm not sure what the right way is The right way is to make sure that stuff that used to work in the previous version still works in the current version. Breaking people's work, especially work that spans multiple years, projects, knowledge, etc and expecting them to be happy about it is naive. Being condescending when they turn out to not be happy and try to avoid the unnecessary busywork forced on them does not h…

> The right way is to make sure that stuff that used to work in the previous version still works in the current version.

But that too brings considerable downsides.

For all its merits, C++ is an extremely bloated language, getting even more complex every release, due in no small part to its commitment to backward compatibility.

There's no perfect answer. Python3's decision wasn't stupid, they just chose one downside over another.

Re: How to Port from Python 2 to Python 3 (2019)

#46

Post by badsectoracula »

MaxBarraclough wrote: post #45
badsectoracula wrote: post #8

Earlier quoted context omitted.

> I'm not sure what the right way is The right way is to make sure that stuff that used to work in the previous version still works in the current version. Breaking people's work, especially work that spans multiple years, projects, knowledge, etc and expecting them to be happy about it is naive. Being condescending when they turn out to not be happy and try to avoid the unnecessary busywork forced on them does not h…

> The right way is to make sure that stuff that used to work in the previous version still works in the current version. But that too brings considerable downsides. For all its merits, C++ is an extremely bloated language, getting even more complex every release, due in no small part to its commitment to backward compatibility. There's no perfect answer. Python3's decision wasn't stupid, they just chose one downside…

C++ bloated largely because they decided to make it bloated - they didn't had to, they just decided to shove in whatever new idea sounded good without much concern about the language's size.

But despite that i 100% guarantee you that people who actually use the language and have large codebases are really glad that C++ is backwards compatible and they do not have to waste time refactoring code that works.

Re: How to Port from Python 2 to Python 3 (2019)

#47

Post by badsectoracula »

rtpg wrote: post #27
badsectoracula wrote: post #8

Earlier quoted context omitted.

> I'm not sure what the right way is The right way is to make sure that stuff that used to work in the previous version still works in the current version. Breaking people's work, especially work that spans multiple years, projects, knowledge, etc and expecting them to be happy about it is naive. Being condescending when they turn out to not be happy and try to avoid the unnecessary busywork forced on them does not h…

The most painful breaking change was the string treatment. Breakage was necessary if you wanted to make it possible to have more confidence in the basic building blocks of python. If you make a mistake when making a tool, you can either leave it forever, permanently causing pain for users forever, or you can try to find a path to fix it. That being said, a Python 3.0 which was _just_ “can’t call encode in string, dec…

Free Pascal changed the string type some time ago to make it encoding aware (i'm not really a fan of the idea, but it was done for Delphi compatibility which is considered important by the FPC developers). I only had to change a handful of lines in my 10+ year old code (at the time, now it is older) to make things work (all were about treating the string as a byte array and manipulating the memory directly - i just changed the type to RawByteString which provides exactly that functionality).

AFAIK that was the biggest "breaking" change they introduced by far. In general have code from 2007 that compiles out of the box and this sort of stability is why i stick with FPC (and C) despite it being messy sometimes.

If you make a mistake when making a language or API you should make sure whatever fix you come up with will keep the existing code working, most common way being that the old API is implemented in terms of the new (even if slower, things will keep working) or in the case of languages, new stuff that can conflict with existing code can be opt-in (Free Pascal often uses compiler submodes for this).

Yes, this makes implementing the library/language harder but it is going to be a bit of extra work for the implementors in exchange for avoid A LOT of work for the users (especially when you consider all the combined time wasted in porting Python 2 to Python 3).

Re: How to Port from Python 2 to Python 3 (2019)

#48

Post by badsectoracula »

lizmat wrote: post #42
segmondy wrote: post #13

Earlier quoted context omitted.

Upgrades are just hard. See perl5 to perl6 GWbasic to Qbasic to VB to VB.net you either make a clean break or keep all the warts, Either way folks are going to be unhappy. Keep the warts, COBOL, Fortran, C, C++, PHP, Excel

Rename Perl 6 to Raku. People happier.

It makes sense if a language is so different and backwards incompatible than the previous version to just rename it to someone else.

Hence why a lot of people back in the day felt that Visual Basic .NET should be called Visual Fred instead :-P

Re: How to Port from Python 2 to Python 3 (2019)

#49

Post by rtpg »

magicalhippo wrote: post #38
rtpg wrote: post #27

Earlier quoted context omitted.

The most painful breaking change was the string treatment. Breakage was necessary if you wanted to make it possible to have more confidence in the basic building blocks of python. If you make a mistake when making a tool, you can either leave it forever, permanently causing pain for users forever, or you can try to find a path to fix it. That being said, a Python 3.0 which was _just_ “can’t call encode in string, dec…

The language we use at work (Delphi) changed its string type from ANSI to Unicode, and it took us less than a day to fix our ~500kloc code base, which does a _lot_ of string manipulations all over. This was due to the hard work the people behind Delphi had put down to make the transition as smooth as possible.

Python 2s issues went beyond the string encoding.

Some functions would return either bytes our text (in python 2 parlance, strings or Unicode) depending on the input. People would call decode on text (despite it only making sense on bytes).

Ultimately Python 2 encouraged a programming model where if you just tested with ASCII everything worked but the instant one of your library users put in an accented character or a kanji everything would blow up.

Just to make things clear: many python 2 programs operated on bytes thinking they were text. There isn’t really a way of resolving this API without user intervention on declaration of intent (not saying 3.0 was perfectly right but not every change can be made backwards compatible if you still have existing code)

Re: How to Port from Python 2 to Python 3 (2019)

#50

Post by deathanatos »

pjc50 wrote: post #32
deathanatos wrote: post #16

Earlier quoted context omitted.

> is that I can't remember an IPv6 address off by heart. IPv4 addresses just _feel_ so much more human-consumable than IPv6 addresses. Stop remembering numbers meant for a machine, and use DNS. It will make your life so much easier. I spend ~$15/yr for my personal DNS name & hosting, and I never want to memorize an IPv4 or v6 address ever again. > I have no idea what is using IPv6 and what's using IPv4 right now. Any…

You're correct that the ISPs are dragging their feet, despite it allegedly being for their benefit - but exactly the same breakage risks apply. The cost/benefit tradeoff doesn't look good to them. I just bought a new router. https://www.asus.com/uk/Networking/DSLAC68U/ It doesn't support IP6.

> I just bought a new router. https://www.asus.com/uk/Networking/DSLAC68U/ It doesn't support IP6. (sic)

That's not what your link says:

> while power users will love its IPv6 support

Post reply on HN