Tutorial

51 views
Skip to first unread message

Nick Antonaccio

unread,
Aug 30, 2024, 10:36:51 PM8/30/24
to brython
Hi all,

I made a tutorial for Brython:

https://com-pute.com/brython_tutorial/

I hope it's useful!

Denis Migdal

unread,
Sep 3, 2024, 3:29:24 AM9/3/24
to bry...@googlegroups.com
Hi,

Thanks for the link, I took a look at it quickly.

If your tutorial target beginners, I am not sure if Brython is pertinent. Brython is more intended for people already knowing Python, and wanting to create a website. If somebody doesn't know Python and wants to create websites, I'd assume that learning JS/TS would be more pertinent ?

Also, I think it is quite dangerous to encourage beginners to use LLVM/GPT, when they doesn't have the experience to properly judge the generated content. If we don't want to write too much code, maybe some CMS would be more appropriate ?


For your examples, maybe you can use an iframe instead of a picture ? That'd enable you to make interactive examples.
As your tutorial is quite long, you can also split into different pages.

I also think you should talk about WebComponent and events more in depth.


Didn't had the time to read more in depth, I have a train to catch today ;).
Hope, it'll help.

In few weeks/months, I'll have to publish a short course on Brython, but with the JS API. I'll share the link on the googlegroups too, so that you could read it too.
It is almost redacted, but I want to add interactive examples.

--
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 on the web visit https://groups.google.com/d/msgid/brython/093fb6b8-6965-48d0-8582-7953b17fb7ben%40googlegroups.com.

Ed

unread,
Sep 4, 2024, 1:53:48 AM9/4/24
to bry...@googlegroups.com
Thanks Nick.  I found your tutorial quite interesting.  Prose is well written, good flow and very readable.

Who is your intended audience?  People who never programmed probably need more explanation of basic concepts like algorithms, control flow, variable types, etc.  I wouldn't add that - it's available many other places, would bog down the text.  I see it more useful for people who already know python, but are new to web programming.  Or people who've done web programming in the past and want to try a full-stack python approach.

For me, the main benefit was seeing other approaches to a python stack.  It was nice to compare with my stack.  I used brython and http.server for years, with html and css front ends.  Used sqlite directly, never tried alchemy.  Last year I switched to nicegui and it's been fantastic.  Backend programming very similar to flask, with integrated frontend in Vue/Quasar.  Although it's meant as a complete environment, I find brython better suited to many client-side tasks.  The two work quite well together.

The AI build part is interesting.  In my experience, you have to be able to think like a programmer about algorithmic logic and detailed data types in order to build an effective AI prompt.  Many people can't do that.  If you're already a programmer, then AI can help with syntax and unfamiliar APIs.  Which again, makes the guide seem to me more suitable for existing python programmers.

The only real quibble I have is with this part at the end:
Learn to replace the Brython code examples in this tutorial with JavaScript jQuery, and you'll be smack dab in the center of the way web applications have most often been built during the past decade and a half.  After finishing this tutorial, it's not much of a jump at all to learn how to complete your front-end coding in JavaScript. From there, you may want to learn to replace all the front-end machinery entirely, with frameworks like React, Vue, Svelte, and others which have been incredibly popular in recent years.

The whole reason I use brython is to avoid javascript / jquery nonsense.  Python is a far better language, js has way too much stupidity baked in.  Recommending people jump from (br/p)ython back to js is like telling a gourmet chef to eat at McDonald's.  We're all here because brython is a better way.  If W3C had any sense, they'd make browsers support python natively.  But no, everyone wants to beat their head against the js wall...

Overall, well done example showing how to do full stack web dev in python.


--

Denis Migdal

unread,
Sep 4, 2024, 3:22:10 AM9/4/24
to bry...@googlegroups.com
> Recommending people jump from (br/p)ython back to js is like telling a gourmet chef to eat at McDonald's.

I'd like to disagree.
JS is a poorly designed language, but is native for browsers, with a massive number of libraries and tools for Web development.
Brython also has some instabilities in some of its components.

I'm here because I teach Web to students that only know Python. Still, I dev in JS/TS.

> If W3C had any sense, they'd make browsers support python natively.  But no, everyone wants to beat their head against the js wall...

There are already ways to execute Python in the browser, still Python isn't widely used.
W3C doesn't want to push Python, making browsers heavier, therefore with more risk of bugs/vulnerabilities.

And tbh, Python is hard to implement in an optimized way. Lot of liberties offered by Python kill performances.

Nick Antonaccio

