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

Python 2 vs. Python 3: A retrospective

dropbox.com

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#71

Post by Sami_Lehtinen »

lmm wrote: post #47
andyl wrote: post #42

It seems like I've been reading about the difficulties of Python V2 -> V3 for awhile. Why is that? Is this Python upgrade unusually difficult/ambitious? Or is the Python community just very reluctant to jump on new things?

It's a big, ambitious update. The biggest difference is forcing users to distinguish between strings and byte sequences; essentially programs now have to be encoding-aware (at least if they use any of the standard library functions). Which is a Good Thing, but can require a ton of work for existing codebases.

I've seen many programmers having trouble with this. But it's essential when using UTF-8, because sgtring presentations length might be is different from byte length. So byte != char != int (0-255). It's hard to get for some coders who are used that all of those datatyps are the same.

Re: Python 2 vs. Python 3: A retrospective

#72

Post by ajford »

steveklabnik wrote: post #56
spamizbad wrote: post #36

Earlier quoted context omitted.

The Python ecosystem is far too diversified to get knocked down by one language. Python has a wealth of production-quality libraries across a ton of domains (Web, scientific computing, data science, NLP, parsing, scripting/automating, etc). Go is a non-entity in most of these domains and isn't even a top-20 programming language on Github (source: http://sogrady-media.redmonk.com/sogrady/files/2013/07/progr... ) Pytho…

The scientific Python community will never leave 2.5 -> 2.7, though...

The science community will get there. The problem is that for a long time, NumPy/SciPy/etc. didn't support 3.x. And when you're more interested in end results, why would you rewrite your code (or spend days/weeks/months relearning) when you could use a still perfectly acceptable and supported version?

There's also a lot of reuse and expansion on existing code bases, which would involve a lot of work to migrate to 3.x. There's also the matter that on top of moving to 3.x, you also have the task of making sure there's no hidden bugs that may alter your results in ways you may not notice. A lot of scientific code has been repeatedly vetted to make sure that there's no bias or glitches that may skew your results.

Hell, I know astronomers who are still using Fortran code that was written in the 80's. It still works (though now it requires a long build process, as it is no longer compatible with the latest Fortran compilers), so no reason to try to rewrite it just because the language is dated.

Re: Python 2 vs. Python 3: A retrospective

#73

Post by ceol »

pdonis wrote: post #39
yeukhon wrote: post #30

Earlier quoted context omitted.

Whoever downvoted me have some weird negativity here. It doesn't against ethos of Python. There is a Zens of Python, I don't know Ethos of Python. http://www.python.org/dev/peps/pep-0020/ Beautiful is better than ugly. Writing .items() or surrounding enumerate() does not make your code look prettier, does it? Explicit is better than implicit. In fact, my proposal is more explicit than the implicit of for key in my_di…

my proposal is more explicit One could just as easily say that your proposal is less explicit, because a sequence is a sequence of items, not (index, item) tuples, yet you're making the "for" iteration yield tuples. Similarly, a dict is a container of keys, not (key, value) pairs. The reason is that otherwise you would be unable to check to see if a key was in the dict unless you knew the value that went with it: but…

I forget if it's Jinja or Django's template, but one of them has a function that only exists inside of for loops that returns the current index. I thought that was a great way to handle it, since it's always available without changing any syntax.

In retrospect, I suppose the .index() method would be fine, since Lists can't hold two of the same object, and Dicts return the key by default.

Re: Python 2 vs. Python 3: A retrospective

#74

Post by ceol »

xymostech wrote: post #59
mhenr18 wrote: post #41

Earlier quoted context omitted.

There's no need to make it not be valid. C++ uses begin() and end() for obtaining iterators to containers, but nothing's stopping you from using those method names for your own purposes. It's just that if you want to use a few new language niceties like range-based for loops then you'll need to conform to that convention.

