Show HN: Transcrypt – Fast, small Python 3.5 to JavaScript transpiler(transcrypt.org)
transcrypt.org
Show HN: Transcrypt – Fast, small Python 3.5 to JavaScript transpiler
http://www.transcrypt.org
52 comments
My coding style took shape long before PEP8 or even Python emerged. I tried following PEP8 for a few months, but since I mosty use C++ and Python in combination, pure PEP8 didn't work on the C++ side of things. So I stick with a kind of geometric mean of my Fortran, Basic, Cobol, Algol, Ada, Pascal, Modula2, C, C++, Python, JavaScript, asssembler and PLC AWL coding styles. But that's just the way Transcrypt itself is coded. Feel free to follow PEP8 completely in your code using Transcrypt. It's parsed by the CPython parser, so no problem there. However, if you use JS libs they won't follow PEP 8 either. And that's probably something to accept, as, however big the Python world, one cannot ignore the JS world when programming for the browser. By the way of all those languages I like Python best. But since I write technical (signal processing) apps, C++ interoperation is an inevitable fact for me. To be more exact about the braces: I started out numerical programming in Fortran66, and wanted a formula to look like this: (a + b) * (c + d), so with blanks surrounding the braces, rather than (a+b)*(c+d) which I found harder to decipher at that time. I stuck with that ever since, for any braces, unless adjacent to each other.
Thanks for the response, man!
To be completely honest, I definitely don't follow PEP8 100% (especially in regards to continuing-line indentation) because to do so would make some lines quite nasty looking simply for compliance to guidelines (also, I've seen many many projects ignore those rules too). But I don't recall ever seeing any libraries break that specific spacing rule which as some others have pointed out, make the documentation look a bit.. unexpected.
In regards to: > if you use JS libs they won't follow PEP 8 either. > And that's probably something to accept, as, however > big the Python world, one cannot ignore the JS world.
I totally agree. I spend about half of my time writing JS and half in Python and I definitely don't try to enforce PEP8 guidelines onto JS code, simply because it's a Python style guide, not a JS guide. I would try to follow a largely accepted code style of the JS community if I was made aware of one, but there only seems to be a large collection of non-official guides, so just I try to adjust my code style to what seems to be common among all of the "nice"/readable code around the web, or, if I'm working in a large existing code base, the style that is followed in that codebase, unless there's reason good not to.
I guess my general approach is that I prefer to style the code I write based upon the language (sometimes, for example, this requires placing open braces in different positions), and I find this actually helps my mind to switch between languages as they have their own look-and-feel to them.
Thanks for reading, and thanks for writing a very interesting library!
In regards to: > if you use JS libs they won't follow PEP 8 either. > And that's probably something to accept, as, however > big the Python world, one cannot ignore the JS world.
I totally agree. I spend about half of my time writing JS and half in Python and I definitely don't try to enforce PEP8 guidelines onto JS code, simply because it's a Python style guide, not a JS guide. I would try to follow a largely accepted code style of the JS community if I was made aware of one, but there only seems to be a large collection of non-official guides, so just I try to adjust my code style to what seems to be common among all of the "nice"/readable code around the web, or, if I'm working in a large existing code base, the style that is followed in that codebase, unless there's reason good not to.
I guess my general approach is that I prefer to style the code I write based upon the language (sometimes, for example, this requires placing open braces in different positions), and I find this actually helps my mind to switch between languages as they have their own look-and-feel to them.
Thanks for reading, and thanks for writing a very interesting library!
On a related note, pep8 (the tool) will actually be renamed "pycodestyle" by request from Guido himself.
https://github.com/PyCQA/pep8/issues/466
https://github.com/PyCQA/pep8/issues/466
What whitespace? I took a glance and noticed only the tabs..
E.g.: https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/mo...
E.g.: https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/mo...
See https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/de...
There are spaces before subscript operators, before `.method()` calls, and between `def name` and `(param1, param2)`.
There are spaces before subscript operators, before `.method()` calls, and between `def name` and `(param1, param2)`.
Yep, as a Python dev that's used to Python looking a certain way, this is very offputting. This is a great project, and I would hate for it to look "off" by something as trivial as Javascriptish whitespace and formatting conventions.
You're encouraged to follow PEP8 completely for your Transcrypt apps and libs. As for interop with JS libs, following JS conventions is probably best, although some often use libs may acquire a PEP8 facade.
Does anyone have insight on how does this compare to Rapydscript (http://www.rapydscript.com/)?
Rapydscript came closest to what I was looking for. But I wanted multiple inheritance, assignment of bound functions, properties and recursive tuple assigment.
Thanks. I already have an use case in mind for this kind of transpiler, therefore I asked. I've toyed with Rapydscript a bit but the things mentioned in this thread and in the documentation, such as relative simpilicity, traspilation (is that even a word?) that retains the pythonic code structure, flexible use of Javascript libraries etc., tempt me to try also Transcrypt. Looking forward to it.
So you rewrote the whole thing.
Yes, after programming ever since I was 15, I've learned that it has to be one of both:
_ Either I have to accept the basic design choices made in a piece of code as is, and build upon it in the same line of thought
- Or, if I really don't want to live with that, I start out completely fresh, not even looking at existing code, since it will just distract me from my path
In this case I opted for the second approach. Many transpiler projects out there are somehow related. As you can see by the source code Transcrypt isn't. I needed a fresh approach to reach my goals (the shopping list in the docs). People ask: why not add this or that to an existing project. Answer: because it isn't that simple. For me multiple projects existing alongside each other isn't a problem, but a fact of nature. There exist many C/C++ compilers, prog languages, OS'es, processor chips. Diversity and survival of a rich, diverse set of fit-enough creatures is what drives IT as well, in my view.
Exactly. There are currently is also brython.
Stop reinventing the wheel everytime something you want is missing from a lib. Try to contribute to said lib first.
Otherwise, this adds noise, wastes ressources and splits point of focus in the FOSS community.
I understand the appeal of writting your own baby, I understand the ego part too.
But remember this is a projet you then have to maintain and document. People will ask about their problems with it on stackoverflow, they will type "X vs Y vs Z" on Google.
Creting a new project has consequences.
Stop reinventing the wheel everytime something you want is missing from a lib. Try to contribute to said lib first.
Otherwise, this adds noise, wastes ressources and splits point of focus in the FOSS community.
I understand the appeal of writting your own baby, I understand the ego part too.
But remember this is a projet you then have to maintain and document. People will ask about their problems with it on stackoverflow, they will type "X vs Y vs Z" on Google.
Creting a new project has consequences.
I don't mind supporting, maintaining and documenting it. I've taken a good look at Brython and it just isn't what I can use for my projects. Also the fact that there are cows and horses I don't consider a waste of Nature's effort. Building big banking offices is, in my view. But making something is just fun. The whole life is a waste of effort, afterall what's the purpose, unless you enjoy it... ;)
[deleted]
About the intended use:
Transcrypt’s niche are non-trivial web applications where, apart from looks, things like structure, overview, simplicity, explicitness and regularity start to count. This is where Python shines and Transcrypt with it.
Hackers/Tinkers should understand the difference between syntax and semantics, most of the devs love python because of its clean syntax (95%).
Having a lightweight syntax around the semantics of managed platforms will be a win here for any syntax language targeting JS, LuaJIT, BEAM, JVM, CLR, LLVM.
Having a lightweight syntax around the semantics of managed platforms will be a win here for any syntax language targeting JS, LuaJIT, BEAM, JVM, CLR, LLVM.
Well done JdeH. Being able to keep a python hat on when writing client side and server side code could be very useful.
I also like how you've kept the output as close to the original Python code as possible. The generated scaffolding code looks neat and easy to read too.
I also like how you've kept the output as close to the original Python code as possible. The generated scaffolding code looks neat and easy to read too.
Thanks. It had to be debuggable in the browser, so I paid a lot of attention to that. But I wanted the multiple inheritance in. The combination of lean, readable JS and multiple inheritance, is why I started the project.
I checked your example with solar system. Since it's calling directly document.getElementById, it would not be some valid Python code that I could run independently. Isn't that defeating the purpose of coding in Python first?
Purpose of Transcrypt is to be able to use Python in the JavaScript world. The call document.getElementById doesn't have meaning outside a browser. For non-gui debugging purposes module org.transcrypt.stubs.browser is present supporting the bare minimum. Of course someone could write a library supporting all kinds of DOM functions. But I don't think it would be very useful. The idea is to be able to do the whole web "chain" in Python. So CPython + a framework on the server, Transcrypt in the Browser (or, generally, JS client).
It's still valid python code, the libraries are just different.
I feel like all these python to javascript transpilers will be used as a crutch for those who know python but not javascript. The problem with that is javascript has spent well over a decade developing tool-chains, conventions, and best practices, to assist in web development. When people start trying to apply python to web development, they throw all that away.
The idea is to embrace the JS world to the max and not reinvent any wheels. So Transcrypt will cooperate with any existing JS lib. Only personal I code far more efficiently in Python, especially for bigger apps. But (as is elaborated in the docs) that's personal. I've coded quite complicated technical web apps in JS, but somehow it didn't fit me like Python does. For different people that will be different, I guess.
I agree with you as to the language (I just like Python a whole lot better than JS), but I always feel dirty writing in a non-native language, not to mention the pretty big commitment one makes when choosing a transpiler.
In Transcrypt's case, the commitment probably isn't that big, since the JS source is pretty readable (and so I can just migrate to that relatively easily if I want to), but it's still a bit of a hack.
That said, it looks like a great project, and I'll definitely give it a try and hopefully use it more widely.
In Transcrypt's case, the commitment probably isn't that big, since the JS source is pretty readable (and so I can just migrate to that relatively easily if I want to), but it's still a bit of a hack.
That said, it looks like a great project, and I'll definitely give it a try and hopefully use it more widely.
Commitment will require continuity, so in the long run I want it to be independent of me, except for technical input. I plan transfer it to a foundation in a few years. At the same time I'd like to keep a firm hand on the wheel to keep it lean and focused.
As for the 'hack' part: I am rather old... And I remember very lively people thought Kernighan and Ritchie C was a hack to avoid programming directly for a processor using a macro assembler.
I seem to remember an post here last week that mentioned how convoluted, overly complex, and downright user unfriendly the JS tool-chains, and conventions have become. It certainly didn't seem like it was written by a Python/Ruby/Java/Go dev either. If I remember correctly it was written by someone in the JS community.
I try to stay away from JS to the extent I am able due to the complexity.
I try to stay away from JS to the extent I am able due to the complexity.
I was thinking more the fact that anything transpiled to Javascript can potentially be run on services like Amazon Lambda via Node.js or other competing services that only run code from a small set of languages.
Don't forget you can use Python on Lambda now :)
Why not use a python->x86 compiler followed by a x86->asm.js compiler?
I don't know much about the project but I have a lot of experience with asm.js. Using asm.js has many drawbacks and should only be used if the tradeoffs are acceptable. Some of the large issues:
- A bad debugging experience (no segfaults on null, local variables are numbers instead of strings or objects, function pointer calls are super confusing)
- Much more difficult to interoperate with external JavaScript libraries
- Massive code bloat (you have to reinvent everything like arrays, strings, maps, regexes, memory management, etc. instead of just using the browser's built-in implementations)
- A bad debugging experience (no segfaults on null, local variables are numbers instead of strings or objects, function pointer calls are super confusing)
- Much more difficult to interoperate with external JavaScript libraries
- Massive code bloat (you have to reinvent everything like arrays, strings, maps, regexes, memory management, etc. instead of just using the browser's built-in implementations)
PyPyJs does that. It's complete, but loads very slowly. In practice that's a problem not so easy overcome. And debugging and JS interop is a problem.
Does it support yield from/async/await?
No. As soon as JS supports this, I'll work on that. If you work in an environment with multitasking primitives, you can use it via the appropriate JS API, though. In other words, anything you can do in JS, you can do in Transcrypt. But a standard Pythonic API to multitasking is on my wish list.
Why on earth are you using frames for that website?
Please rewrite it. Maybe hide the menu under some icon I don't understand is the menu. Override the scroll so it jars. Probably a good idea to show a blank page, until I click through to allow about 4-5 external scripts before I can see any text, another 2 scripts to show images, and whilst we are at it, make sure I cannot click any links without allowing another script.
At the moment, the site is too easy to navigate, the text too easy to read. Maybe use more images, big images, a 2mb+ background gif would be good. Oh, I forgot external scripts, throw some of those in, my laptop fan isn't whirring so it is underused.
yes, what a terrible website, please "improve" it
:-\
At the moment, the site is too easy to navigate, the text too easy to read. Maybe use more images, big images, a 2mb+ background gif would be good. Oh, I forgot external scripts, throw some of those in, my laptop fan isn't whirring so it is underused.
yes, what a terrible website, please "improve" it
:-\
Well, in fact, the only thing it had to be right now, is functional, which indeed I believe it is. There's no css, just hand coded html. And it was ready in a snap. But if I ever change it it will remain functional in the first place. It won't feature any floating menu buttons that try to escape your mouse button, or screenwide pictures of managerial looking types at a conference desk. Frames seem to be a bit difficult for search engines. But for now they'll have to do.
Using ScriptSafe, it actually does show a blank page, since ScriptSafe blocks frames by default.
Even in the HTML4.0 days, nobody liked frames. They were used while there were no viable alternatives. I absolutely don't love sites that show no content without loading javascript.
Because I haven't yet found the time to make something decent. It will change, but cannot promise when...
Believe it or not, some people are style-blind and/or html- or css-impaired.
As a side note: I found your extra whitespace before function arguments to be very strange. I haven't seen this type of spacing before. Is there a reason why you do this?
I personally use and encourage the use of the "pep8" python tool (link below) to validate my codestyle as I find it makes working with other developers easier (this extra whitespace is pointed out as an error).
pep8 tool: https://pypi.python.org/pypi/pep8