PyScript项目中JS Proxy在Python与JavaScript交互中的问题剖析

引言

在PyScript项目中，Python与JavaScript的交互是一个核心功能。然而，近期发现了一个关键问题：Pyodide和MicroPython两种Python解释器在处理JavaScript Proxy对象时存在不一致行为，这直接影响了跨解释器代码的可移植性。

问题本质

当Python代码通过FFI(外部函数接口)访问JavaScript Proxy对象时，两种解释器表现出截然不同的行为：

• MicroPython：仅支持js_proxy["key"]的字典式访问，而js_proxy.key属性访问会抛出AttributeError
• Pyodide：仅支持js_proxy.key属性访问，而js_proxy["key"]会抛出TypeError: 'pyodide.ffi.JsProxy' object is not subscriptable

这种差异导致开发者无法编写在两种解释器上都能正常工作的通用代码。

技术背景

JavaScript Proxy对象允许开发者创建一个对象的代理，从而可以拦截和自定义该对象的基本操作。在JavaScript中，obj.key和obj["key"]是完全等价的访问方式。

然而在Python中，这两种访问方式对应不同的魔术方法：

• obj.key → __getattr__
• obj["key"] → __getitem__

问题复现

通过一个简单的Proxy示例可以清晰展示这个问题：

const proxy = new Proxy(new Map, {
  get(map, name) {
    if (!map.has(name))
      map.set(name, Math.random());
    return map.get(name);
  }
});

在JavaScript中，proxy.test和proxy["test"]都能正常工作且结果相同。但在不同Python解释器中：

• MicroPython只接受proxy["test"]
• Pyodide只接受proxy.test

深入分析

问题的根源在于两种解释器对JavaScript对象到Python对象的映射策略不同：

1. MicroPython最初实现时过于严格，只实现了__getitem__方式
2. Pyodide则更倾向于Python传统，认为模块属性应该通过.访问

更复杂的是，Pyodide在内部进行了大量的类型检测，包括：

• 检查对象是否具有then方法(Promise检测)
• 检查next方法(迭代器检测)
• 各种品牌检查(brand checking)

这些检测会意外触发Proxy的get陷阱，导致不必要的副作用。

解决方案演进

1. 临时解决方案：通过Python包装器统一访问方式

import js
get = js.Reflect.get

def js_proxy(ref):
    class JSProxy:
        def __getitem__(self, name): return get(ref, name)
        def __getattr__(self, name): return get(ref, name)
    return JSProxy()

2. MicroPython修复：已提交PR使两种访问方式行为一致

3. 最佳实践建议：

   • 避免在Proxy背后使用Map/Set等特殊对象
   • 明确实现所有必要的Proxy陷阱(has, get等)
   • 在跨解释器代码中使用保守的访问方式

对PyScript项目的影响

这个问题直接影响PyScript的几个核心功能：

1. 命名Worker系统：workers[name]的动态访问
2. 存储抽象层：IndexedDB的键值访问
3. 模块系统：通过registerJsModule注册的JS模块访问

总结与建议

JavaScript Proxy在现代Web开发中越来越常见，Python解释器需要更智能地处理这类对象。建议：

1. 统一两种访问方式的行为
2. 减少不必要的类型检测和属性访问
3. 提供明确的文档说明JS对象映射规则

PyScript作为桥接Python和JavaScript的项目，处理好这类边界情况对开发者体验至关重要。随着两种语言交互的深入，这类问题需要更系统性的解决方案。