Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

151–160 of 355 posts

Re: Why Is the Migration to Python 3 Taking So Long?

#151

Earlier quoted context omitted.

I suspect that someone, or a group of people, will step up to unofficially maintain Python 2 for the foreseeable future. It's clear that there are a lot of people using it that either can't easily migrate or are unwilling to do so for the various reasons already discussed in this thread.

If I encounter Python 2 bugs that matter to me, I can and will fix them myself if needed, and submit or otherwise publish the change. I'm quite certain I'm not the only one.

Why not just migrate to 3?

genuinely curious...

Re: Why Is the Migration to Python 3 Taking So Long?

#152
post #118

Earlier quoted context omitted.

I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.

What's weird is that it's half baked def foo(self): instead of a more logical: def self.foo(): to match the calling syntax.

I don't think you understand what is actually going on under the hood here, at all. Methods are member functions of a class, and must be invoked on an object.

  someInstance.foo()
When invoking a method from within the class, you still need a reference to the object the method will be invoked on. In python, the reference is passed implicitly as the first argument, and usually called self. That has nothing to do with the method name or signature itself, and calling the method self.foo() would result in calling it like

  someInstance.self.foo()
for cases when you aren't referencing the function from within the class, which would be even more confusing.

Re: Why Is the Migration to Python 3 Taking So Long?

#153

Earlier quoted context omitted.

If I encounter Python 2 bugs that matter to me, I can and will fix them myself if needed, and submit or otherwise publish the change. I'm quite certain I'm not the only one.

Why not just migrate to 3? genuinely curious...

Because of the amount of work involved in porting my existing Python code. Python 3 doesn't offer any advantages that matter to me, so that's a lot of effort for little gain.

Re: Why Is the Migration to Python 3 Taking So Long?

#154

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…

> The only real killer feature of Python3 is the async programming model. I understand that this is one of the major features, but I personally never saw the appeal, given that gevent exists and in my experience works well most of the time. It also allows me to multiplex IO operations and doesn't rely on new syntax. I'm probably missing something?

In gevent, any call may behave like an implicit "goto". Here's why "goto" is bad https://vorpus.org/blog/notes-on-structured-concurrency-or-g... (the link is stolen from @hermod's comment above)

Re: Why Is the Migration to Python 3 Taking So Long?

#155

Earlier quoted context omitted.

This is such a good point. Take SQL. It has survived because it is well designed, and changes so little and so slowly, and it’s obvious what SQL is and isn’t meant for. Amateur programmers can port SQL queries between database systems semi-painlessly. In the right environment a query can survive with small edits for YEARS. Who wants to break old SQL? Nobody.

That's something of an illusion. The flaws in SQL often aren't noticed because you usually pick one database vendor and stick with them. There are plenty of differences between vendors, but you don't usually have to support them at the same time, and you don't notice for simple cases. But changing database vendors for a company can be a big deal, as bad as going from Python 2 to 3.

This is true. But, I think he means syntactically you can make jumps from one dbms to another without much of a fuss. Obviously there are non-language features but, that is not what is being discussed here.

Re: Why Is the Migration to Python 3 Taking So Long?

#156

Earlier quoted context omitted.

On the topic of not enough carrot, I’m curious how impactful the end of support for python2 will be. How many programs stuck in python2 are encountering bugs in the runtime?

I actually find this aspect of the whole thing exciting, perhaps paradoxically. Now that Python 2 is static the runtime can become asymptotically bug-free. Meaning that, if you only change it to fix bugs (as opposed to introducing new syntax|semantics) it's going to approach perfection.

You are assuming that fixing bugs introduces less new bugs.

Re: Why Is the Migration to Python 3 Taking So Long?

#157
Personally, I don't see the need to migrate entire code bases if there is no need. I think that much is obvious. Perhaps the focus should be put onto pivoting instead. That way it doesn't leave your dev team on the hook to go back and change existing code bases in python 2.

Re: Why Is the Migration to Python 3 Taking So Long?

#158

Earlier quoted context omitted.

See, it just broke when UTF-8 was interpreted as ASCII. It's entirely possible to treat bytes as bytes and leave encoding out of it for the vast majority of programs. If you're dealing with text editing and so on, then you know you need to be UTF-8 aware, and the broken programs would still be broken in either language. The visibility of the errors is a minor point, but I think it more appropriate that it be solved b…

> the broken programs would still be broken in either language. You need to slap a decode anyway on reads from subprocesses in python3, and files open in Unicode mode by default. Wouldn't that fix the majority of silly UTF-8 compat bugs? Or am I missing a class of bugs that's not avoided automatically by python3 strings?

Well, the summary of the argument is that the python3 UTF-8 does not actually solve the fundamental problem of multiple encoding formats existing. Think: Do you know that the process actually returns UTF-8, or that the file is actually encoded in UTF-8? No, you're just guessing. This puts people in the habit of attempting to turn everything into UTF-8 which could happen automatically and not require so much boilerplate.

On the other end, most programs don't actually care what the data encoding is. They just move it.

Re: Why Is the Migration to Python 3 Taking So Long?

#159
post #36
post #20

Earlier quoted context omitted.

Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.

The nuisance of having to add self as parameter to every class method, no way of enforcing private methods and the mix between methods on objects and functions in the standard library. OO feels more integrated in e.g. Ruby. About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...

> The nuisance of having to add self as parameter to every class method

This was done intentionnaly, because "Explicit is better than implicit". It also has some uses, eg. if you want to do this:

    class Foo:
        def inject_bar(self):
            def new_bar(self2):
                pass # you can refer to both 'self' and 'self2 here
            other_object.bar = new_bar
It's rare, but it has its uses.

Re: Why Is the Migration to Python 3 Taking So Long?

#160

The simple reason is that there was no compelling feature to reward you for upgrading. You'd spend a tremendous amount of effort for dubious return and (until recently) a smaller ecosystem. 1. Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an in…

> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.

Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up.

In python 3 it always blows up when you mix bytes with text so you can catch the issue early on.

> In the latest py3 versions we've finally gotten some sugar to tempt people over: asyncio, f-strings, dataclasses, and type annotations. Still not exactly compelling, but at least something to encourage the average Joe to put in all the effort.

That's because until 2015 all python 2.7 features were from python 3. Python 2.7 was basically python 3 without the incompatible changes. After they stopped backporting features in 2015. Suddenly python 3 started looking more attractive.

Post reply on HN