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

41–50 of 355 posts

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

#41

Post by dragonwriter »

chungy wrote: post #20
erokar wrote: post #14

Earlier quoted context omitted.

Python 3 seems like a bit of a missed opportunity. Since they were introducing breaking changes in the first place, why didn't they go bigger? E.g. make the OOP seem less tacked on, immutable data structures, clean up inconsistencies in the standard library?

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.

I think for some people having the receiver as an explicit parameter of methods rather than references through a special syntactic variable bothers some people and makes it look to them like a procedural language playing OO, though I personally think it's the most clear representation of what every class-based OO language actually does operationally, since methods are attached to a class and take a reference to the instance on which they are invoked.

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

#42

Post by enragedcacti »

CoolGuySteve wrote: post #34
chungy wrote: 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.

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

I personally really like the self keyword after spending some time reading code in Java where `this` is optional. Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I'm a fan of forcing devs to acknowledge when they are accessing or manipulating mutable object state.

Separate from that, I think that would be a much bigger breaking change than you think. __setattr__ and __setattribute__ means that self.y doesn't necessarily refer to a traditional attribute so without self you could end up with either:

1. `x = y` where the expression `y` executes code

or

2. `x = y` where `x = ???` and `x = self.y` where `x = self.__setattr__('y')`.

That said, I do think the language could use something to reduce the size of __init__() since

self.arg1 = arg1

self.arg2 = arg2

self.arg3 = arg3

...

can get pretty verbose

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

#43

Post by btown »

CoolGuySteve wrote: post #34
chungy wrote: 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.

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

Self lets you do really cool things though. For instance, you can monkey-patch with `def override_method(arg_that_will_get_self, *args): pass; Class.method = override_method` after Class is defined. Python lets you have all the dynamism of Ruby without letting you go too crazy with DSLs - which is the perfect balance IMO.

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

#44

Post by linsomniac »

What do you mean taking so long? The original target date, proposed by Guido, was Jan 1, 3000. Looks like we're 980 years ahead of schedule! :-)

I say this in part because comedy, but also because it was anticipated to be a long project. It was originally called "Python 3000".

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

#45

Post by dragonwriter »

CoolGuySteve wrote: post #34
chungy wrote: 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.

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

Python doesn't have a self keyword, redundant or otherwise.

In fact, that's a key difference between Python and many other class-based OO languages.

I'm not sure whether that (and the associated need to make the receiver an explicit parameter—conventionally, though this is not required, named “self” in instance methods—in method definitions) is your problem, or if your problem is that (unlike some, but fewer than the previous difference, OO languages) you can't omit explicitly naming receiver in references to its own instance variables in an instance methods, making instance variable reference syntactically distinct from local variable references.

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

#46

Post by skybrian »

crustacean wrote: post #35
semiotagonal wrote: post #13

Earlier quoted context omitted.

I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?

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.

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

#47

Post by CoolGuySteve »

snagglegaggle wrote: post #19
downerending wrote: post #8

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 main change people cite is the UTF-8 "support" but frankly it seems like far more pomp and circumstance than is necessary. Appropriate code point handling could have been provided and everything left as it was. And when you get rid of that, there's not that much left that is breaking.

I find the stronger differentiation between bytes and strings leads to a lot of gotchas, like when I forget to encode bytes or pass a string where bytes are expected.

I understand why it's the way it is, but when it comes the the typical unixy things I need to do shuffling of files around, tar'ing stuff, etc, it definitely trips me up more than I'd wish.

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

#48

Post by Animats »

First off. Python 2.6 and 2.7 supported Unicode just fine. I had a large all-Unicode system in Python 2.6. You had to write u'word" to get a Unicode constant, and use a "unicode(s)" function here and there. Also, the part that remained "compatible" was that "str" remained an array of bytes, even though there was also a type "bytes" and a "bytearray".

Early Python 3 was hell for conversion. The syntax was changed for no good reason. u'word" became illegal. (That later went back in.) The "2 to 3 converter" was a joke. I didn't have the "print statement problem" because my code called a logging function for all debug output.

Many of the P3 libraries didn't work. (The all-Python MySQL connector failed the first time I tried to do a bulk load bigger than a megabyte, indicating that nobody was using it.) It took years before the libraries were cleaned up.

Python 3 got some really weird features, such as type declarations that don't do anything. I can see having type declarations, especially for parameters, but they need to be used both for checking and optimization. CPython boxes everything, which is terrible for numerics and is why most serious math has to be done in C libraries. My comment on that was "Stop him before he kills again."

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

#49

Post by kevin_thibedeau »

alexhutcheson wrote: post #15

[copying comment from an older HN thread, not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current too…

The way to start a migration is to first get the 2.7 code as forward compatible as possible. Bring in the future imports. Make sure equivalent iterators are used where 3.x mandates them (xrange, iterkeys, etc.). Make sure Unicode is managed correctly on I/O. Explicitly call out truncating division.

This doesn't require parallel testing. These all improve the quality of 2.x code even if you never make the leap to 3.x.

Once this is done you can use 2to3 to mechanically fix the remaining differences. Anything else that remains broken can be special-cased in the 2.7 code until 2to3 works without intervention.

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

#50

Post by lasermike026 »

war1025 wrote: post #25
lasermike026 wrote: post #18

Management wants new features not porting. They will only port when they absolutely have to.

Even if management wanted porting, the python 2 -> 3 migration path is very painful in the details, while on the surface not having a lot to offer at the other end in terms of new capability.

Roger that.
Post reply on HN