Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

Post reply on HN
Print view View original

171–180 of 355 posts

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

#171

Post by ageofwant »

recursivecaveat wrote: post #81

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…

Again with the 'Tremendous amount of effort' meme. I've done many ports and they were all trivial:

    - run 2to3
    - spend 2h max fixing any failing tests
    - cook of any remaining issues in a few days of beta testing like you'd do for any new release
Now now doubt Python 2.7 is a excellent and solid release and will remain so for as long anyone keeps the bitrot in check, but to keep using it because porting is 'hard' is patent bs.

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

#172

Post by progval »

tomp wrote: post #166
progval wrote: post #159

Earlier quoted context omitted.

> 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.

> "Explicit is better than implicit" Too bad Python breaks this "commandment" pretty much whenever it wants to.

Yeah, The Zen of Python has commandments to justify pretty much anything. eg. "Simple is better than complex." or "Readability counts." when you want something to be implicit

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

#173

Post by doctoboggan »

recursivecaveat wrote: post #81

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…

I know its simple, but it wasn't until I learned about f-strings that I actually switched for good.

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

#174

Post by wvenable »

just_myles wrote: post #155
skybrian wrote: post #46

Earlier quoted context omitted.

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.

Dealing with Unicode in SQL has long been a backwards-compatibility nightmare.

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

#175

Post by ogre_codes »

avisser wrote: post #161
btreecat wrote: post #112

Earlier quoted context omitted.

>JS manages to do that just fine How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes. And JS "The good parts" is like 1/10 of the full language so often it feels like a lot of pile on. >as does Java How are them generics?

Now do C#. You are moving the goalposts and ignoring the fact that Python3 still didn't deliver anything for most users.

Replying here because the other is nested too deep.

You do realize that C# was itself Microsoft's replacement for C++ right? And that when C# was released it had it's own growing pains and long roll-out in spite of having the worlds biggest corporation pushing it.

Python as a language is far older than C# so it had a lot more baggage than C# does.

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

#176

Post by setr »

just_myles wrote: post #155
skybrian wrote: post #46

Earlier quoted context omitted.

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.

That's mostly a result of databases (kinda) converging, SQL being a declarative language and it primarily being a wrapper around relational algebra, with a bunch of flags. And of course, it's a very direct interface to the RDBMS, and you're just migrating between systems that try very hard to have the same interface.

As a language however, it's a whole lot of nonsense. Extremely inconsistent syntax, stuffing a trinary logic into a boolean system, a standard that gets extended arbitrarily, and even the tooling ecosystem is a fair bit pathetic (the lack of formatters particularly annoy me; everyone tries to support SQLs generally, and end up missing every extended feature.. if it's not a simple select query/ddl, you're not getting a decent format output)

And it most certainly is a whole lot of fuss to migrate unless your database is tiny, or you didn't actually utilize the DB except as a dumb datastore (eg you relied solely on your ORM + indexes); there's a reason no good translator exists, and those that exist only support a very limited subset of any particular SQL variant, despite programming languages having a whole array of transpilers; it's simply not at all a simple language, and the variants only superficially look the same.

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

#177

Post by jordigh »

ageofwant wrote: post #171
recursivecaveat wrote: post #81

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…

Again with the 'Tremendous amount of effort' meme. I've done many ports and they were all trivial: - run 2to3 - spend 2h max fixing any failing tests - cook of any remaining issues in a few days of beta testing like you'd do for any new release Now now doubt Python 2.7 is a excellent and solid release and will remain so for as long anyone keeps the bitrot in check, but to keep using it because porting is 'hard' is pa…

Behold the tremendous amount of effort for Mercurial:

https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2...

They've been porting hg into Python 3 for the last 10 years and are only now nearing completion.

I've written a bit more about this in Lobsters:

https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_...

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

#178

Post by Redoubts »

recursivecaveat wrote: post #81

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…

They really should have used the breaking nature of v3 to drop features that prevented good JIT implementations or speedups in cpython.

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

#179

Post by setr »

marcus_holmes wrote: post #149
crustacean wrote: post #35

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.

> Who wants to break old SQL? Nobody. Every couple of months there's a new startup / dev site that says "SQL is broken/old/bad, so we reinvented it!". They all sink without trace, but there's a cohort who agrees with them.

The problem I think is they typically try to go ahead and reinvent the entire RDBMS as well.

It's not clear to me why postgres hasn't simply grown a whole array of frontends..

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

#180

Post by biggestdecision »

keypusher wrote: post #152
gowld wrote: post #118

Earlier quoted context omitted.

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 th…

The syntax of a language is an abstraction over what is actually going on under the hood. There's no reason python couldn't have designed their OOP abstraction more elegantly.
Post reply on HN