4 ms·

In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611 htt

by brachi 11y ago

In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611 https://youtu.be/PiBfOFqDIAI?t=1611

icebraining 11y ago
What's sad is that Firefox already had Python working inside <script> tags (for addons only, though) back in 2005: https://bugzilla.mozilla.org/show_bug.cgi?id=255942 https://bugzilla.mozilla.org/show_bug.cgi?id=255942
- bzbarsky 11y ago
  A few notes on that implementation, since I have some firsthand experience with both the implementation and its removal: 1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time). 2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't. 3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.

by brachi 11y ago

In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611 https://youtu.be/PiBfOFqDIAI?t=1611

icebraining 11y ago

What's sad is that Firefox already had Python working inside <script> tags (for addons only, though) back in 2005: https://bugzilla.mozilla.org/show_bug.cgi?id=255942 https://bugzilla.mozilla.org/show_bug.cgi?id=255942

bzbarsky 11y ago
A few notes on that implementation, since I have some firsthand experience with both the implementation and its removal: 1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time). 2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't. 3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.