4 ms·

You are too naive when you think that someone thought about it. Many things in Python happened because that's how they were implemented initially without much

You are too naive when you think that someone thought about it. Many things in Python happened because that's how they were implemented initially without much thinking or at all. There was no plan, and, in the initial stages, I'd imagine that the author(s) were surprised that they'd even gotten this far. Famously, the whole object system in Python was implemented in like a few days. That included the design and testing too... It did see some changes over time, but there's a lot of petrified turd there that's increasingly difficult to get rid of.

mixmastamyk 3y ago
Arrogant bullshit, probably the worst non-spam comment I’ve seen on HN—congrats. https://peps.python.org/pep-0671/ https://peps.python.org/pep-0671/ Truth is, early vs late binding is a tradeoff. Python picked one, but not like the other is without edge cases either.
- colejohnson66 3y ago
  GP's point is that Python didn’t “pick” one but that it’s probably an accident of how the parser was implemented. It would see the `[]`, allocate a new object, then greedily assign it to the “variable”. The whole “tradeoff” argument doesn’t make sense when you consider that Python is the odd one out here with early binding. In fact, there’s been so many bugs with it that they had to invent a whole new syntax to fix it. When one says `intParam += 2`, why should they expect that to modify the default parameter? Yet when the default is a list, all of a sudden it’s fine. Python breaks the principle of least astonishment with default parameters, and it’s frustrating hearing people defend such a thing.
  - mixmastamyk 3y ago
    The point is that it wasn't an accident. It was picked for performance reasons. And Python isn't the only one that does it. Don't remember the exact list but it was given once in a python-dev thread regarding the mentioned pep.
- chlorion 3y ago
  I don't understand what's getting you all bent out of shape about this. Unexpected emergent behaviors are extremely common in programming language design. Even when carefully planning every language feature, unexpected interactions can and do occur, sometimes these things are not ideal. I am not very informed about Python's history here, but it's not far fetched that this behavior was not planned and just happened due to unexpected interactions of other features. Why would Python be immune to this? Are Guido and the rest of the Python contributors 1000x devs that can see infinitely far into the future and never make mistakes? All of Pythons quirks were actually planned from the very beginning I guess.
  - mixmastamyk 3y ago
    It was chosen, I listened to the debate around the pep. Go is talking out their ass.
  - mixmastamyk 3y ago
    It was chosen, I listened to the debate around the pep. GP is talking out their ass.
- crabbone 3y ago
  What does this trash have to do with my comment?
memefrog 3y ago
The "new" object system in Python ("new" 23 years ago in Python 2.2 and the only system in Python 3 (2008 = 16 years ago)) was strongly and widely debated and refined over time. Maybe the old object system, which hasn't been relevant for 20 years, may have been implemented in a few days? So what? All of JavaScript was invented in a few days - the entire language. Yet people around here seem to love the language.
- crabbone 3y ago
  I couldn't quickly find the source, but what I recall is this story: the basic and only data type in Python from the very start was tuple, and then Guido decided to add objects and did it in like over the weekend sprint of "intense thinking and coding". All the "discussion" wasn't really a discussion but post-rationalization and adoration of his "genius work". No sane programmer with a modicum of experience would've designed objects to have both __slots__ and __dict__. The @property thing was also a crutch to deal with bad "design" decisions which were never properly addressed... and, basically, everything that was done afterwards was done in an additive way, so the old garbage stayed forever and became more entrenched.
  - memefrog 3y ago
    You've imbibed a very strange, almost slanderous story and now you're repeating it as fact. But perhaps old-style classes were awful. I don't really remember. I haven't used them for a very long time, because new-style classes, which were definitely not implemented in a weekend, have been around for approximately forever. Old-style classes were obsoleted in 2002 and don't even exist in Python 3, which was first released in 2008. Old-style classes didn't have multiple inheritance or many of the customisation points that new-style classes have. >No sane programmer with a modicum of experience would've designed objects to have both __slots__ and __dict__. Python objects don't have both __slots__ and __dict__. __slots__ is an optimisation for those cases where performance is important and you don't need the dynamism of __dict__. There is also no need for such extreme language. >The @property thing was also a clutch to deal with bad "design" decisions which were never properly addressed... Not at all. @property is just one example of a descriptor. Python attributes are just attributes, but descriptors allow them to be more than just __dict__ accesses. It's a very clever and flexible system that allows for some very expressive metaprogramming. @property isn't special and it has nothing to do with "bad design decisions". >and, basically, everything that was done afterwards was done in an additive way, so the old garbage stayed forever and became more entrenched. Python is literally one of the only languages that has got rid of its "old garbage".

