TRANSCRYPT HAS A NEW CAPTAIN !!!

[geatec]

Dear users and contributors to Transcrypt.
It won't have escaped your attention that development of Transcrypt has had quite a long pause.
Due to personal circumstances I wasn't by far able to put in the energy I would have liked to.
Still I take this project very seriously, and I've been searching for a succesor to take the lead since rather a long time.
Today I am very happy to announce that John Sheehan, author of the book REACT to PYTHON, will take over the project per direct.

I've learned to know John as a dedicated and knowledgeable developer.
I hope many open source developers will support him in his task to get the project moving again.
In my view Transcrypt remains an amazingly performant, meanwhile highly Pythonic, solution to web development.
It strikes a good balance between page load speed and adherence to beloved CPython constructs like multiple inheritance and operator overloading.
Users, even with small bandwidths, will not suffer any performance loss.
Meanwhile it is my opinion that Python holds the upper hand over development of readable, maintainable code running in the browser.

I wish John wisdom and support from the open source community in further building out Transcrypt.
I'll remain a user, and maybe sometimes a contributor of Transcrypt, for sure!

Good luck to you all
Jacques de Hooge

[JennaSys]

Thank you Jacques for creating and maintaining the Transcrypt project for the last several years. I know for myself and many others how much it has changed the way we look at developing software for the web.

For those that don't know me, I've been a business application developer for the last 25 years or so, and over the last decade, have made Python my programming language of choice. I am the organizer for a local Python meetup group, as well as a Raspberry Pi/electronics meetup group. I have been using Transcrypt myself for about 3 years, primarily for developing React-based web applications. I was so impressed with how well Transcrypt worked for that task, as Jacques mentioned, I ended up putting my approach to creating React applications with Python in the form of the React to Python book. (It started out just as a talk for my Python meetup group but the content got to be a bit much).

I am going to do my best to keep in mind Jacques' philosophy and intent regarding Transcrypt as we move forward with the project, including keeping it lean, fast, reliable, compatible with CPython, and embracing JavaScript libraries rather than trying to replace them. I know there will be technical challenges along the way where I will need to rely on help from the community, so I do not intend for this to be a solo project!

The first big change you will see for Transcrypt will be a new home on GitHub. In the next week or so I will be moving it from Jacques' personal account to an organizational GitHub account where we can have a home for any Transcrypt related projects and keep them in one place. All issues, branches, and history that is here now will be preserved (according to GitHub) in the move.

Once the move is made, I will start taking a look at open PRs and open issues and begin addressing some of them. There is quite a bit there to digest, so I ask for your patience. Beyond that, there is a bit of house cleaning on the project I'd like to do as well. I will be posting a roadmap once I get a better handle on things. Once things get rolling, I do plan on releasing more frequent version updates.

I hope for your support and am excited about moving Transcrypt forward and growing the community of developers using it.

Thank you,
John Sheehan

[cirospaciari]

Really happy to see the project moving again! Thanks, @geatec to create Transcrypt, and thanks @JennaSys for maintaining it from now on!

[faerot]

Transcrypt is a great project with a proper direction to approach web development IMHO, but unfortunately it is too rough and has way too many "gotchas" to be used in production. I had to fork it a long time ago in order implement fixes and not to stall progress of my project. Some fixes required massive code rewrites. Hopefully now at least trivial fixes would be accepted promptly.

[JennaSys]

That is my plan. I want to focus on making small fixes and improvements this year, and then do a major version update next year.

I got busy the last few weeks so I haven't yet had a chance to move the repo to it's new home on GitHub yet. I need to do a build with a version bump and update PyPI at the same time so that it points to the right place.

For what I personally use Transcrypt for, I've been able to use workarounds for most of the issues I've encountered. So at some point I'd like to understand what the major issues were that you had (or just point me to the open GitHub issues).

[faerot]

Yes, at first I created a library with workarounds for stuff that had inconsistent / incorrectly working methods (as I use the same code for both CPython on server and Transcrypt on client), but it made the code ugly and over time I kept stumbling upon things that I cannot wrap in functions easily and had to always keep in mind while coding in Transcrypt.

As of the major changes that required code rewrites, for example I have completely reworked class generation code which allows to use expressions, i.e.:

class Test:
     A = 1
     B = A + 2

which in turn affected properties generation as there were some hacks involved.
Something like this PR is supposed to do: #725
(but that PR is a very naive and causes major scope problem, in order to properly implement that functionality more complex approach required).

I have also refactored for loop to account for #625, #631, #740 issues, Refactored slices and indexing to support del x[i] for both lists and dicts, throwing IndexError, del [i:j] support, negative steps support, etc. Not to mention numerous smaller fixes like missing functions/methods/arguments, etc.

There is way too many problematic stuff to use workarounds for all of them. At least when you are using it in a large code base. Especially considering that fixing the issue is often easier than writing a workaround. The bigger problem is not workarounds itself, but remembering all the places where you need to use them instead of normal python stuff.

If I finish my project that uses Transcrypt and it will be commercially viable to support it in the future, I plan to rewrite the compiler using PyLint's Astroid which is a way better AST parser than built-in one as it supports type inferring which will allow to get rid of all those numerous pragmas and generate fast code by default and avoid various edge cases in Transcrypt like having to write for x in d.keys() instead of for x in d in dict iteration, if len(seq): instead of just if seq: for sequence emptiness check and so on.

[JennaSys]

Thanks, I'll keep these in mind. Some of them I haven't run into myself yet, but I know how frustrating it is when you do.