Modest Proposal

[Ed]

Two issues I recently ran into while developing brython apps:

1. When loading multiple scripts, an error in one means later scripts never execute.

This is not ideal when loading multiple independent modules on the page (one to display user data, one to handle form submissions / data validation, one to update data display, etc).

Is it possible to have interpreter wrap each module loaded with <script src=foo.py> in a try/except block, so failures don't block other modules on page from loading?  modules included in another module with "import", sure, cascading errors and stopping interpreter makes sense.  separate scripts are a different matter.

Wrapping each module myself in a giant try/except is not ideal.  Makes top-level functions look like methods by virtue of indentation.  Not to mention violation of DRY principle.  Doing it once at interpreter level - at least as a config option - would help.

2. cpython supports -tt option to forbid code with mixed leading spaces & tabs.  can brython support the same option for parsing modules?  I do my best to keep code consistent, but sometimes rogue edits introduce invisible spaces where they don't belong.  running such code in brython produces useless errors like "invalid syntax" at a line far away from the real problem, because invisible spaces changed indentation levels.

if you're striving for max compatibility with brython spec, -tt seems like a useful option to include.

[Denis Migdal]

IMO mixed indentation is a matter more of edition than execution.

You should configure some validations (e.g. linters, type checkers, etc) in your IDE.

For the try/except, maybe having an option on the script tag e.g. type="brython-app" to tell Brython to catch its exception ?
This would assume that such script is its own "application" ?

Still, you should manage your errors, either fix the underlying issue, or try to handle the error (e.g. cancel transaction, print an error message, etc).

--
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/CAF1%3DpDmME3KTmwqeP7OUHUuU59kWCuxkTqDmLODwbXTTipz1pg%40mail.gmail.com.

[Ed]

hey Denis,
you're right, linters & validators are good to have.  yet cpython supports -tt.  best to have multiple lines of defense.

agree, you should manage errors.  and also, unexpected things happen.  an error in `ls` doesn't block your next shell command from running.

the question is: what kind of execution model should brython have?  a bit more robustness can help.

To view this discussion visit https://groups.google.com/d/msgid/brython/CAFr00W5%3DrmiiPopw3nddz%3D7d1pReTxdeX-c%3DGtHQJu%2BaGPG%3DLQ%40mail.gmail.com.

[Denis Migdal]

Well, mix indentation shouldn't pass into production in the first place.
Generally, it is best to not do too many things at the same time. Instead, clearly separate responsibilities, to improve maintainability and testability, while reducing coupling. 

IMO, the best way would be to enable to plug checkers at different steps of the Brython pipeline (linters, type checkers, etc). I have to write a message about Brython architecture, but I do not have the time for now.


For Shell, this can cause issues in scripts. Indeed, in case of an error, you'd continue execution while being in an invalid state.
In REPL, you assume the user saw the error, and took it into account when writing the next command line.
 
You have the same issue with Brython: continuing execution while being in an invalid state. Brython has no way to know if the current script is, somehow, a dependency of another. Hence my suggestion to have an "app" status to consider it as its own "independent" application (which could even have some kind of isolation).

And yes bug happens, but IMO it is often better to stop execution than doing things in an invalid state, which can cause lot of issues.

[Pierre Quentel]

Le mardi 17 mars 2026 à 20:59:50 UTC+1, Edward Elliott a écrit :

Two issues I recently ran into while developing brython apps:

1. When loading multiple scripts, an error in one means later scripts never execute.

This is not ideal when loading multiple independent modules on the page (one to display user data, one to handle form submissions / data validation, one to update data display, etc).

Is it possible to have interpreter wrap each module loaded with <script src=foo.py> in a try/except block, so failures don't block other modules on page from loading?  modules included in another module with "import", sure, cascading errors and stopping interpreter makes sense.  separate scripts are a different matter.

Wrapping each module myself in a giant try/except is not ideal.  Makes top-level functions look like methods by virtue of indentation.  Not to mention violation of DRY principle.  Doing it once at interpreter level - at least as a config option - would help.

I have implemented this in commit 691e714. Can you check if it's working for you applications ?

2. cpython supports -tt option to forbid code with mixed leading spaces & tabs.  can brython support the same option for parsing modules?  I do my best to keep code consistent, but sometimes rogue edits introduce invisible spaces where they don't belong.  running such code in brython produces useless errors like "invalid syntax" at a line far away from the real problem, because invisible spaces changed indentation levels.

if you're striving for max compatibility with brython spec, -tt seems like a useful option to include.

I couldn't find a reference to this option in the official Python documentation. It doesn't show when I do python -help on my PC (Windows 10). The best I could find is this stackoverflow question ; apparently there are 2 levels, -t which issues a warning and -tt which throws an error. 

I am lukewarm to add options in general, and this one specifically as it is not widely documented.

[Ed]

Thanks Pierre, very kind of you.  I'll test shortly.

Interesting on -tt.  It was taught on day one of python programming when I started, a quarter century ago.  Never occurred to me that it might not be standard practice.

Indeed I found an excellent reason why.  As of python 3.0:

"The former -tt startup
option to raise TabError on ambiguous mixtures of tabs and spaces for
indentation has been removed as an option and is now the standard behavior."

see issue tracker and github thread

So -tt is now the default behavior.

What are your thoughts on whether brython should adopt?

--

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/968515a2-9b66-4e62-8d33-8f442d117f87n%40googlegroups.com.

[Ed]

Just realized I never sent this message - 

I confirm the latest commit fixes the issue of exceptions in <script> loaded modules.  Other <script> modules are no longer blocked from loading.  Even handles syntax errors.  Thanks Pierre.