6 ms·

Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. This is what Ruby developers mean when they say they optimize for dev

by bphogan 11y ago

Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. This is what Ruby developers mean when they say they optimize for developer happiness over bowing to the will of the computer. /uses Python regularly and enjoys it.

sanderjd 11y ago
> Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. Not really – all the code knows is to stringify objects, and it saw the object called `exit`, for which the stringified version is that error message. But nowhere in that flow does the code know how call anything that could exit the REPL. /doesn't use Python regularly and thinks the smart move would be to make the REPL understand certain things as commands instead of normal Python code.
- NoGravitas 11y ago
  Well, the __repr__ method on the 'exit' object is getting called. So that method could actually call sys.exit() and cause repl to exit. But it would be very rude and strange behaviour for calling a __repr__ method to exit the interpreter, or, indeed, to do anything other than return a string representation of the object.
  - sanderjd 11y ago
    Point well made.
  - fleitz 11y ago
    And quit calling exit isn't weird?
  - deleted 11y ago
    [deleted]
  - hyperpape 11y ago
    What someone more clever than me ought to do is write up a huge investigation of an obscure bug caused by exit.__repr__() calling sys.exit(), and then only at the end comment that it's not real, but could've been if Python went down this road.
  - telotortium 11y ago
    Why? quit and exit are imported exclusively at the REPL: https://docs.python.org/3/library/constants.html?highlight=exit#exit https://docs.python.org/3/library/constants.html?highlight=e.... Would it really be any worse than automatically assigning the result of the last expression to _?
- true_religion 11y ago
  If the REPL initiates an exit via throwing an exception (eg.g new QuitException ) and having the top level of the stack catch it then handle the termination, then you could have the stringification of exit throw that exception too. It's not really magic at that point. It's not really 'magic' at that point to me. Granted some people might say its surprising for stringifying an object to call sys.exit() or throw an error that'll cause exiting.... But within the context of the REPL its not surprising.
