sed -i 's/print \("[^"]*"\)/print(\1)'
How to Port from Python 2 to Python 3 (2019)
21–30 of 51 posts
Re: How to Port from Python 2 to Python 3 (2019)
#22Python 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_.
IPv6 is a perfect example of the second-system effect [1] as in it added a bunch of things no one needed (but might need someday) and didn't solve roaming. All IPv4 really needed was a bigger address space.
But as soon as you cross the mental threshold of making a breaking change (which expanding the IPv4 address space obviously was) then it's easier to convince yourself to make a bunch more breaking changes. And this is where Python3 really lost its way (IMHO).
One of the silliest design decisions in Python3 was (initially) removing the string prefixes like s and u. Now obviously Python2 defaulted to ASCII and Python3 defaulted to Unicode but this decision just made making libraries compatible with both, so much so that they added it back (around 3.2-3.3 IIRC).
There are also always decisions you make that in hindsight you wish you'd done differently (eg the mutable Date class in Java) but just because you're making breaking changes doesn't mean you should "fix" all of those. You still have to look at each one and ask yourself "does this really matter enough to justify changing it now?". The default answer is "no" and the bar for "yes" should be really high.
I feel like Python3 failed here too.
And look where we are. Python3 out in 2008 and we're still writing migration guides in 2019.
Re: How to Port from Python 2 to Python 3 (2019)
#23Python 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
Ruby did a great job back in the day with their 1.8 release which changed the language to be Unicode friendly.
Re: How to Port from Python 2 to Python 3 (2019)
#24IIRC, the Python used in the macOS vim(1) is still 2.x. So at least on a Mac it won't be possible to just move on to Py3 and forget / uninstall Py2 for the foreseeable future.
Additionally, the next version of macOS, out this fall, will remove/hide the system version of python (python2) from users.
Look under Scripting Language Runtimes
https://developer.apple.com/documentation/macos_release_note...
Re: How to Port from Python 2 to Python 3 (2019)
#25Earlier quoted context omitted.
The main mental stumbling block I have about IPv6 (and I know it's kind of a silly one, but it's honestly what I feel on introspection) is that I can't remember an IPv6 address off by heart. IPv4 addresses just _feel_ so much more human-consumable than IPv6 addresses. I can't imagine myself using IPv6 addresses on the command line like I do with IPv4 now. There's also the issue that honestly, I have no idea what is u…
> 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…
Even if ISPs aren't dragging their feed, the home routers are lacking a giant amount of features on IPv6 stack, which are still needed even for basic users.
E.g.: - My Mikrotik will not to any kind of routing acceleration for IPv6 so throughput on GBit FTTH (which is standard offering here) will be significantly slower.
- There's no way to autoconfigure firewall (so no UPnP-like technology to enable voice calls and gaming).
- There's no way to statically assign addresses or autoconfigure firewall for automatically configured ones.
- There's no builtin way to push your own DNS to configure things like pihole.
So even a "simple" techy guy setup where you have a home NAS and a few machines that need to drill holes through the firewall is almost completely impossible on pretty much any router affordable for home use.
Re: How to Port from Python 2 to Python 3 (2019)
#26The big issue of ports like these is not the tutorial but to justify that to your boss. From enterprise to a self run startup you have to see if it’s worth it .
> The big issue of ports like these is not the tutorial but to justify that to your boss.
I think that's a red herring. Convincing your boss is an issue even for minor upgrades. In a previous job, we couldn't convince him to move from Python 2.5 to 2.7.
Re: How to Port from Python 2 to Python 3 (2019)
#27Python 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 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, decode on bytes” then subsequent releases fixing up other stuff over time would have been much nicer.
Like the “everything is iterators now” release could have happened later.
Re: How to Port from Python 2 to Python 3 (2019)
#28Earlier 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…
The constant stream of breaking changes in Python - that is, in the "standard library" which may as well be part of the language - is the most frustrating thing about Python. There are perfectly good projects that can no longer be run without major work, just because they were left unmaintained for a few years. This is a silly state of affairs, and depressingly common when the fix is really simple: version declarations. Feel free to move fast and break things, but always provide the old behaviour if the user puts a "version=3.2" flag in their code. There's no reason this mechanism couldn't have extended to every change in Python since its release.
If POV-Ray can do it, Python could have done it.
Re: How to Port from Python 2 to Python 3 (2019)
#29Isn't it ironic that Sentry is one of the tools mentioned in py2->py3 migration? (Sentry is on py2 and as far as I remember they were not very optimistic about migrating)
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.
Re: How to Port from Python 2 to Python 3 (2019)
#30Earlier quoted context omitted.
The main mental stumbling block I have about IPv6 (and I know it's kind of a silly one, but it's honestly what I feel on introspection) is that I can't remember an IPv6 address off by heart. IPv4 addresses just _feel_ so much more human-consumable than IPv6 addresses. I can't imagine myself using IPv6 addresses on the command line like I do with IPv4 now. There's also the issue that honestly, I have no idea what is u…
> 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…
> Stop remembering numbers meant for a machine, and use DNS
This is not a good solution. A lot of times people use IPs because DNS is not available or is more complex to set up. Say you are:
- Setting up and configuring a network. - Setting up the firewall. - Inspecting traffic and seeing where it goes. - Verifying that the DNS resolutions are being done correctly.
Most people already use DNS, because it's more comfortable. But anything that requires working with the network is now going to be much more complicated. For example, I can remember some network prefixes and know whether they are in building A or building B. IPv6 makes that much, much more difficult.
Also, the numbers are not even that well meant for a machine. Text representation of IPv4 is easy to detect. IPv6 representation? Good luck with that.
All of that because of the decision of using 128 bits instead of 64. 2^64 address would be more than enough, representable without issues in usual data types (uint64_t is a standard C type, uint128_t is not) and the problem of ipv6 representation would be far less relevant.