In C++ it's fairly common to be calling begin() and end() on containers, where in Python it's not common to call next(), you let the for loop handle it. It's reasonable to rename a function to something ugly when you're never going to be seeing it.

That's the best time, so that people don't think it's a function they should be calling without understanding exactly what they're doing.

Re: Python 2 vs. Python 3: A retrospective

#75

Post by pdonis »

ceol wrote: post #73
pdonis wrote: post #39

Earlier quoted context omitted.

my proposal is more explicit One could just as easily say that your proposal is less explicit, because a sequence is a sequence of items, not (index, item) tuples, yet you're making the "for" iteration yield tuples. Similarly, a dict is a container of keys, not (key, value) pairs. The reason is that otherwise you would be unable to check to see if a key was in the dict unless you knew the value that went with it: but…

I forget if it's Jinja or Django's template, but one of them has a function that only exists inside of for loops that returns the current index. I thought that was a great way to handle it, since it's always available without changing any syntax. In retrospect, I suppose the .index() method would be fine, since Lists can't hold two of the same object, and Dicts return the key by default.

Lists can't hold two of the same object

Yes, they can. Try it! The index method has extra arguments to let you specify a range of indexes in the list to search, so you can find multiple indexes that point to the same object (by picking a range that excludes indexes you've previously found).

Dicts return the key by default

Dicts don't have an index method; dict keys are not ordered.

Re: Python 2 vs. Python 3: A retrospective

#76

Post by spamizbad »

steveklabnik wrote: post #56
spamizbad wrote: post #36

Earlier quoted context omitted.

The Python ecosystem is far too diversified to get knocked down by one language. Python has a wealth of production-quality libraries across a ton of domains (Web, scientific computing, data science, NLP, parsing, scripting/automating, etc). Go is a non-entity in most of these domains and isn't even a top-20 programming language on Github (source: http://sogrady-media.redmonk.com/sogrady/files/2013/07/progr... ) Pytho…

The scientific Python community will never leave 2.5 -> 2.7, though...

Yeah that's true. Getting everyone to 3 is going to be quite a slog. I have a feeling once Python 3 becomes the default Python installation for OSX and Linux systems you'll see a big uptick in adoption (and probably some abandonment as well).

Re: Python 2 vs. Python 3: A retrospective

#77

Post by meowface »

TylerE wrote: post #62
yen223 wrote: post #57

Earlier quoted context omitted.

The division change is good. I have a hard time understanding why you'd want 3/2 = 1 as the default behaviour.

Imagine the following (admittedly bad, minimalistic to make my point) code x = int(input(">>> ")) a = x / 2 append_int_to_magical_db(a) If the division does a "naturaL" thing, you suddenly have a float "polluting" your integer algorithm, but it's _not consistent_. If the user enters "4", you get an int back. If they enter 5, you get a float.

Users of Python 3 and up will just have to remember that the result of any division will be a float.

It's a breaking change, yes, but in general I think it's a good one.

Re: Python 2 vs. Python 3: A retrospective

#78

Post by meowface »

yeukhon wrote: post #8

The one thing I wish they could change in the future is forcing list and dictionary iterable same syntax: instead of writing for index, element in enumerate(some_list) for key, value in my_dict.items() they should unify and make items and enumerate default behavior. i.e. for index, element in my_list: for key, value in my_dict: I really don't see the benefit of not doing this as default behavior. I always find if I n…

First, keep in mind that as others have said, there is no "magic" involved here.

`list(seq)` will return a list of elements. `list(dct)` will return a list of keys. A for-loop will always loop over the abstract "list representation" of the object (the list result itself is just an accumulation of values from a for-loop).

So your first suggestion would make no sense whatsoever. As for the second...one could maybe argue for that. Many people end up using `dct.keys()` anyway when they want the keys, and `.items()` is so common that it could maybe be made the default. Ruby actually does this by default. However, it would break a ton of current code where people expect to be looping over the keys.

Post reply on HN