unread,
Sep 5, 2024, 2:46:59 AM9/5/24
to brython
Thank you for the feedback Dennis and Edward.  The audience may likely include absolute beginner developers, and novice developers who've had some experience with Python, and/or other developers who are missing knowledge about some part of the web development stack.  The point of the tutorial is to introduce those groups to the full stack architecture, in a way that only requires using some Python.  The intention is to demonstrate how all the pieces work together, by example, not as a comprehensive introduction to programming skills.  I think Brython works nicely to do all that because students can become familiar with some Bootstrap classes, AJAX, an ORM, functions routes in Flask routes, etc. all making use of some very basic Python code.  The mention of jQuery is pertinent from my perspective, because it's an undeniably popular tool, it should at least be familiar to anyone doing web development, it's not at all a tremendous jump from using Brython, and Brython can help bridge that gap nicely for Python developers.  Including the recommendation to use AI is of course a topic that rubs some people the wrong way, but in my experience (40 years writing and teaching people), it would be irresponsible not to explain how that tool can be used to help learn how to write, debug, and understand code, and to work through the struggles which might in many cases stop some potential developers from continuing to learn.

Denis Migdal

unread,
Sep 5, 2024, 3:21:53 AM9/5/24
to bry...@googlegroups.com
One suggestion: maybe introducing the full stack architecture first : why ? what it is ? what does it contains (with a schema) ?

> The mention of jQuery is pertinent from my perspective, because it's an undeniably popular tool, it should at least be familiar to anyone doing web development

I think JQuery is nowadays a little obsolete now that we have more standardized JS.


> Including the recommendation to use AI is of course a topic that rubs some people the wrong way, but in my experience (40 years writing and teaching people), it would be irresponsible not to explain how that tool can be used to help learn how to write, debug, and understand code, and to work through the struggles which might in many cases stop some potential developers from continuing to learn.

Personally I think AI is good for productivity, when correctly used by experienced users in some given context, but I do not think it is good for learning or for beginners.

Ed

unread,
Sep 5, 2024, 5:34:17 AM9/5/24
to bry...@googlegroups.com
Didn't expect to find so many js fans here.

JS is objectively harder to read, write, and reason about than python.  Studies show this (as does the proliferation of WTF javascript websites).  Part of it is the language itself, a mish-mash of poorly thought-out features by a guy with no experience designing languages.  Part of it is widespread duplication / repetition of language features (three types of equals comparison, 3 different for loops, etc).  Part of it is the proliferation of redundant libraries.  Use jquery!  No use react!  No use jquery version >2.4.35!

If you like js, ok no problem.  Use what you like.

A few points to consider:
JS is a poorly designed language, but is native for browsers, with a massive number of libraries and tools for Web development.
Yes js has been around a long time and has many users.  So does McDonalds. 

Brython also has some instabilities in some of its components.
So you're saying that a one-man project building an interpreter / transcompiler on top of javascript that aims for 100% python compatibility may not be entirely bullet proof?  I'm shocked, I say, shocked!  It's amazing Pierre has made brython so incredibly stable and feature complete.  It took years of dedicated effort with the resources of Google to make js reasonably stable.

I'm here because I teach Web to students that only know Python. Still, I dev in JS/TS.
Ok that's your choice.  Brython is not just for people who only know python.  I know python and js.  I choose brython because it saves me untold time and effort.

There are already ways to execute Python in the browser, still Python isn't widely used.
Python isn't widely used because it isn't natively supported.  Ways to execute python in browser are not well known because there's no native support.  Put Google's marketing budget behind python in the browser and watch what happens (not Google themselves.  They have a bad history of abandoning frameworks every few years).

W3C doesn't want to push Python, making browsers heavier, therefore with more risk of bugs/vulnerabilities.
W3C has no problem adding web assembly, which has same drawbacks.  They simply don't want python because companies have too much invested in js.  If they wanted python, they could easily make it happen.  

And tbh, Python is hard to implement in an optimized way. Lot of liberties offered by Python kill performances.
So you program everything in C and assembly then?  What's more valuable, processor time or developer time?  This isn't the 1960's anymore.

JS was a performance pig 20 years ago.  Google et al poured mountains of cash into making js perform decently.  Do you think python is incapable of performing just as well?  Would you say cpython doesn't perform well enough?   Major websites disagree.  And faster python interpreters are available if needed.



dgront

unread,
Sep 5, 2024, 5:38:11 AM9/5/24
to bry...@googlegroups.com
I can just second to that.

I have my own suggestions on how to improve Brython usability, this however deserve a separate thread.

Best,
Dominik Gront

Denis Migdal

unread,
Sep 5, 2024, 8:32:13 AM9/5/24
to bry...@googlegroups.com
You are kind of missing the point. I am not here to claim that JS is a superior language to Python, or even whether I like JS or not.

> Yes js has been around a long time and has many users.  So does McDonalds.

Your comparaison makes no sense. McDonalds doesn't have a monopoly with strong barriers of entry...

>So you're saying that a one-man project building an interpreter / transcompiler on top of javascript that aims for 100% python compatibility may not be entirely bullet proof?  I'm shocked, I say, shocked!

Do you even understand that, in a professional environment, using a one-man project not entirely bullet proof is often an issue in itself ?

Even more when your application needs to be bullet proof, else you lose money ? What will they do if, one day, this "one-man" can't maintain the project anymore ?

> It's amazing Pierre has made brython so incredibly stable and feature complete.

I do agree with this. Pierre did, and still does, lot of works.

