New version with many changes - request for testing

92 views
Skip to first unread message

Pierre Quentel

unread,
Jan 4, 2025, 4:52:35 PMJan 4
to brython
Hi all,

I have been working on a new release with a major change in the internal implementation of functions. The result is a significant improvement in the speed of function creation, it is now about 30% faster than CPython.

I have done my best to test the changes but they have so many impacts on so many scripts that before releasing a new version, I request those of you who have the time to test the current development version and report bugs on the Github issue tracker.

Thanks,
Pierre

Carlo Oliveira

unread,
Jan 8, 2025, 1:18:10 PMJan 8
to brython
I am just now testing many versions of brython for the worker function. Up to now, only the one I downloaded from the gallery example works. Where can I get a reliable source of that new version, so I can test it too?

ben levitt

unread,
Jan 14, 2025, 1:10:06 PMJan 14
to bry...@googlegroups.com
Hi Pierre,

I've done quite a bit of testing over the last few days, and have not found any problems.  Things my testing covers pretty extensively:
- Webworkers and messaging between them and the main thread.
- Interacting with a bunch of js libraries from brython.
- Lots of conversion both implicit and explicit between js objects/arrays and python dicts/lists.
- Lots of string, datetime, regex, math, try/except, timers, DOM manipulation, redirecting stdout and stderr.
- With debug at 0 and at 1.

Thanks for the continued improvements!

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/679d25db-cfad-40b1-a6f0-537b2eec4750n%40googlegroups.com.

Pierre Quentel

unread,
Jan 28, 2025, 5:18:00 AMJan 28
to brython
Thanks for the feedback. I have just released version 3.13.1 with an additional major change: a rewriting of the error reporting system, with an implementation of PEP 657, the one that explains how to generate reports like

>>> (1 /
...   ( 2 -
... 2))
Traceback (most recent call last):
  File "<python-input-18>", line 1, in <module>
    (1 /
     ~~^
      ( 2 -
      ~~~~~
    2))
    ~~
ZeroDivisionError: division by zero
>>>

with these funny ~ and ^.

CPython uses the instruction number in the generated bytecode; these is no such thing in Javascript so I had to implement something to simulate it.

For code like

x / 2

the generated Javascript now includes these lines

frame.positions = [[2,2,0,5]]  # (1)
$B.rich_op('__truediv__', locals.x, 2, 1) # (2)

In (1) an array frame.positions is created, indicating the location of an instruction by a 4-element list [lineno, end_lineno, col_offset, end_col_offset].
In (2), an "instruction number" is passed as the last argument of the internal function rich_op. If this function raises an exception, the instruction number is used in association with frame.positions to determine the location of the problematic instruction in the source code and generate the error trace.

It was fun to develop it, but tricky so there might be remaining bugs here and there.

Eilon

unread,
May 18, 2025, 2:07:42 PMMay 18
to brython
When I create an error like that: a = 200z, I get no line number.
Maybe I don't extract well the frame.positions
Can you please provide the exception code to extract frame.positions ?
Thank you
Message has been deleted

Pierre Quentel

unread,
May 18, 2025, 2:40:57 PMMay 18
to brython
Le dimanche 18 mai 2025 à 20:07:42 UTC+2, Eilon a écrit :
When I create an error like that: a = 200z, I get no line number.
Maybe I don't extract well the frame.positions
Can you please provide the exception code to extract frame.positions ?
Thank you

This is strange, in the online console at brython.info I get the expected error trace

>>> a = 200z
File "<python-input-0>", line 1
    a = 200z
        ^^^
SyntaxError: invalid decimal literal
 

Eilon Keret

unread,
May 18, 2025, 2:59:29 PMMay 18
to bry...@googlegroups.com
I did the test with the new dev version. Can you please provide me the code for handling the exception 🙏?

--
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.

Pierre Quentel

unread,
May 18, 2025, 4:18:32 PMMay 18
to brython
Le dimanche 18 mai 2025 à 20:59:29 UTC+2, Eilon a écrit :
I did the test with the new dev version. Can you please provide me the code for handling the exception 🙏?

It is the same error message with the current development version.

I'm not sure what you mean with "handling the exception". For syntax errors as in your example, it is the interpreter that detects the error and prints the formatted error message. If you want to catch it you have to use exec():

try:
  exec("200z")
except SyntaxError as exc:
  ...

You can try to get the positions with something like

import sys
frame = sys._getframe()
frame.f_code.co_positions()

as described in PEP 657, but you shouldn't need to access them to handle errors

Eilon Keret

unread,
May 18, 2025, 4:41:36 PMMay 18
to bry...@googlegroups.com
Ok, thank you very much!

So basically when :

try:
      exec('a=200z', None, None)
except BaseException as err:
exc = traceback.format_exc()
      lines = exc.splitlines()
      for i, line in enumerate((lines)): # reversed
          print(f"Line {len(lines)-i}: {line}")

I get a list of lines, unformatted with all the info about the exception. 
If I want to extract line number and message and error type, I need to do it by manipulating the text?
There is more "elegant" way to extract that info I need?

--
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.

Ed

unread,
May 18, 2025, 4:47:53 PMMay 18
to bry...@googlegroups.com
This is well covered in python docs:

The more "elegant" way would be to check standard python material before asking.




Eilon Keret

unread,
May 18, 2025, 5:26:26 PMMay 18
to bry...@googlegroups.com
Thank you very much for your kind words and wizdom Mr. ED

Reply all
Reply to author
Forward
0 new messages