6 ms·
Python 2 vs. Python 3: A retrospective
- MBlume 13y agoCan anyone else not read the last lines of some of the slides?
- shocks 13y agoI am also having this problem.
- ChronosKey 13y agoDropbox's powerpoint viewer isn't perfect. I had to download the pptx. Works fine in Keynote.
- jzwinck 13y agoThanks 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.
- MBCook 13y agoWhat was worse for me was the font kerning on some things (supposed to be fixed width?) was amazingly atrocious. 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.
- gsnedders 13y agoIt's some PPTX -> PDF converter and then it's just pdf.js.
- blaze33 13y agoUbuntu here, tried with LibreOffice, same issue. Had to reupload it to google drive, problem solved: https://drive.google.com/file/d/0B8MSXu_W6_e4ZE02ZUQ5dU03cXM/edit?usp=sharing https://drive.google.com/file/d/0B8MSXu_W6_e4ZE02ZUQ5dU03cXM...
- goronbjorn 13y agoHere is a version with no problems (I used the Box View API): https://view-api.box.com/view/VoRxuIIQel26CLNAgt8KskrQxgUpwDj8TTg_myyVgUfMxh93LnUQXBaHeNwHtlbbRUWsdrxG4TjQrEpK-COpIm-E7SlJSxo https://view-api.box.com/view/VoRxuIIQel26CLNAgt8KskrQxgUpwD...
- pstuart 13y agoNow 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.
- lmm 13y agoPython was never the right answer for the cases Go solves (OCaml was a better choice 5-10 years ago, and nowadays there are plenty of options). But it's still the best language around for where you just need to write a one-off script as quickly as possible (in that sense it's always been the new perl).
- _delirium 13y agoFor a one-off script I still prefer Perl. But where I run into Python more is scientific computing. It seems to be making inroads into areas that previously would've only used Matlab. Haven't seen any Go in that area yet. Of the new entrants, Julia seems to be building buzz.
- clebio 13y agoe.g. Sage: http://sagemath.org/ http://sagemath.org/
- axaxs 13y agoPython should not directly compete with go. A sure sign of an inexperienced dev is "why I moved from Lang x to Lang y". You should use and know multiple languages, and know where they fit in. That said, for a lot of cases I think Go steps in where python comes up short, which is definitely performance and concurrency. But if I'm doing something that's too complicated to fit easily in a shell script, but doesn't warrant a lot of time, the brevity of python wins every time.
- ghshephard 13y agoSuggesting that python will soon enough become the new perl is high praise indeed. Perl runs a good portion of the internet, and is (and will likely for the next half century) be a very, very popular language. It's definitely the case that python was shoehorned into some places where it probably wasn't the best fit, but, at the time (1999-2001) was really the high-level dynamic language that had a lot of mindshare. A lot (almost all?) of companies that tried to use Zope as their application server back then would probably be looking at Java as their deployment platform today. Python sits in that nice "batteries included, easy to read, reasonably fast to write" space. I tend to write most of my scripts in Python, because a week later, I could never understand the perl code I wrote, but, for some reason, python code never had that problem for me. I don't expect too many people are writing quick "one-off" scripts in Go (I'd be interested to be proven wrong though), so perl/python/awk/bash all still have a place in people's toolkit.
- fidz 13y agoCould someone create/convert the PDF version? I don't think my computer good enough to open PPT* format Edit: not really needed, just loaded the dropbox preview, it is still readable
- yeukhon 13y agoThe 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 need to loop a list there is a good chance the index can help, and even if I don't need it it doesn't hurt to have one either. Simple is better. And the whole looping dict and get back the key only sucks too because you often need the value as well so you essentially do dict["key"] but why not just default return both key and value?
- asperous 13y agoExplicit is better than implicit. I think you think for is magical and could be modified like this, but really for just iterates over something. It's enumerate and items that are the magic. Enumerate zips a range onto a list, the ``index,element`` unpacks the zip. Items returns a list of (key,value) tuples and the key,value unpacks that. You couldn't modify the iterators because it would effect EVERYTHING. sum([1,1,1]) would now be sum([(1,1),(2,1),(3,1)]) AHH! And ``key in dict`` wouldn't work any more, since the iterator would return key,values. EEK.
- yeukhon 13y agoI never said it would be easy to implement or whether it would be actually possible. My complain is that what we are doing right now isn't convenient and is counter-intuitive. I don't write programming language so I wouldn't know how difficult it would be to change the grammar and the semantic of for. Being simple vs explicit is a political debate. I prefer if Python has simpler magical syntax.
- aidos 13y agoThat's totally against the ethos of python. I think you'll find that very few python developers would side with you on that change. If I'm iterating over something I'd like the elements of the thing I'm iterating over, not some weird results based on the type of iterator. In the (extremely) rare cases I need an index I wrap the list/whatever in the enumerate function. What are the use cases where you frequently need the index? I write and read a lot of python and I almost never see it. Maybe if you're working in a problem domain where it's a common issue you could create some abstraction to better handle it for you.
- mortenlarsen 13y agoAngry noscript user here. Visit URL... almost blank page... with non-working download button. Enable Javascript... Get .pdf named .pptx.
- tomp 13y agoWhy does Guido think that slices syntax is screwed up? I mean, it's not exactly natural, but at least it's consistent (first bound is included, second is excluded): a = '12345' a[0:-1] == '1234' a[-1:0:-1] == '5432' Personally, I think that "downcounting" slices are rarely used. For code clarity, I prefer reversing the string/list first.
- JeffJenkins 13y agoThis came up on python-ideas recently, there was a long thread: https://mail.python.org/pipermail/python-ideas/2013-October/023733.html https://mail.python.org/pipermail/python-ideas/2013-October/...
- izzle9 13y agowhoa did he just say static analysis is the future?
- andreisoare 13y agoyeah, I'd love to understand the reason behind that statement.
- nly 13y agoPyPy?
- masklinn 13y agopypy is dynamic analysis.
- nly 13y agoSemantics. Pypy's RPython dialect is "a restricted subset of Python that is amenable to static analysis", to quote the PyPy website.
- masklinn 13y agoRPython and Pypy are different things. RPython is a restricted subset of python indeed, but its purpose is to be a toolkit for implementing virtual machines. It is not and does not aim to be a general-purpose programming environment. PyPy is a JITed Python runtime implemented in RPython. The relation between PyPy and RPython is more or less the relation between CPython and C.
- bsaul 13y agoThat line made me feel warm and fuzzy inside. He also mentionned mypy which i thought was a one man lonesome soon to be abandonned ( but absolutely fantastic) project.
- midgetjones 13y agoI 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".
- pdonis 13y agoThat was true early on in Python 3, but it's not true now.
- jzwinck 13y agoPeople have been saying this for three years, but it's not true now.
- caligo 13y agoAre those books, books that came out this year?
- jzwinck 13y agoAs someone who learned Python when 3.2 came out, I completely agree with you. I have only really used Python 2.7! Because too much shit is broken (NumPy, hello). Because Python 3 has been the default on basically no system ever (OK, maybe this is changing right now, slowly). As Guido says, it's been five years and it will take another five. This whole experiment has been a huge misstep for Python, an absolutely massive gaffe. Some of Python's peers did it too, roughly around the same time (Perl, and to a lesser extent Ruby). Python (Guido?) noticed its own maturity a bit too late. The damage is incredible; along with the performance stuff (which is in a way easier to overcome) this may be a key factor leading to the fall of a great language.
- nron 13y agoOn the other hand, my experience has been very different: I learned Python when 3.2 was current as well, using Lutz' "Learning Python", which takes the approach of "teach Python 3, and explain how 2 is different whenever necessary". I've followed suit and taken the approach of writing Python 3 code first, and to make it work on 2.7 only when I need to, which I found fairly easy to do, though it can make the code a bit uglier sadly (writing cross-version-compatible metaclass code is the one that annoys me, since it adds some verbosity). I'm looking forward to 2.x dying out to eliminate that retrofitting step (and it's happening: the improving dependency landscape means I find I have to do it less and less often), but I've not experienced any major pain overall. From where I'm sitting, Python 3 is a better, cleaner language, and as someone new to Python, I'm happier for it.
- pmelendez 13y agoThis is my problem with Python: "Rename func_name —> __name__, etc Rename .next() —> .__next__()" Too many ugly renames, too few alternatives of doing things. To be honest the only attractive thing to me is all the libraries that they support but I don't find the language itself interesting.
- sillysaurus2 13y ago__ is basically a namespace for official language extensions. How would you suggest they do it? Prevent "next()" from being a valid method name?
- pmelendez 13y agoThat has been addressed in some many other ways by several languages that goes from the C++ way where you actually have namespaces to the C way where you don't worry about it and pick another name. From all of them I find this the most odd way to address it, specially when python was supposed to improve legibility by design (at least for me those underscores are very distracting)
- deleted 13y ago[deleted]
- masklinn 13y agoEr... they are methods not functions. Tell me how does the C++ way namespace methods within an object?
- chilldream 13y agoThe underscores are distracting on purpose; any method surrounded by double underscores is one that you're virtually never supposed to explicitly call (there's a builtin `next(foo)` in Python 3, for instance)
- mhenr18 13y agoThere'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.
- deleted 13y ago[deleted]
- justinmk 13y agoI'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 nonlocal variable modifier which (I guess) "promotes" the variable outside its local scope. Kind of the inverse of Java requiring 'final' to bind a variable to a closure.
- jzwinck 13y agoYou 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 sure, but that's only part of Python's audience, and probably won't be the longest-lived part.
- yen223 13y agoThe division change is good. I have a hard time understanding why you'd want 3/2 = 1 as the default behaviour.
- deleted 13y ago[deleted]
- TylerE 13y agoImagine 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.
- andyl 13y agoIt 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?
- lmm 13y agoIt'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.
- krakensden 13y agoIt'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.
- craigyk 13y agoding ding ding!! It was not ambitious enough for breaking backward compatibility.
- smnrchrds 13y agoMaybe not in the world of ASCII, but the new Unicode system scream seems pretty loud to me. When I decided to use pelican for a non-English blog, I thought it would be piece of cake; just changing the theme and plugging a calendar converter and I would be done with it. In reality, I had to fork pelican and the calendar library (which was not well-maintained) and bang my head to the wall for three days to make them work together, all because of the whole string/unicode seperation and the fact that things work automagically as long as you're just using ASCII.
- gcr 13y agoDoes this get easier or harder in python 3? I like the explicit separation that Racket has between "here is a buffer of binary data" and "here is a sequence of Unicode characters," and (looking on the outside without working with it), I'm glad that Python 3 began to adopt some of that.
- mixmastamyk 13y agoAs a dev that hasn't been able to move to Py3 yet (but will soon), I'm wishing they'd fix the rest of the issues, bundle PyPy, and ship Python 4 instead! Make it a compelling upgrade. Then Py3 could be nicknamed "Vista," I suppose.
- U2EF1 13y agoempty dict: {:} empty set: {} Ah, the road not taken.
- michielvoo 13y agoQuestion for the professional Python developers: do you (on a daily/weekly/monthly) basis switch between projects in Python 2 and Python 3? Is that hard to do (e.g. do you have to constantly and consciously remind yourself of syntax/semantic differences), or does your mind sort of automatically adjust to the new/old patterns?
- _random_ 13y ago"People positively hate incompatible changes – especially bad for dynamic languages", "Never again this way – the future is static analysis and annotations". Wouldn't it be better to pick a better-suited language then? John Carmack put it nice way: "One of the lessons that we took away from Doom 3 was that script interpreters are bad, from a performance, debugging, development standpoint. It’s kind of that argument “oh but you want a free-form dynamically typed language here so you can do all of your quick, flexible stuff, and people that aren’t really programmers can do this stuff”, but you know one of the big lessons of a big project is you don’t want people that aren’t really programmers programming, you’ll suffer for it!"
- LBarret 13y agoEpic might disagree, the UnrealEngine is heavily scriptable. This was one of its major selling points in the last generation. I have a huge respect for Carmack but some other people prooved him wrong in the past. His opinions are often taken as gospel but more discreet people (like Sweeney) may have different and a s worthy points of view.
- rpedela 13y agoDoes Python 3 fix the import system? Can I import a file from any location in the file system?
- baq 13y agoyou always could, see __import__ and imp module.