since Python is a thoroughly mediocre language.
Care to elaborate?
Care to elaborate?
In short, it's a language best define by what it isn't: it isn't bad, but it also isn't good.
It isn't particularly elegant, but it isn't particularly ugly either. It isn't exceptionally expressive, but it's also no tarpit. It isn't very concise, but it isn't quite overly verbose.
It is the very essence of plainness. If languages had a color, Python's would be a dull gray.
An interesting thing to note is which communities do not like Python. For what it's worth, the least Python-endorsing site I've found is Lambda the Ultimate. That should definitely tell you something, although I suspect what it tells you depends entirely on your own preferences :P.
Python really is nothing but mediocre and uninspiring. Sure, it isn't bad, but I would like a language that is actively good.
The very interesting thing about all this is that, quite often, you need a mediocre language. So Python is actually a great fit for a bunch of startups--it's the modern lowest common denominator. But I--being deeply interested in programming languages--wouldn't want to work anywhere that settled on a language that way.
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.
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")
("foo")
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.
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",
)
> 4 * (3+2)
should throw:
> TypeError: unsupported operand type(s) for *: 'int' and 'tuple'
???
I beg to differ.
>>> 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.
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.
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.
> 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.
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.
People trot Python out as the gold standard of language design
Who?
The point is that it's a subtle syntactical difference but a dramatic semantic difference. I think most newcomers to Python hit this.
You should get an achievement of some sort. Hackernews needs achievements.
And why the bitterness?
No offense, but your youth is showing--it appears you haven't used it long enough to fully understand it (gotchas), have unrealistic expectations of purity, and aren't very aware of the preceding. Yet you still have strong opinions... like most of us experience will beat you down, give it time.
I wrote a few of these stinkers a decade ago and would laugh at them now.
Exactly, as you point out in the end. It's a language for people who are deeply interested in getting shit done. Rather than people "being deeply interested in programming languages".
You are acting out the 2nd (tower type) stereotype so well I can almost believe you are a parody.
I think everything you've mentioned is pretty defensible, particularly the readability bit. Honestly if a language does everything reasonably well, I think that's pretty awesome. I'm also curious what magical dynamically-typed interpreted language you prefer. The only mainstream general-purpose alternatives I can think of are Ruby (which is basically alternate-universe python) and Perl (which seems strictly worse), or are you into JavaScript or APL-derivatives? It's all a matter of taste of course, but I could probably write a much more vicious rant against any of those.