Rewriting built-in types

28 views
Skip to first unread message

Pierre Quentel

unread,
Jan 12, 2026, 4:51:18 PMJan 12
to brython
Hi all,

The last commit in the master branch is more than 2 months old, which is an all-time record in the 13-year history of Brython !

But that doesn't mean I'm less active on the project, on the contrary: I am working like mad on a new branch called "tp_methods_2025", which consists in a total rewriting of the built-in classes implementation.

The main reason was to make the code for attribute resolution as straightforward as in CPython, just a few lines of code for object and type __getattribute__ methods, whereas the current code in Brython (object.__getattribute__ in py_object.js and type.__getattribute__ in py_type.js) is extremely long and hard to maintain. Fixing bugs such as the ones detected by Djoume Salvetti on unittest.mock meant adding even more code for special cases.

The new version will be much closer to the code of the CPython implementation. For instance, types are now implemented as Javascript object with (more or less) the same name as in CPython (tp_name, tp_getattro, etc). Methods are also implemented with the same type as in CPython (wrapper_descriptor, method_wrapper, etc.).

For the first time today the first test in the built-in test suite passes completely. Making all the tests pass will still take a few weeks, maybe months. I will keep you updated from time to time.

Best wishes,
Pierre

ben levitt

unread,
Jan 12, 2026, 5:19:28 PMJan 12
to bry...@googlegroups.com
Thank you Pierre!

I look forward to testing out your updated code whenever you're ready for more testing. 

Happy New Year,
Ben

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/brython/19458fae-945a-46b1-8cb4-14a8e0899ec4n%40googlegroups.com.

Djoume Salvetti

unread,
Jan 12, 2026, 5:58:35 PMJan 12
to ben levitt, bry...@googlegroups.com
Sounds very exciting! Likewise happy to test whenever ready to provide feedback :-)

-- 
  Djoume Salvetti

Kiko

unread,
Jan 13, 2026, 5:19:19 PMJan 13
to bry...@googlegroups.com, ben levitt
Merci, Pierre, for the hard work!!

Happy new year everyone.

Denis Migdal

unread,
Jan 14, 2026, 2:40:58 AMJan 14
to brython
Great news. :)
I'll try to take a look at the code when I'll have some time to kill.

Was S/RBrython somehow useful to you in some ways ?

Denis Migdal

unread,
Jan 14, 2026, 3:04:17 AMJan 14
to brython
Ouch, that's a LOT of code changes.
Could a CHANGES.md be quite useful, and help you afterward to announce the new version once released and to update the documentation ?

I'm not sure I understand why set's __le__ is a function and not a method (in the first commit).

Pierre Quentel

unread,
Jan 15, 2026, 7:18:16 AMJan 15
to brython
Le mercredi 14 janvier 2026 à 09:04:17 UTC+1, Denis Migdal a écrit :
Ouch, that's a LOT of code changes.
Could a CHANGES.md be quite useful, and help you afterward to announce the new version once released and to update the documentation ?

Yes, I plan to write a document to explain the design of this new version 
I'm not sure I understand why set's __le__ is a function and not a method (in the first commit).
There have been huge changes since the first commit. At time of writing, Python set is imprented as the JS object `__BRYTHON__.builtins.set`. It has an attribute `dict` (equivalent to tp_dict in the CPython code) which is a Python dictionary with string-only keys. The value associated with the key `__le__` is an instance of wrapper_descriptor, the same as in CPython.

I didn't dive enough in S/RBrython enough to see if I could use some parts of it in this new version; the reference is the CPython source code
Reply all
Reply to author
Forward
0 new messages