mixmastamyk 3y ago

Arrogant bullshit, probably the worst non-spam comment I’ve seen on HN—congrats. https://peps.python.org/pep-0671/ https://peps.python.org/pep-0671/ Truth is, early vs late binding is a tradeoff. Python picked one, but not like the other is without edge cases either.

colejohnson66 3y ago
GP's point is that Python didn’t “pick” one but that it’s probably an accident of how the parser was implemented. It would see the `[]`, allocate a new object, then greedily assign it to the “variable”. The whole “tradeoff” argument doesn’t make sense when you consider that Python is the odd one out here with early binding. In fact, there’s been so many bugs with it that they had to invent a whole new syntax to fix it. When one says `intParam += 2`, why should they expect that to modify the default parameter? Yet when the default is a list, all of a sudden it’s fine. Python breaks the principle of least astonishment with default parameters, and it’s frustrating hearing people defend such a thing.
- mixmastamyk 3y ago
  The point is that it wasn't an accident. It was picked for performance reasons. And Python isn't the only one that does it. Don't remember the exact list but it was given once in a python-dev thread regarding the mentioned pep.
chlorion 3y ago
I don't understand what's getting you all bent out of shape about this. Unexpected emergent behaviors are extremely common in programming language design. Even when carefully planning every language feature, unexpected interactions can and do occur, sometimes these things are not ideal. I am not very informed about Python's history here, but it's not far fetched that this behavior was not planned and just happened due to unexpected interactions of other features. Why would Python be immune to this? Are Guido and the rest of the Python contributors 1000x devs that can see infinitely far into the future and never make mistakes? All of Pythons quirks were actually planned from the very beginning I guess.
- mixmastamyk 3y ago
  It was chosen, I listened to the debate around the pep. Go is talking out their ass.
- mixmastamyk 3y ago
  It was chosen, I listened to the debate around the pep. GP is talking out their ass.
crabbone 3y ago
What does this trash have to do with my comment?

memefrog 3y ago

The "new" object system in Python ("new" 23 years ago in Python 2.2 and the only system in Python 3 (2008 = 16 years ago)) was strongly and widely debated and refined over time. Maybe the old object system, which hasn't been relevant for 20 years, may have been implemented in a few days? So what? All of JavaScript was invented in a few days - the entire language. Yet people around here seem to love the language.

crabbone 3y ago
I couldn't quickly find the source, but what I recall is this story: the basic and only data type in Python from the very start was tuple, and then Guido decided to add objects and did it in like over the weekend sprint of "intense thinking and coding". All the "discussion" wasn't really a discussion but post-rationalization and adoration of his "genius work". No sane programmer with a modicum of experience would've designed objects to have both __slots__ and __dict__. The @property thing was also a crutch to deal with bad "design" decisions which were never properly addressed... and, basically, everything that was done afterwards was done in an additive way, so the old garbage stayed forever and became more entrenched.
- memefrog 3y ago
  You've imbibed a very strange, almost slanderous story and now you're repeating it as fact. But perhaps old-style classes were awful. I don't really remember. I haven't used them for a very long time, because new-style classes, which were definitely not implemented in a weekend, have been around for approximately forever. Old-style classes were obsoleted in 2002 and don't even exist in Python 3, which was first released in 2008. Old-style classes didn't have multiple inheritance or many of the customisation points that new-style classes have. >No sane programmer with a modicum of experience would've designed objects to have both __slots__ and __dict__. Python objects don't have both __slots__ and __dict__. __slots__ is an optimisation for those cases where performance is important and you don't need the dynamism of __dict__. There is also no need for such extreme language. >The @property thing was also a clutch to deal with bad "design" decisions which were never properly addressed... Not at all. @property is just one example of a descriptor. Python attributes are just attributes, but descriptors allow them to be more than just __dict__ accesses. It's a very clever and flexible system that allows for some very expressive metaprogramming. @property isn't special and it has nothing to do with "bad design decisions". >and, basically, everything that was done afterwards was done in an additive way, so the old garbage stayed forever and became more entrenched. Python is literally one of the only languages that has got rid of its "old garbage".