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

11–20 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#12

Post by tomp »

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

Re: Python 2 vs. Python 3: A retrospective

#14

Post by asperous »

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

Re: Python 2 vs. Python 3: A retrospective

#17

Post by yeukhon »

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

Re: Python 2 vs. Python 3: A retrospective

#18

Post by JeffJenkins »

tomp wrote: post #12

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

This came up on python-ideas recently, there was a long thread: https://mail.python.org/pipermail/python-ideas/2013-October/...

Re: Python 2 vs. Python 3: A retrospective

#20

Post by aidos »

yeukhon wrote: post #17
asperous wrote: post #14

Earlier quoted context omitted.

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

Post reply on HN