Live data from Hacker News

Python is not a great programming language

gist.github.com

141–150 of 156 posts

Re: Python is not a great programming language

#141
post #31

It doesn't matter about its quirks. The most important thing nowadays is that it's reached critical mass. We're at the point where even non-developers can now cobble together a bit of python code to do simple things to make their jobs easier. This means it's here forever, IMO.

I remember our salesmen back in 90's cobbling together some Visual Basic or whatever it was called. So where it is now?

I'm not disagreeing with this, but you'd be surprised just how much VB still exists in the wild. Literally billions of dollars in revenues in financial service industry alone. Some trading desks use VB and Excel for the majority of trading. It's an abomination of epic proportions and well beyond critical mass, but it still exists precisely because of the reasons you mention - non-developers with some technical competency depending on it.

Whole other debate on benefits and drawbacks if this sort if thing however..

Re: Python is not a great programming language

#142
post #73

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

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

Re: Python is not a great programming language

#144
post #120

Earlier quoted context omitted.

There's some annoyances that have accumulated in python, like the inheritance patterns and too many underscored things. Decorators are kinda weird, too. I think Python is pretty awesome, but to pretend that it's super clean is a bit of a stretch. (a,) for a single-elem tuple-- avoiding colliding with (a) as a paren'd expression-- is wonky, too.

For the single element tuple case - what else would you suggest? You can always do Tuple(3) instead of (3,) if you'd like.

Could use something other than parens for bracketing tuples, so you don't have the conflict with the order-of-operations use of parens.

Re: Python is not a great programming language

#145
post #120

Earlier quoted context omitted.

There's some annoyances that have accumulated in python, like the inheritance patterns and too many underscored things. Decorators are kinda weird, too. I think Python is pretty awesome, but to pretend that it's super clean is a bit of a stretch. (a,) for a single-elem tuple-- avoiding colliding with (a) as a paren'd expression-- is wonky, too.

The tuple notation is one of those places where the obvious way is a distraction. A non-empty tuple doesn't need the ()s - it's the "," which makes the tuple! The following two are equivalent: x = 1, x = (1,) Of course, then there's no way to express the empty tuple using commas, which is where () comes in. Using (a,) is the belts-and-suspenders way of saying "this is a 1 element tuple".

Which is just further elaboration on the syntax being excessively special cased.

Re: Python is not a great programming language

#146

TLDR: if you’re a new programmer, don’t take this seriously. This person clearly doesn’t understand programming languages so well. Sorry to make this response an “ad hominem” one, I should revoke the claims. But it’s impossible if they don’t understand basic concepts of programming languages. For example, complaining that a dictionary key must be place in quotes. It’s not that “the key needs quotes”, but that you’re…

> any immutable object as a key Any hashable object, technically. Especially with custom objects, the two (immutability and hashability) don’t necessarily have to overlap, although it’s often a bad idea to have hashable, mutable objects

Mutable objects can't be hashed right?

Re: Python is not a great programming language

#147

Earlier quoted context omitted.

> any immutable object as a key Any hashable object, technically. Especially with custom objects, the two (immutability and hashability) don’t necessarily have to overlap, although it’s often a bad idea to have hashable, mutable objects

Mutable objects can't be hashed right?

As the comment you responded to says: An object can be mutable and hashable. E.g. any custom class by default has mutable and hashable instances.

Re: Python is not a great programming language

#148
post #147

Earlier quoted context omitted.

Mutable objects can't be hashed right?

As the comment you responded to says: An object can be mutable and hashable. E.g. any custom class by default has mutable and hashable instances.

How can you get both mutable and hashable instances at the same time?

Re: Python is not a great programming language

#149
post #147

Earlier quoted context omitted.

As the comment you responded to says: An object can be mutable and hashable. E.g. any custom class by default has mutable and hashable instances.

How can you get both mutable and hashable instances at the same time?

the only requirement on a hashable instance is that it implements a proper __hash__ function. The default implementation in CPython returns the address of the memory the object is stored at, so all instances are considered unique, values play no role at all.

Re: Python is not a great programming language

#150
post #145

Earlier quoted context omitted.

The tuple notation is one of those places where the obvious way is a distraction. A non-empty tuple doesn't need the ()s - it's the "," which makes the tuple! The following two are equivalent: x = 1, x = (1,) Of course, then there's no way to express the empty tuple using commas, which is where () comes in. Using (a,) is the belts-and-suspenders way of saying "this is a 1 element tuple".

Which is just further elaboration on the syntax being excessively special cased.

Oh, agreed. Just wanted to point out that I think the transition from "()" to "a," is the underlying problem, not from "(a)" to "(a,)"
Post reply on HN