Hacker News new | past | comments | ask | show | jobs | submit login

There is no 'horrible gotcha' with tuples of one element. Have you even tried generator expressions? Do you have any specific performance problem, or do you just suppose that you couldn't write sufficiently performant code in Python?

Overall, from your post, I don't believe you have used Python seriously.

I don't care what color Python would be, nor would I care what ice cream flavor it would be. Nor do I care whether it is cool on Lambda the Ultimate. Is this grade school?

If you are looking for a lowest common denominator, I think the language best fitting that description is C. I do not say this to damn C, which I rather like in its way. The core language is relatively simple and portable and is the closest thing that practical programming has to a lingua franca (not talking about academic stuff like ML).

If you can't understand why anyone would like C then it isn't at all surprising that you wouldn't understand why someone would like Python.

Use whatever you want for yourself, but let's be clear that this is a matter of you being too cool for Python, not of you having any real reason why it is a bad tool.




For what it's worth, I've used Python professionally and in several classes. I certainly don't have much experience in it, but it would be odd if I did--why would I use a language I don't particularly like too much?

You only say there are no horrible gotchas with tuples because you've never spent hours hunting down a bug and finding that you forgot a trailing comma. More pertinently, changing something like

    ("foo",
     "bar",
     "baz")
to

    ("foo")
actually breaks the code. This style is used often in configuration scripts (e.g. for Django) and certainly got me before. I don't really see what generator expressions have to do with anything.

The performance problem isn't a problem per se--the performance just isn't good. But this does not mean it's bad! That was really the whole point of my post; the performance, like everything else about the language, is unimpressive. In my experience, even naively written Haskell tends to perform better while being shorter and easier to write.

My point with Lambda the Ultimate was more general--I've noticed that the more programming language oriented a community is, the less people like Python. The people who spend the most time thinking about and working on different programming languages--the denizens of Lambda the Ultimate--are the ones who like it least. It's very much like music that musicians don't like.

What I meant by lowest common denominator is that you could get virtually anybody, regardless of skill level, to use Python. C is far more tricky--and has far more odd edge cases and ways to shoot yourself in the foot--than Python. It trades this for lower-level hardware access and performance, but this makes it far less of a LCD language than Python.

This is not a matter of "cool"--and it's not even a matter of Python being a bad tool. It's a matter of Python not being an outstanding, or, honestly, even a good tool. And, as I said, this is perfectly fine; there are plenty of reasons to choose a solid tool you know well over something that may even be strictly superior. I can even understand why people would like this; many people like something approachable and bland over something seemingly exotic but also exciting.

But this does not fit with Python's general hype. People trot Python out as the gold standard of language design and are rather proud of themselves (as the post starting this whole discussion parodied) without having the substance to back that attitude up.

And all this goes back to the original thesis: Python is not actively bad, but it is also not actively good--it occupies a rather uninteresting middle ground. This is only surprising in light of its somewhat incongruous reputation as one of the best languages in certain circles.


People who like programming languages are not the intended users. People who like programming are, and in my experience there is rather less overlap between these two groups than you might think.


Doing that makes it not a tuple but just a string that's in brackets.

Anybody that's done Python for more than a day will instantly know that you'd do ("foo",), and to be honest you'd more likely write it as

  (
      "foo",
      "bar",
      "baz",
  )
So removing the last two elements will not break the tuple.


I'm so confused. You seem to be saying that

> 4 * (3+2)

should throw:

> TypeError: unsupported operand type(s) for *: 'int' and 'tuple'

???

I beg to differ.


No, parent is saying that:

>>> isinstance(tuple, ("foo", "bar"))

True

>>> isinstance(tuple, ("foo"))

False

which is correct. In Python, a single-element tuple must end with a comma--otherwise it is just that element, e.g.:

"foo" == ("foo")

FWIW, OP is right--finding a bug related to this issue is almost a rite of passage for new Python devs.


I'm not clear on what in my comment you're saying "no" to. isinstance(tuple, ("foo")) being True is not a "rough edge" (or if it is anything people are ever confused by is a rough edge). If it were True, that would also mean you couldn't use parentheses to set the order of operations, since items inside parentheses would be tuples. That would be nuts.

IMO this is just an educational issue where people aren't taught that the comma is the tuple operator (e.g. `x = 3,4` is perfectly legal) and parentheses just come along for the ride to disambiguate other uses of commas. If I were king tuples wouldn't have the same syntax as argument lists (`f((3,2))` is pretty ugly), but both Python tuples and Python argument lists conform to a lot of people's expectations of how both those things should look.

The fact that duck typing makes tuples and literals (temporarily) indistinguishable to the interpreter is more of a rough edge of duck typing itself. Duck typing can result in tricky bugs in many scenarios well beyond singleton tuples.


I responded to this point (which was phrased as a question):

You seem to be saying that 4 (3+2) should throw: TypeError: unsupported operand type(s) for : 'int' and 'tuple'???

Parent wasn't saying that at all, and I was clarifying.


Sorry to belabor the point, but this is exactly what parent was saying.

> changing something like > ("foo", > "bar", > "baz") > to > ("foo") > actually breaks the code.

Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.


No, he's saying that the operation you perform to truncate the former to the latter is the operation you would logically expect to perform (i.e. removing the trailing comma), which makes the thing a string.

He's not actually proposing that a string be a tuple. He's just saying that a single element enclosed in parentheses doesn't work the way you'd expect it.


Thank you, Stavros.


You are quite welcome.


I don't get your tuple example. If you don't use the tuple operator - the comma - why would you expect to get a tuple?

People trot Python out as the gold standard of language design

Who?


> I don't get your tuple example ...

The point is that it's a subtle syntactical difference but a dramatic semantic difference. I think most newcomers to Python hit this.


I like how after all these paragraphs you've managed to avoid having to offer up your own personal example of a "good" and "outstanding" language. But have no problem labeling other languages as NOT being such, with very poor examples :P

You should get an achievement of some sort. Hackernews needs achievements.


Why were the examples poor? Also, if he'd have "Python is mediocre, and X is fantastic", the discussion would've moved to X. He was right in not doing that.

And why the bitterness?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: