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

31–40 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#31

Post by pdonis »

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…

And ``key in dict`` wouldn't work any more

The "in" operator is actually a separate operator; it doesn't depend on the dict iterator implementation. So you could keep the semantics of the two separate.

However, if the dict iterator semantics were changed, it would make sense to change the semantics of "in" as well--and since it doesn't really make sense to change the semantics of "in" (if you're asking if something is "in" the dict, you mean the key), that would explain why the dict iterator semantics are the way they are: the dict is a container of keys, not key-value pairs.

Re: Python 2 vs. Python 3: A retrospective

#32

Post by kansface »

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…

my_dict is a dictionary while items() and friends return an iterable. Your proposed change would lead to ambiguity and confusion- what determines how we should iterate (what does it return, when is it done)? How would we define custom iterables?

Re: Python 2 vs. Python 3: A retrospective

#33

Post by sillysaurus2 »

pmelendez wrote: post #25

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.

__ is basically a namespace for official language extensions. How would you suggest they do it? Prevent "next()" from being a valid method name?

Re: Python 2 vs. Python 3: A retrospective

#34

Post by pdonis »

zwegner wrote: post #24
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'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.

is the expected semantics of 'x in y' for sequence types the same as 'any(x == z for z in y)'?

For sequences that aren't strings, yes. :-) Strings are a sort of hybrid between "atomic" values and sequences, so their semantics can be different.

Re: Python 2 vs. Python 3: A retrospective

#35

Post by justinmk »

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

Re: Python 2 vs. Python 3: A retrospective

#36

Post by spamizbad »

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.

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

Python went everywhere Perl did and then expanded the map for "scripting languages". This didn't happen by accident: Python is, by design, very easy comprehend and learn. The Python community also one of the most newbie-friendly around, with mountains of freely available resources for beginners.

A programming language cannot be sustained by uber hackers, PLT nerds, and hipsters alone. You gotta make it reach the world (Like JavaScript, Java) or it'll never be"Tier 1" programming language. I have yet to see the Go's developer or community put forth a strategy to make this happen -- which is completely understandable given how new the language is.

Re: Python 2 vs. Python 3: A retrospective

#37

Post by rdtsc »

pmelendez wrote: post #25

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.

What do you mean by "ugly renames?" How many times in using Python did you have to look at .__next__() or .func_name ?

I have been using Python full time for the last 7 years and I very rarely have to call either of those function.

> Too few alternatives of doing things.

Can you explain that as well? What do you mean by alternatives of doing things? Like say you want to read a file and you might want to use a wider variety of options when opening the file handle or say you want to parse JSON and you'd like standard library to have more parsers available?

Re: Python 2 vs. Python 3: A retrospective

#38

Post by ghshephard »

yeukhon wrote: post #30
aidos wrote: post #20

Earlier quoted context omitted.

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

I almost never use enumerate in python - 90%+ of the time it's the values I'm interested in - an exception might be if I'm trying to print a numbered list - and it's just handy to have the index instead of incrementing a counter. In your scenario, though, to find the location of a specific item in a list:

  >>> b=['one','two','three','four','two']
  >>> b.count("two")
  2
  >>> b.index("two")
  1
  >>> b.index("two",2)
  4

Re: Python 2 vs. Python 3: A retrospective

#39

Post by pdonis »

yeukhon wrote: post #30
aidos wrote: post #20

Earlier quoted context omitted.

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_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 in that case why would you need the dict? (Technically, you could still iterate over the entire dict looking for your key, but that's extremely slow; the whole point of having a dict is to be able to do fast lookups of keys in order to retrieve their values.)

Writing .items() or surrounding enumerate() does not make your code look prettier, does it?

Neither does having to extract just one item from a tuple when I don't need the index. There's no way around the fact that one of the types of iteration (either just items, or index, item tuples) is going to have to be spelled with something extra. So just saying "I shouldn't have to type something extra" isn't a sufficient argument. You need to justify why your preferred type of iteration should be the one with the shorter spelling: and since your preferred type of iteration has extra baggage attached to it, it seems perfectly legitimate to me that it should have the longer spelling, not the shorter one.

find the location of a specific item in the list

That's what the "index" method is for.

Re: Python 2 vs. Python 3: A retrospective

#40

Post by pmelendez »

sillysaurus2 wrote: post #33
pmelendez wrote: post #25

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.

__ is basically a namespace for official language extensions. How would you suggest they do it? Prevent "next()" from being a valid method name?

That 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)
Post reply on HN