logoalt Hacker News

necovek • yesterday at 4:25 PM • 4 replies • view on HN

The type of dynamic language gymnastics done with Python is huge: any sufficiently well known library basically employs some sort of meta-programming of the language:

  * Typing is a non-obligatory add-on to the syntax
  * SQLAlchemy and other ORMs override basic operators like "=" and employ metaclass programming heavily to create Python-like SQL query builders
  * Pytest rewrites all the assertions as it side-steps bytecode generation (so your .pyc files are different than what they would be without pytest)
  * Many libraries depend on monkey-patching live library calls, including ones to external dependencies
  * The way async was added in is another bolt-on where the same code behaves differently in different contexts
  * Decorators can introduce any side-effect you imagine, and nobody (including core libraries) follow the golden rule of "don't do, only decorate"
  * Many debugging and profiling mechanisms (including REPL) depend on these properties to function — including observability tooling like Sentry, Datadog etc.
  ...
JavaScript never had that level of flexibility (for better and for worse), and by extension, it's easier to build an alternative implementation and keep it compatible with the rest of the world that claims to be JavaScript.

Replies

xorcist • yesterday at 5:32 PM

> The type of dynamic language gymnastics done with Python is huge

Have you seen Ruby?

pjmlp • yesterday at 7:08 PM

The common excuse that ignores Smalltalk, Self, Lisp Machines like Interlisp-D, and more recently Ruby.

All just as dynamic as Python, and with quite usable JIT compilers.

Or for that matter, PyPy and GraalPy do exist.

➕ show 1 reply
cyberax • yesterday at 5:41 PM

Operator overloading is a non-issue, it's just another form of method calls.

JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.

There are really no fundamental language reasons why Python should be more complex. From what I heard from a JIT developer, the main issue is not the code itself but the module system and code loading.

JavaScript was designed from the start to operate inside a sealed environment with only few external handles, with the code loaded upfront or added on-demand via "eval". Not so for Python, where native code modules can (and will) result in code loaded dynamically and it's hard to track what depends on what.

➕ show 2 replies
mistrial9 • today at 2:44 AM

> Many libraries depend on monkey-patching live library calls, including ones to external dependencies

someone please think of the monkey patchers!