Comment by akubera | Hacker News Reader

Comment by akubera | Hacker News Reader

Parent Full thread

Part of the problem here is clearly this person is mapping JavaScript idioms to python; in particular "Needing to put dict property names `{'in': 'quotes'}": these aren't object properties, these are keys in a map, and they can be and often are variables themselves, (also, can be any hashable type, not just strings) and I don't see how that can detract from the 'greatness' of python.

Also "foo['bar'] returns a KeyError", then saying sometimes this is resolved by "getattr(foo, 'bar', None)" -- the split between attributes and items are one of the best things about python.

I don't know why list comprehensions are "magic syntax", and you can't complain about having to type list(map(...)) and then complain that you don't like list comprehensions!

"You have to cast your data back to a list/tuple after using enumerate() and map()." -- I don't know what that means

"Different syntaxes for lists and tuples." -- Again, what? They're different types!

How is r'a\nd' less "goofy" than String.raw`a\nd` in JS or any other language with prefixed strings?

Python is clearly not for everyone nor for every problem, but in my opinion it is a great programming language.

> "Different syntaxes for lists and tuples." -- Again, what? They're different types!

Lists and tuples have different syntax in a weird and surprising way. List syntax is straightforward, just square brackets and commas. Tuple syntax pretends to be list syntax with parentheses but it's actually only about commas except when it isn't.

Typically you write `(a, b)`, but the parentheses are only for precedence, and can be left out if it's unambiguous: `a, b`. You can write a 1-list as `[a]`, but a 1-tuple is `(a,)` because `(a)` is just `a`. An empty tuple on the other hand is `()`, without any commas, and with parentheses doing something other than precedence. It's very ugly.

I can't think of a better way to fit it into the rest of the syntax but I still count it as a flaw.

It’s the one of those common situations where there’s no perfect solution, so one from a number of suboptimal ones needs to be chosen. This rubs random folks in random ways, and is endemic to language design. Just try to design one without no such compromise.

In this case the problem stems from the overloading of parentheses. There aren’t any more paired delimiters in ascii available unfortunately. Perhaps t[] could have been chosen, but as you see it isn’t exactly elegant either.

Ah, yeah I see; there's an ambiguity in parsing expressions and tuples which could lead to subtle typing bugs. There's another ambiguity that (a for a in b) is not a tuple, but a generator, while [a for a in b] is a list.

> "You have to cast your data back to a list/tuple after using enumerate() and map()."

I think he means you don't get a list/tuple back after applying enumerate and map. That's actually lazy evaluation and it's a plus. If you just want to iterate over the values, why create a list that you are going to throw away? Twice the effort for nothing.

I agree with you that this reads as someone expecting JS behavior in Python.

On the dict property name thing, you can do:

  {'a':1, 'b':2, 'c':3}

or

  dict(a=1, b=2, c=3)

I find the second syntax easier to read and write for dicts where all of the keys are static strings that are valid Python variable names.

> "You have to cast your data back to a list/tuple after using enumerate() and map()." -- I don't know what that means

I'm assuming that the author has a problem with the fact that those two functions return a generator and not a list.

They return an iterator, not a generator.

You are correct, I typed without thinking. But my point remains the same.

Reply on news.ycombinator.com