> It took years of dedicated effort with the resources of Google to make js reasonably stable.

This isn't true, and doesn't matter. The fact is, nowadays, JS is stable.

> Python isn't widely used because it isn't natively supported. Ways to execute python in browser are not well known because there's no native support.

This is false. TS (and others) are widely used while not being natively supported.

> Put Google's marketing budget behind python in the browser and watch what happens (not Google themselves.  They have a bad history of abandoning frameworks every few years).

Okay... so... will you pay for it ?
And please note that you'd also need, on top of the Python interpreter, a C library interpreter, while ensuring security against arbitrary code...

> W3C has no problem adding web assembly, which has same drawbacks.

And WebAssembly is designed for browsers, is low level, and enables to execute any language on the browser (though not on the web page main thread - i.e. no DOM access).

> They simply don't want python because companies have too much invested in js.
If they wanted python, they could easily make it happen.

Sure...

> So you program everything in C and assembly then?  What's more valuable, processor time or developer time?  This isn't the 1960's anymore.

Are you for real ???

1) Lot of Python modules ARE written in C/assembly for performances.
2) Sometimes processor time DOES matter. Why do you think so much is invested into optimizing interpreters ?

> Do you think python is incapable of performing just as well?

As I stated, some features prevent optimizations...

In SBrython I try to cheat as much as possible to generate fast and clean JS.
Still, I have to use a subset of Python as some features/edges cases require additional checks, and are therefore slower.

> Would you say cpython doesn't perform well enough? Major websites disagree.

Benchmarks disagree...

> And faster python interpreters are available if needed.

Like Cython, but it requires providing type annotations to help optimization...
Well, a little like what I am trying to do with SBrython, trying to have as much as possible known at transcription time to enable better optimizations...


Ed

unread,
Sep 5, 2024, 9:15:42 AM9/5/24
to bry...@googlegroups.com
Of course enterprise environments use js because it's better supported than brython.  JS has 25 years of corporate investment behind it.  As you admit, that decision has nothing to do with technical merits, only which has more support.  Your argument amounts to "js is better because it's more popular", just like McDonalds.

Using js is fine.  Telling others they have to "graduate" from brython to js to do "real" web development is not fine.

For many, many projects brython is a solid choice.  Not where enterprise support is needed (aka who can I blame when things go wrong? - although npm causes way more security problems and exposes countless companies to show-stopping security vulnerabilities, so enterprise reliability for js really isn't great).  In many other respects, brython is a perfectly suitable environment - mature, performant, stable.  Huge companies like Facebook and Google develop their own in-house languages and toolsets anyway.  They are perfectly capable of adopting brython for mission-critical products if they choose to.

At one time jquery, vue, react, etc were all new projects.  How did they become enterprise worthy?  Because developers like you and me decided to use them.  Brython is just as capable of doing the same.


Nick Antonaccio

unread,
Sep 5, 2024, 10:58:43 AM9/5/24
to brython
I didn't mean to set off a religious war :)  Also, I didn't mean to convey that moving on to use something like jQuery should be considered like a graduation to a better tool.  It's more about just being able to understand everything else that's out there.  The Fetch API, or Axios, or XHR, for example, are a lot easier to grok once someone understands how to use AJAX in Brython.  Those other things exist and they're used in projects.  Making the choice to use them isn't necessarily about choosing better or worse tools.  It's more often just about being able to understand how they've been put use in projects by other developers.  If someone has to continue using XHR to maintain compatibility in some environment where supporting old machines/OSes/browsers/development requirements, etc., it's not a far jump from using AJAX in Brython.  That doesn't mean XHR is better, or a graduation, just that using it can be understandable if/when needed.  The choice of which tools to use in a project isn't always necessarily the developer's...

Denis Migdal

unread,
Sep 5, 2024, 12:04:47 PM9/5/24
to bry...@googlegroups.com
> As you admit, that decision has nothing to do with technical merits, only which has more support.

I did give some technical arguments.

> Your argument amounts to "js is better because it's more popular", just like McDonalds.

My argument was never to say that JS is a better language.

> In many other respects, brython is a perfectly suitable environment - mature, performant, stable.

Brython still has performances issues on some parts (IIRC e.g. for regex), and for the stability, the github regularly has new issues.

Some parts are quite complex to properly handle, e.g. JS <-> Py objects conversions.
And re-implementing in JS some Python modules written in C takes lot of time, and is not easy.

> At one time jquery, vue, react, etc were all new projects.  How did they become enterprise worthy?  Because developers like you and me decided to use them. Brython is just as capable of doing the same.

You can't compare a framework with often a team of full-time maintainer with a whole langage transpiler maintained by one person.

If you want Brython to be more widely adopted, you need a more modern documentation, to develop tools like bundlers with advanced features like tree shaking, debugers/sourcemap generators, better syntax highlight/auto-completions in editors, etc.

One man can't do all of this alone. Pierre is already doing a lot to maintain Brython, while being very reactive, he can't do everything alone.

Reply all
Reply to author
Forward
0 new messages