cookiecaper 11y ago
Those assumptions that "optimize for developer happiness" 95% of the time make the developer's life hell the other 5% of the time. It happens often enough that "explicit is better than implicit", within reasonable constraints like dynamic typing, is one of Python's core values, and experienced developers usually come to appreciate it. It's best to design an API that makes what's happening clear without being overly verbose or esoteric, and without making assumptions, especially not dangerous assumptions that may cause you to lose data (exit may close the REPL and cause you to lose your session when you forget that exit is a special word in REPL mode). My personal feelings are that Python has done a better job at this than any other major language. I have major projects in both Ruby and Python and I enjoy the Python ones 100x more because of this. This document partially explains why; DHH is normalizing shortcuts because it helps him gain new users, even though working around those same shortcuts becomes a major PITA when you need to go a little bit off the beaten path, which happens in one way or another in most real software. There is a way to make these things explicit with only marginally more typing/"effort" (for example, requiring parens to call functions with no arguments, making it explicit and obvious when someone is referencing a variable vs. when they're calling a function), thus avoiding the complexity down the road.
- TheOtherHobbes 11y ago
  Ruby + Rails has always been better at social engineering than any other language or environment.
- bphogan 11y ago
  > and experienced developers usually come to appreciate it. I find statements like this a bit condescending. It's like when Java developers say 'Oh, that's nice, but I work on big applications." "Obviously you don't get it because you're not experienced. Experienced developers get it." I'm sure that wasn't your intent. But it still irks me a bit. I've been writing software for a very long time, in many languages and paradigms over the years. I believe that qualifies me as an experienced developer. My years of experience tell me that if I only experience pain 5% of the time, then the 95% of the time I don't experience the tools I use making me do extra work more than makes up for it. :)
talideon 11y ago
Whatever method you take, whether it's a special case after reading a line, or some other weird hack, you're adding magic. With Ruby, this isn't a big deal because if `exit` is a function, then typing `exit` will call it, and you need to use the unary `&` to bypass this and have the callable treated the same way that Python does (which is roughly equivalent to a Ruby Proc). Ruby doesn't require the hack, but Python would, for better or worse.

by bphogan 11y ago

sanderjd 11y ago

> Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. Not really – all the code knows is to stringify objects, and it saw the object called `exit`, for which the stringified version is that error message. But nowhere in that flow does the code know how call anything that could exit the REPL. /doesn't use Python regularly and thinks the smart move would be to make the REPL understand certain things as commands instead of normal Python code.

NoGravitas 11y ago
Well, the __repr__ method on the 'exit' object is getting called. So that method could actually call sys.exit() and cause repl to exit. But it would be very rude and strange behaviour for calling a __repr__ method to exit the interpreter, or, indeed, to do anything other than return a string representation of the object.
- sanderjd 11y ago
  Point well made.
- fleitz 11y ago
  And quit calling exit isn't weird?
- deleted 11y ago
  [deleted]
- hyperpape 11y ago
  What someone more clever than me ought to do is write up a huge investigation of an obscure bug caused by exit.__repr__() calling sys.exit(), and then only at the end comment that it's not real, but could've been if Python went down this road.
- telotortium 11y ago
  Why? quit and exit are imported exclusively at the REPL: https://docs.python.org/3/library/constants.html?highlight=exit#exit https://docs.python.org/3/library/constants.html?highlight=e.... Would it really be any worse than automatically assigning the result of the last expression to _?
true_religion 11y ago
If the REPL initiates an exit via throwing an exception (eg.g new QuitException ) and having the top level of the stack catch it then handle the termination, then you could have the stringification of exit throw that exception too. It's not really magic at that point. It's not really 'magic' at that point to me. Granted some people might say its surprising for stringifying an object to call sys.exit() or throw an error that'll cause exiting.... But within the context of the REPL its not surprising.

cookiecaper 11y ago

Those assumptions that "optimize for developer happiness" 95% of the time make the developer's life hell the other 5% of the time. It happens often enough that "explicit is better than implicit", within reasonable constraints like dynamic typing, is one of Python's core values, and experienced developers usually come to appreciate it. It's best to design an API that makes what's happening clear without being overly verbose or esoteric, and without making assumptions, especially not dangerous assumptions that may cause you to lose data (exit may close the REPL and cause you to lose your session when you forget that exit is a special word in REPL mode). My personal feelings are that Python has done a better job at this than any other major language. I have major projects in both Ruby and Python and I enjoy the Python ones 100x more because of this. This document partially explains why; DHH is normalizing shortcuts because it helps him gain new users, even though working around those same shortcuts becomes a major PITA when you need to go a little bit off the beaten path, which happens in one way or another in most real software. There is a way to make these things explicit with only marginally more typing/"effort" (for example, requiring parens to call functions with no arguments, making it explicit and obvious when someone is referencing a variable vs. when they're calling a function), thus avoiding the complexity down the road.

TheOtherHobbes 11y ago
Ruby + Rails has always been better at social engineering than any other language or environment.
bphogan 11y ago
> and experienced developers usually come to appreciate it. I find statements like this a bit condescending. It's like when Java developers say 'Oh, that's nice, but I work on big applications." "Obviously you don't get it because you're not experienced. Experienced developers get it." I'm sure that wasn't your intent. But it still irks me a bit. I've been writing software for a very long time, in many languages and paradigms over the years. I believe that qualifies me as an experienced developer. My years of experience tell me that if I only experience pain 5% of the time, then the 95% of the time I don't experience the tools I use making me do extra work more than makes up for it. :)

talideon 11y ago

Whatever method you take, whether it's a special case after reading a line, or some other weird hack, you're adding magic. With Ruby, this isn't a big deal because if `exit` is a function, then typing `exit` will call it, and you need to use the unary `&` to bypass this and have the callable treated the same way that Python does (which is roughly equivalent to a Ruby Proc). Ruby doesn't require the hack, but Python would, for better or worse.