4 ms·

Ruby's cardinal sin: there's no way to `require` code without global side effects. e.g. https://twitter.com/tomdale/status/457282269342744576 https://twitter.c

• roywiggins 12y ago
  Technically this is true for Python as well though, right? You can't import a module without executing it.
  • riffraff 12y ago
    but you can namespace the import, which avoids _accidental_ global pollution i.e. import foo # creates only foo require 'foo' # can change everything In both ruby and python you can execute code that changes the global namespace from within a module, but you have to go out of your way to do it in python, while in ruby it's the default. The thing is: ruby has #load(true) to load a file in anonymous module, it would just need to return that module and we could build something reasonably close to python's import. (I think there was an RCR for this many years ago)
    • masklinn 12y ago
      > import foo # creates only foo Technically incorrect. The code within `foo` could alter anything itself accessible via an import, and it could walk up the stack to mess with the "current" stack frame of the module being defined by the import. It's generally not done and would be considered very bad form, but it's definitely possible. > In both ruby and python you can execute code that changes the global namespace from within a module, but you have to go out of your way to do it in python, while in ruby it's the default. The tweet is about monkeypatching existing structures though. And you can definitely do that in Python, including at import (though that's generally considered a Bad Idea, libraries which can do that such as gevent usually require an explicit call to patch or replace existing modules)
      • deleted 12y ago
        [deleted]
• xentronium 12y ago
  One man's sin is another's superpower.
  • yxhuvud 12y ago
    Yes, which is why having the ability to do both would be nice.