Hacker News Reader

> dynamically modify some of the scopes that names refer to

You can do some fairly disgusting things to name resolution in class bodies, but names within functions are resolved statically nowadays.

> as well as changing the actual prototype chain itself

You can change a class's MRO, if that's the closest analogue.

  class Foo:
      x = 'foo'
  
  class Bar:
      x = 'bar'
  
  class Baz(Foo):
      pass
  
  print(Baz.x)
  Baz.__bases__ = (Bar,)
  print(Baz.x)

In Python you can also hook your own entire custom import system into importlib, or just arbitrarily change the meaning of the `import` statement by replacing builtins.__import__:

  >>> import builtins
  >>> builtins.__import__ = lambda *a: "Too bad"
  >>> import foo
  >>> foo
  'Too bad'

You can use sys._getframe() to look in the current call stack and poke at variables:

  import sys
  
  def f():
      x = 3
      return g()
  
  def g():
      return sys._getframe().f_back.f_locals['x']
  
  print(f())  # 3

You can make your own class that inherits from types.ModuleType and use it to replace an existing module's class and add interesting new behaviors to its object:

  # foo.py
  import sys, types
  
  class MyMod(types.ModuleType):
      def __call__(self):
          return "Hello!"
  
  sys.modules['foo'].__class__ = MyMod


  >>> import foo
  >>> foo()
  'Hello!'

You can replace sys.ps1 by an object with a __str__ implementation to make a dynamic prompt in the REPL:

  import datetime, sys
  >>> class Prompt: __str__ = lambda self: str(datetime.datetime.now()) + ' >>>'
  >>> sys.ps1 = Prompt()
  2019-09-12 18:33:48.303692 >>>

Python has a lot of exposed detail.

> JS allows you to dynamically modify some of the scopes that names refer to, as well as changing the actual prototype chain itself. I'm not sure you can do such crazy things with Python classes/metaclasses.

> Of course, for v8 in particular, doing any of this crazy manipulation tends to set off alarm klaxons that kick your code off every optimization path, but the language still permits it.

Most of the real badness in JS (direct eval and the with statement stand out above everything else here) can be statically detected; the fact in Python that you can fundamentally change operation of things already on the call stack through prodding at things via the `sys` module makes this an order of magnitude worse (and yes, guards and OSR in principle can be used here, but it's very easy to end up with a _lot_ of guards).

> And for JS, very low overhead of calling into the DOM APIs (written in C++) is a necessary feature for having competitive performance. Arguably more so than in Python, since the overhead of the FFI trampoline itself here is considered a bottleneck.

Oh yes, it's absolutely essential, but the definition is on a very different level: we might have an interface defined in WebIDL that must be exposed to JS in a certain way, but how that's implemented is an implementation detail (and there's nothing in the public API stopping a browser from changing how their JS VM represents strings, for example; the JS VMs themselves don't really have totally stable APIs). Whereas in Python, the C API is public and includes implementation details like refcounting, string representation, etc.

You can't change the inheritance as far as I know after creation without some hacks, but you can change the class that an instance refers to which can kinda sorta achieve the same thing. You can't necessarily add properties to a base class and have all of those reflect immediately unless you use some hackery with class properties.

Example: https://github.com/dabeaz/python-cookbook/blob/master/src/8/...

> You can't necessarily add properties to a base class and have all of those reflect immediately

Are you talking about JS? You definitely can:

  class A {}
  class B extends A {}
  const b = new B();

  A.prototype.test = () => 'test';
  b.test();
  // => 'test'