4 ms·

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 r

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".
  - crabbone 3y ago
    You have it all backwards. No, __slots__ isn't an optimization, it came before __dict__. Old classes allowed multiple inheritance. And they are not so different from the new classes. The difference is superficial. There were and still are many things in Python that were written w/o any thought or cohesive organizing principle, but, over time, they put some effort to make it look more uniform. For example, old errors didn't inherit from object, but eventually they were made to do so. Similarly, module type didn't inherit from object, but at some point it was made to do so. A lot of Python builtins were half-arsed reimplementation of object with a bunch of slots missing. > Not at all. @property is just one example of a descriptor. This is exactly why it's bad design. If one were to design object system with properties, they wouldn't need this patch. It would've been part of the system from the get go. There's no need for descriptors here or in general. The whole idea of decorators is a half-arsed attempt at macros... > Python is literally one of the only languages that has got rid of its "old garbage". No, absolutely not. They renamed things, but kept the implementation the same. Sometimes they added things, like in example with module type, to make it look more uniform. Sometimes they hid some functionality from the interpreted part of Python, but it is still accessible to C API etc. It's the same story with multiprocessing -- it was a failure from the start, but they never admitted it, and kept incrementing to make it an even bigger failure... while deep inside their hearts they knew it was a failure, so they also tried other things... which also failed (like multiple interpreters). When you read the C source of Python, the feeling that you get is that you are looking at someone who sucks at C, who struggles to make their code to run at least somehow. It's not the code of a person who knows their way around, can consider benefits and downsides of doing the same thing in different ways. It's a code of a person who adds asterisks and ampersands until it compiles, who's never heard of const-correctness, who doesn't try to minimize heap allocations... It's a code that you'd typically expect from a second-third year CS student.

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".
- crabbone 3y ago
  You have it all backwards. No, __slots__ isn't an optimization, it came before __dict__. Old classes allowed multiple inheritance. And they are not so different from the new classes. The difference is superficial. There were and still are many things in Python that were written w/o any thought or cohesive organizing principle, but, over time, they put some effort to make it look more uniform. For example, old errors didn't inherit from object, but eventually they were made to do so. Similarly, module type didn't inherit from object, but at some point it was made to do so. A lot of Python builtins were half-arsed reimplementation of object with a bunch of slots missing. > Not at all. @property is just one example of a descriptor. This is exactly why it's bad design. If one were to design object system with properties, they wouldn't need this patch. It would've been part of the system from the get go. There's no need for descriptors here or in general. The whole idea of decorators is a half-arsed attempt at macros... > Python is literally one of the only languages that has got rid of its "old garbage". No, absolutely not. They renamed things, but kept the implementation the same. Sometimes they added things, like in example with module type, to make it look more uniform. Sometimes they hid some functionality from the interpreted part of Python, but it is still accessible to C API etc. It's the same story with multiprocessing -- it was a failure from the start, but they never admitted it, and kept incrementing to make it an even bigger failure... while deep inside their hearts they knew it was a failure, so they also tried other things... which also failed (like multiple interpreters). When you read the C source of Python, the feeling that you get is that you are looking at someone who sucks at C, who struggles to make their code to run at least somehow. It's not the code of a person who knows their way around, can consider benefits and downsides of doing the same thing in different ways. It's a code of a person who adds asterisks and ampersands until it compiles, who's never heard of const-correctness, who doesn't try to minimize heap allocations... It's a code that you'd typically expect from a second-third year CS student.