Fedora and Python 2
Fedora and Python 2
Posted Apr 5, 2018 15:41 UTC (Thu) by southey (guest, #9466)In reply to: Fedora and Python 2 by cyperpunks
Parent article: Fedora and Python 2
Don't forget that users can still install Python 2 from source in their distribution of choice and users can create their own Python 2 distribution as well. But if users wants to have the benefits of a distribution then users need to support their distribution and get those Python 2 packages ported over. This would also be true for PyPI but PyPI is not a Linux distribution and PyPI needs to become more proactive as well.
Arguments based on dependencies are no longer valid. It will be 10 years in December since Python 3 was released and many of the frequently used packages have already been ported to Python 3. So if a dependency has not been ported by now then users should have no expectations that it will be ported in the future nor should users expect that the package will be continue to be supported. So unless users can get it ported, users need to start replacing those packages with something else that is supported in Python 3.
Posted Apr 6, 2018 12:50 UTC (Fri)
by bandrami (guest, #94229)
[Link] (5 responses)
Though they will get sued if they have the temerity to call that Python 2 distribution "Python"
Posted Apr 12, 2018 4:50 UTC (Thu)
by njs (subscriber, #40338)
[Link] (4 responses)
Posted Apr 17, 2018 13:27 UTC (Tue)
by bandrami (guest, #94229)
[Link] (3 responses)
Can you think of any other situation in free software where a team that has abandoned a codebase has not just discouraged someone willing from taking over maintenance, but in fact used legal pressure to prevent it?
Posted Apr 17, 2018 14:00 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
That's not what happened here. Maintenance of the codebase is perfectly fine. The name however is not free to use for forks. That is a situation that is quite common in Free software projects.
Posted Apr 17, 2018 20:22 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
Posted Apr 28, 2018 20:07 UTC (Sat)
by flussence (guest, #85566)
[Link]
This Python naming dispute isn't an act of malice - it's a simple trademark defence. Mozilla does exactly the same thing, which is why we have IceCat, IceWeasel, PaleMoon, Seamonkey etc.
Posted Apr 8, 2018 13:52 UTC (Sun)
by togga (guest, #53103)
[Link] (14 responses)
Considering that the Python "community" (or BDFL) for obvious reasons has failed to switch it's users from 2 to 3 during a period of 10 years and then finally resided to threats and end-of-support for this, I'd wonder if this is a sound stance to take. Buying this tactics has had negative impact on the open source community. Py2/Py3 range of problems is now at the same (or surpassing) the annoyance levels of multi-platform path-separation, argument-quoting- and eol-issues. Fedora should answer the following question for their users:
Why should users accept regressions to migrate to Python3?
I think Fedora should stay classy and recommend migration away from a BDFL-controlled language gone awry. Ideally a fork would have happened long before this point.
Posted Apr 8, 2018 18:55 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (13 responses)
Yeah. Hindsight is always 20/20. Where were you 10 years ago? did you know better at the time? I certainly didn't.
Python is not any more BDFL-"controlled" than any other language.
Posted Apr 8, 2018 19:28 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
The correct way is to acknowledge them and fix them. PHP actually did this with ill-fated PHP6, which also had started with "convert-the-world-to-magic-Unicode" approach. But after several years they realized that it's not going to work, so the fork was abandoned and most of the interesting stuff had been backported into PHP5. And the next migration attempt (PHP7) was designed to have only fairly minor breaking changes.
Yet Python persists in the belief that "they know better" and "just because". That "Unicode is like eating veggies" ( https://nothingbutsnark.svbtle.com/porting-to-python-3-is... ).
Well, as a result a lot of large codebases are now migrating away from Python entirely. Google now has a transparent Golang interoperability layer built specifically for Youtube and Dropbox is just moving to Golang piecewise.
Posted Apr 8, 2018 21:09 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (10 responses)
Python2's indiscriminate support for mixing test and binary data caused a ton of hard to track bugs. "the day Django stops supporting Python 2 they will be able to rip out a ton of code that exists purely because it was so easy to mix text and binary data and get it wrong" (cited from the page you linked to). Yes it's annoying to suddenly be required to think about whether your data ist binary or text, and if the latter what encoding, but frankly you should have done that in the first place – the real problem is Python2's inability to support that distinction.
And yes there were some mistakes in early Python 3.x versions, but "acknowledge and fix mistakes" happened, e.g. by ditching 2to3 in favor of six and by extending support for Py2 – not by throwing in the towel because the whole thing was doomed to fail from the beginning. It obviously isn't; Python3 uptake may be slower than expected initially, but it's still way faster than that of Perl6. :-P
If Go is a better fit than Python2/3 for whatever it is you want to do, well, go for it. I'm not going to infer any perceived inferiority of Python2 vs. Python3 from that. It's probably more like "if we need to spend some effort to switch over anyway, let's examine what else might work even better".
Posted Apr 9, 2018 2:17 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> "the day Django stops supporting Python 2 they will be able to rip out a ton of code that exists purely because it was so easy to mix text and binary data and get it wrong" (cited from the page you linked to).
> If Go is a better fit than Python2/3 for whatever it is you want to do, well, go for it. I'm not going to infer any perceived inferiority of Python2 vs. Python3 from that. It's probably more like "if we need to spend some effort to switch over anyway, let's examine what else might work even better".
Posted Apr 9, 2018 2:58 UTC (Mon)
by roc (subscriber, #30627)
[Link] (5 responses)
> What is wrong with UTF-16?
Outside UTF-16-based platforms (Windows, Java, JS), UTF-16 is strictly worse than UTF-8:
Posted Apr 9, 2018 7:27 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Apr 9, 2018 10:09 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
Posted Apr 9, 2018 23:49 UTC (Mon)
by roc (subscriber, #30627)
[Link] (2 responses)
People use UTF16 a lot more than they should because in the 90s everyone was taught that 2-byte code points was *the* way to support Unicode, and Windows, Java, JS and others designed their APIs around that assumption. That kinda made sense if you believed, as many people did, that the 2-byte encoding with no multi-code-point characters (UCS2) would suffice for every Unicode character forever. That teaching was pervasive enough that many people came to *define* Unicode support as 2-byte code points, and some still do. So I'm not surprised that Python people got it wrong.
It's all a multibillion-dollar mistake :-(. Platform and application vendors did a ton of work to shift to UCS2 and then (implicitly) UTF16, to end up with a worse encoding than UTF8, a lot more work than if they'd just reinterpreted their byte strings as UTF8. Linux got this right, I think largely by just delaying Unicode support until it was clear UTF16 was a loser.
People at the Unicode consortium who set everyone down the UTF16 path really should fess up and apologize. Their mistake caused vast resources to be wasted and has actually caused Unicode support to be worse than it otherwise would have been.
Posted Apr 12, 2018 23:18 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
The other argument is that nobody could have sold a 32 bit encoding in the early 1990s. In 1996, they declared that it was going to have expand from 16 bit to 32 bit (or 20.1 bit). In 2001, Deseret was one of the first scripts encoded beyond above FFFF because they needed to start encoding stuff up there, but they didn't want to start with scripts people were going to fight to keep in the BMP. And yet it wasn't until 2010 that MySQL, even in UTF-8, supported characters above FFFF. Unless they've made some changes since I checked last time, it still bites people that MySQL charset utf8 is for FFFF and below only, and utf8mb4 is needed to actually encode UTF-8.
With a bunch of foresight on everyone's part, it might have been better. But pushing a 32 bit encoding in 1990 could also have mired the idea and left us working with an ISO 2022-style pile of encodings or at least stalled things by a decade where more legacy data in legacy encodings, and even more legacy encodings, were created, and more protocols were designed around the idea that everything has its own encoding instead of everything being in a fixed encoding, or at least a Unicode-compatible encoding.
Posted Apr 15, 2018 1:14 UTC (Sun)
by DHR (guest, #81356)
[Link]
The key was it require "Han unification". Japanese, traditional Chinese, Korean, and simplified Chinese symbols would have to share code points. This was never going to be acceptable to people using those languages.
The analogy I heard was: would the Greek and Roman alphabets share code points? Alpha and A are really the same, are they not? How about Aleph? No way!
The fact is that UNICODE-1 was doomed before birth.
UTF-16 was always a bad idea. Some tried to ignore that and we live with that mistake.
<https://en.wikipedia.org/wiki/Han_unification>
UTF-8 was designed by the Plan9 folks. Quite early. On a napkin. Some of them later brought us Go.
Posted Apr 9, 2018 10:56 UTC (Mon)
by niner (subscriber, #26151)
[Link] (2 responses)
2 years after Python 3's first stable release, I couldn't even install it from a distro repo. And 10 years after said release, I still can't use it in combination with our existing Python 2 code.
I wonder what you use as base for your update comparison. Because at the 2 year mark, I'd call it a hands down victory for Perl 6 and we don't know what the 10 year mark's gonna be like. And anyway, I didn't even know there was a contest.
Posted Apr 10, 2018 8:16 UTC (Tue)
by OttoErickson (guest, #122996)
[Link] (1 responses)
Posted Apr 12, 2018 8:11 UTC (Thu)
by niner (subscriber, #26151)
[Link]
Posted Apr 11, 2018 21:05 UTC (Wed)
by togga (guest, #53103)
[Link]
Since I was a heavy Numpy/Scipy/etc user 10 years ago I just followed Python3 development occasionally and did not really do any effort on using it. Using it for prototyping algorithms, simulations, debug and test-scripts I've never really encountered any problem Python3 tried to solve. Since I use Python for debug and interface a lot with C/API:s, Python3 issues is really piling up when trying to use it. Personally I'm on an exit strategy now but unfortunately there is a lot of Python code out there especially since it's an "easy syntax", popular at many workplaces. In the last couple of years I've been struck by py2/py3 issues on a almost day-to-day basis. I find most of them un-necessary and annoying, haven't seen anything like this in any other language I use.
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
A few years back the libav gang attempted to sue the legitimate FFmpeg project out of existence over its use of the logo. They failed because they didn't actually own any rights to the image to begin with; a third party contributed it. Hasn't stopped them using it, mind you.
Fedora and Python 2
Why would this situation not happen all over again with Pyhton4, when Guido is disappointed with something else in Python3?
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Why is that? What is wrong with UTF-16?
I really doubt it.
Exactly. And this is self-inflicted entirely.
Fedora and Python 2
* Twice the space usage for ASCII (almost never more compact than UTF-8 on any text in practice)
* Multi-code-point characters are rarer, therefore less well tested
* Byte-order-dependent
* Needs special logic to sort lexicographically
More details: http://utf8everywhere.org/
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2
Han Unification means UCS-2 was doomed and UTF-16 makes no sense
Fedora and Python 2
Not being a Perl Monger I'm genuinely surprised to hear that Perl 6 is being used in production. I was under the impression that Perl 6 had largely been abandon; it would seem that my impression was incorrect.
In all honesty, this is not a criticism or flame of Perl; I've never really worked with Perl—any version—so I haven't kept up with it. I'd love to see an article on the topic of Perl 6 here on LWN.
Fedora and Python 2
Fedora and Python 2
Fedora and Python 2