I would have been more interested in learning Python if there wasn't such a great divide. I read the first chapter of several books that said "Python 3 is out, but we're going to stick with 2.7 because too much shit is broken".
That was true early on in Python 3, but it's not true now.
Python 2 vs. Python 3: A retrospective
51–60 of 113 posts
Re: Python 2 vs. Python 3: A retrospective
#52Earlier quoted context omitted.
Dropbox's powerpoint viewer isn't perfect. I had to download the pptx. Works fine in Keynote.
Thanks for pointing out it's a Dropbox thing--at first I thought it might be a Chrome problem. Specifically the viewer seems not to use the proper font for this presentation. Preview on Mac OS works fine.
I'm kinda impressed though. I don't think I have a program that will view pptx files, so I was happy to be able to read it online.
Re: Python 2 vs. Python 3: A retrospective
#53It 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?
Change is hard. People don't want to spend the money on upgrading. It's almost all downside with very little upside.
Re: Python 2 vs. Python 3: A retrospective
#54Can anyone else not read the last lines of some of the slides?
Re: Python 2 vs. Python 3: A retrospective
#55It 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.
It does, on the other hand, break backwards compatibility. Which is why hardly anyone updated.
Re: Python 2 vs. Python 3: A retrospective
#56Now that I get to use Go, I have no desire to go back to python. I think I'm not alone, and that python will soon enough become the new perl.
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…
Re: Python 2 vs. Python 3: A retrospective
#57I'd really like to see the video for these slides. But here's what caught my interest: Set and dict comprehensions {x**2 for x in range(10)} {x: x**2 for x in range(10)} Why reduce() must die: ... the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly. int [divided by] int should return float nonlocal Explicit non…
You know what's funny? All of those things could have been done in Python 2.8, apart from the int division change. And the division change does as much harm as good, because lots of people use Python and also use another language where int division works the "old fashioned way"; for them (me) this change is counter-productive because it adds a pointless distinction. It is a great change for programming novices, for s…
3/2 = 1
as the default behaviour.Re: Python 2 vs. Python 3: A retrospective
#58It 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?
Imagine someone who was used to doing something like this:
import string
list=open('foo.txt').readlines()
list_strip=map(string.strip,list)
And then discovering this no longer works because the strip function has been removed from the string module (and moved to the string object). If all they want to do was a quick read of a file and then parse - they are not going to dive into Python3 and figure out the new way to do it - they'll just stick with pythonv2.Re: Python 2 vs. Python 3: A retrospective
#59Earlier quoted context omitted.
__ is basically a namespace for official language extensions. How would you suggest they do it? Prevent "next()" from being a valid method name?
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.
Re: Python 2 vs. Python 3: A retrospective
#60Earlier quoted context omitted.
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.
It's not that ambitious- none of the changes are particularly compelling, none of them scream "update now". It does, on the other hand, break backwards compatibility. Which is why hardly anyone updated.