How to Port from Python 2 to Python 3 (2019)
stxnext.com
stxnext.com
Edit: If you down vote me please say why I should care about IPv6
There's also the issue that honestly, I have no idea what is using IPv6 and what's using IPv4 right now. On my internal network I only ever deal with IPv4, but I have no intuition as to what is using IPv6; I couldn't tell you off the top of my head if my ISP supports it.
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 "end" machine (laptop, tablet, phone, server) is going to be dual stack, supporting both IPv4 and IPv6. If it is able to auto-configure an address, then it will use those. Otherwise, it won't. If a domain is IPv4-only, it'll use the IPv4 address. All of this is automatic.
The big issue, for home consumers, is that a lot of ISPs are dragging their feet. They don't need anything from the customers — they just need to get it deployed & turned on. Generally, typing "what is my IP address?" into Google will tell you if you have working IPv6; it will display an IPv6 address if you do.
In the cloud… some cloud vendors have been dragging their feet about rolling support out. You need to do some things, like associate an AAAA record to your domain (s.t. it resolves to an IPv6 address), and make sure things like logging can handle the new addresses, or if you implement IP blocking, that you can block those addresses/networks. If you're writing network code, you need to check that you're not assumptions about the socket type. You can also do things like HTTP proxy from an IPv6 connection to an IPv4 VLAN, e.g., I think w/ an ELB. That is,
client <-- HTTP/IPv6 --> ELB <-- HTTP/IPv4 --> backend server
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.
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.
This regex will detect any IPv6 address:
([0-9A-Fa-f]*:){2}[0-9A-Fa-f:.]*
For the rare cases where a memorized IPv4 address was reasonable you should just assign simple IPv6 addresses ending in a short suffix like ::1. The prefix can be 64 bits or less, which isn't too much to remember, and will be the same for the entire network.
> 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.
Nothing prevents you from assigning visually distinctive prefixes to different buildings. The larger address space actually makes this much easier. For example, you could use xxxx:yyyy:zzzz:a::/64 for every host in building A.
I just bought a new router. https://www.asus.com/uk/Networking/DSLAC68U/ It doesn't support IP6.
That's not what your link says:
> while power users will love its IPv6 support
One could argue that this is actually a significant benefit of IPv6, in practice.
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 help either.
This isn't just about Python, many libraries and languages (and some OSes - see iOS, macOS and to a slightly less extent Android) are terrible about this. The proliferation of semver with its normalization of breaking stuff (the fact that a dependency - be it a library or language or whatever - uses semver communicates that they have already decided that they will break backwards compatibility at some point) shows that most people are fine with breaking others' code.
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.
If POV-Ray can do it, Python could have done it.
This was due to the hard work the people behind Delphi had put down to make the transition as smooth as possible.
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)
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).
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.
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.
Compared to most languages, C++ is very slow moving, but also very old.
> 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
Of course.
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
wait wuh? i thought these were just two of the dozen variants of the BASIC dialect... interesting!
Hence why a lot of people back in the day felt that Visual Basic .NET should be called Visual Fred instead :-P
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.
It is so easy for people to just repeat what they heard even if that idea originated a decade ago and was valid a decade ago.
And that way we got into a mess of not migrating until pass the time it is no longer supported...
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.
The time may have passed, but lots of code is still out there that needs to be updated.
Now that I think of it the legacy branch should be eol soon.
Re: packages, one of the huge advantages of the C ecosystem has been that compiled packages are usually fine across language transitions, not only between major compiler version numbers but even from C to C++ which are much more different languages than Python2 to 3. How different would the Python transition have been if it were possible to load Python2 packages in a Python3 program?
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's to write dumb code because maintenance is twice as hard too.
that's all that is happening really!
From enterprise to a self run startup you have to see if it’s worth it .
Maybe that would be useful for a conversation with one's 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.
brew install vim -- --with-override-system-vi --with-python3
Look under Scripting Language Runtimes
https://developer.apple.com/documentation/macos_release_note...
- First cut a new major version
- Write a few tests if needed, they go a long way here.
- Update to 2.7 best practices and logging
- Run tests, commit
- Add a few future statements, commit
- Run pyflakes3 on it, fix, commit
- Run under 3.x/fix until clean, commit
However, if your project is huge and/or does a lot of string and bit twiddling it's excruciating. Hence the controversy between factions.