On Sat, Dec 09, 2017 at 12:47:28PM +0100, Xen wrote: > Colin Watson schreef op 09-12-2017 0:24: > > there are good reasons behind many of the changes in Python 3 > > You know, an appeal to "good reasons" is really a blanket statement that > betrays the absence of any good reasons.
No, it betrays limited time to write. To take just one example, Python 2's willingness to mix Unicode and binary types provided that the binary strings were limited to 7-bit ASCII was the cause of a large number of bugs over the years, which Anglophones tended to overlook and allow to reach production code because they rarely use characters outside ASCII. Even as somebody generally very sympathetic to the needs of localisation, I've got this wrong because Python 2 had just too many ways to make mistakes in this area. In Python 3 you have to confront the distinction earlier and have a much better chance of getting it right. You can certainly begin to make the distinction in Python 2 code, but adding the extra type-safety required a breaking change. I'm not going to continue to spend time explaining the underlying reasons in response to vague insinuations, though. If there are some particular changes in Python 3 that you think weren't well-founded, name them. This is a list for developers; we can be specific. > So you go on to detail the similarities with C but with C there never was > one breaking point, just incremental changes. There have been many breaking changes in C over the years, though since it's an essentially smaller language most of those changes (not all!) have been at the runtime or library levels. Small consolation if that's what breaks your code, of course. But you seem to be under the impression that moving from Python 2 to Python 3 requires non-incremental changes: i.e. a flag day where your code stops working on Python 2 and starts working on Python 3. This isn't so. There's a large subset that works fine in both: nearly all the code I write these days is "bilingual" in this way, and the obvious porting strategy for most code involves making it be this way, so at the end all you have to do is flip to the newer interpreter after your tests pass. I would rather that Python 3 had taken the Perl 6 approach of having the newer interpreter be able to execute older code in a special compatibility mode, so that we could mix-and-match more freely and the transition would have been easier. On the other hand, it's not at all obvious how text/bytes types would have worked across the boundary. (And, much though I like Perl, Perl 6 has taken even longer to get into typical developers' hands than Python 3 has, so ...) > The work of "God" (unfortunate events) should not be willfully perpetrated > by humans on one another on purpose. What is your *concrete* proposal here? Bear in mind that we don't have the resources to maintain Python 2 indefinitely; if that's your proposal, it's going to run up against real-world constraints. But there may be other things we can do to make it easier for people. Do you have some specific projects that are troublesome? -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
