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

21–30 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#21

Post by clebio »

_delirium wrote: post #9
lmm wrote: post #7

Earlier quoted context omitted.

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

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

e.g. Sage: http://sagemath.org/

Re: Python 2 vs. Python 3: A retrospective

#23

Post by zwegner »

justinmk wrote: post #19
mortenlarsen wrote: post #11

Angry noscript user here. Visit URL... almost blank page... with non-working download button. Enable Javascript... Get .pdf named .pptx.

> Angry noscript user Redundant, I think.

As a noscript user, I think you're probably right.

Re: Python 2 vs. Python 3: A retrospective

#24

Post by zwegner »

asperous wrote: post #14
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…

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

I've thought that dict.items() should be the default behavior for a while, but haven't really thought it through. The 'key in dict' example is interesting--is the expected semantics of 'x in y' for sequence types the same as 'any(x == z for z in y)'? That doesn't hold true for strings, as an example.

Re: Python 2 vs. Python 3: A retrospective

#25

Post by pmelendez »

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

Re: Python 2 vs. Python 3: A retrospective

#26

Post by jzwinck »

ChronosKey wrote: post #4
MBlume wrote: post #2

Can anyone else not read the last lines of some of the slides?

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.

Re: Python 2 vs. Python 3: A retrospective

#28

Post by ghshephard »

pstuart wrote: post #5

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

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

Re: Python 2 vs. Python 3: A retrospective

#29

Post by pdonis »

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…

I always find if I need to loop a list there is a good chance the index can help

You may always find this, but lots of people don't. I find myself doing lots of iteration that doesn't need the index.

and even if I don't need it it doesn't hurt to have one either

Yes it does, because you're adding extra code to compute the index to every iteration, whether it's needed or not. It's not a good idea to encumber such a basic language construct with any extra baggage; that's why the extra baggage is in "enumerate", so you only get it if you actually need it.

Re: Python 2 vs. Python 3: A retrospective

#30

Post by yeukhon »

aidos wrote: post #20
yeukhon wrote: post #17

Earlier quoted context omitted.

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

That'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…

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_dict or for item in my list. I think returning both key,value are more explicit than say remembering the default return value in looping a dict is a key, not value, or relying on remembering enumerate or items.

It is simpler to write such code, and if you just need one of the return values, just that one, they are named.

You want a use case. I will give you one: find the location of a specific item in the list. and if you use django, you know your template engine can read your psudeo python template code. And you often need that index.

Post reply on HN