3 ms·

What's the output of this program? class C(object): A = 1 B = 2 x = 3 y = 10 print(x - B) match y: case C.A: print('A')

What's the output of this program? class C(object): A = 1 B = 2 x = 3 y = 10 print(x - B) match y: case C.A: print('A') case B: print(y - B)

DangitBobby 5y ago
Do you not like the idea of pattern matching as a feature or do you not like the implementation details? This kind of seems like another clumsy scoping problem, no?
- dataflow 5y ago
  I would love a good pattern matching feature, but this is not it. And this is a seriously broken design at a fundamental level, not an "implementation detail". I actually have no clue how it's implemented and couldn't care less honestly. I just know it's incredibly dangerous for the user to actually use, and incredibly unintuitive on its face. It's as front-and-center as a design decision could possibly be, I think. And no, this is not really a scoping issue. Match is literally writing to a variable in one pattern but not the other. A conditional write is just a plain inconsistency. The sad part is both of these features are stumbling over the fact that Python doesn't have variable declarations/initialization. If they'd only introduced a different syntax for initializations, both of these could have been much clearer.
  - DangitBobby 5y ago
    > I actually have no clue how it's implemented and couldn't care less honestly. I guess I'm not sure where "design" ends and "implementation" begins? To me, how to handle matching on variables that already exists is both, because "pattern matching and destructuring" are the features and how that must work in the context of the actual language is "implementation". It being written in a design doc and having real world consequences in the resulting code doesn't make it not part of the implementation. Instead of quibbling over terms, I was much more interested in whether you like the idea of pattern matching. I think not liking the final form a feature takes in the language is fundamentally different from wholesale disliking the direction the language design is going.
    - dataflow 5y ago
      Design is the thing the client sees, implementation is the stuff they don't see. In this case the user is the one using match expressions. And they're seeing variables mutate inconsistently. It's practically impossible for a user not to see this, even if they wanted to. Calling that an implementation detail is like calling your car's steering wheel an implementation detail. But I mean, you can call it that if you prefer. It's just as terrible and inexcusable regardless of its name. And yes, as I mentioned, I would have loved to have a good pattern matching system, but so far the "direction" they're going is actively damaging the language by introducing more pitfalls instead of fixing the existing ones (scopes, declarations, etc.). Just because pattern matching in the abstract could be a feature, that doesn't mean they're going in a good direction by implementing it in a broken way. I guess like they say, the road to hell is paved with good intentions.
      - DangitBobby 5y ago
        > Design is the thing the client sees, implementation is the stuff they don't see. By this definition, bugs and other unintended consequences that the user encounters are "Design". > Calling that an implementation detail is like calling your car's steering wheel an implementation detail. Yes, if there weren't so many important decisions behind the outcome of a car being steered with a steering wheel, it could be a steering handle, or a steering joystick, or just about anything else that allows you to orient the front wheels of the car. The same is true of the pedals on the floor. Those could be implemented as controls on the steering wheel instead. Whether it's an implementation detail depends on the specificity of the feature in question. When I asked you about an "implementation detail", it was scoped to "the feature is pattern matching" (can I steer the car?) and you scoped it to "the feature is pattern matching without overwriting variables conditionally in surprising ways" (can I steer the car with failure modes that aren't fatal?).
        dataflow 5y ago
        > Instead of quibbling over terms and then all that?

What's the output of this program? class C(object): A = 1 B = 2 x = 3 y = 10 print(x - B) match y: case C.A: print('A') case B: print(y - B)

DangitBobby 5y ago

Do you not like the idea of pattern matching as a feature or do you not like the implementation details? This kind of seems like another clumsy scoping problem, no?

dataflow 5y ago
I would love a good pattern matching feature, but this is not it. And this is a seriously broken design at a fundamental level, not an "implementation detail". I actually have no clue how it's implemented and couldn't care less honestly. I just know it's incredibly dangerous for the user to actually use, and incredibly unintuitive on its face. It's as front-and-center as a design decision could possibly be, I think. And no, this is not really a scoping issue. Match is literally writing to a variable in one pattern but not the other. A conditional write is just a plain inconsistency. The sad part is both of these features are stumbling over the fact that Python doesn't have variable declarations/initialization. If they'd only introduced a different syntax for initializations, both of these could have been much clearer.
- DangitBobby 5y ago
  > I actually have no clue how it's implemented and couldn't care less honestly. I guess I'm not sure where "design" ends and "implementation" begins? To me, how to handle matching on variables that already exists is both, because "pattern matching and destructuring" are the features and how that must work in the context of the actual language is "implementation". It being written in a design doc and having real world consequences in the resulting code doesn't make it not part of the implementation. Instead of quibbling over terms, I was much more interested in whether you like the idea of pattern matching. I think not liking the final form a feature takes in the language is fundamentally different from wholesale disliking the direction the language design is going.
  - dataflow 5y ago
    Design is the thing the client sees, implementation is the stuff they don't see. In this case the user is the one using match expressions. And they're seeing variables mutate inconsistently. It's practically impossible for a user not to see this, even if they wanted to. Calling that an implementation detail is like calling your car's steering wheel an implementation detail. But I mean, you can call it that if you prefer. It's just as terrible and inexcusable regardless of its name. And yes, as I mentioned, I would have loved to have a good pattern matching system, but so far the "direction" they're going is actively damaging the language by introducing more pitfalls instead of fixing the existing ones (scopes, declarations, etc.). Just because pattern matching in the abstract could be a feature, that doesn't mean they're going in a good direction by implementing it in a broken way. I guess like they say, the road to hell is paved with good intentions.
    - DangitBobby 5y ago
      > Design is the thing the client sees, implementation is the stuff they don't see. By this definition, bugs and other unintended consequences that the user encounters are "Design". > Calling that an implementation detail is like calling your car's steering wheel an implementation detail. Yes, if there weren't so many important decisions behind the outcome of a car being steered with a steering wheel, it could be a steering handle, or a steering joystick, or just about anything else that allows you to orient the front wheels of the car. The same is true of the pedals on the floor. Those could be implemented as controls on the steering wheel instead. Whether it's an implementation detail depends on the specificity of the feature in question. When I asked you about an "implementation detail", it was scoped to "the feature is pattern matching" (can I steer the car?) and you scoped it to "the feature is pattern matching without overwriting variables conditionally in surprising ways" (can I steer the car with failure modes that aren't fatal?).
      - dataflow 5y ago
        > Instead of quibbling over terms and then all that?