Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there a relatively quick program out there to accomplish at least the basics of this? Just a few regexes? I'm willing to do some manual conversion, but this is a pretty big set of scripts.
You can translate JavaScript to Python using Js2Py. It supports whole JavaScript and you can use it to translate large JavaScript modules like esprima.js (a JavaScript 6 parser).
Short demo:
>>> import js2py
>>> f = js2py.eval_js( "function $(a) {return a + arguments[1]}" )
>>> f
function $(a) { [python code] }
>>> f(1, 2, 3)
3
This is how the translated function looks like internally (it's rather ugly):
>>> print js2py.translate_js( "function $(a) {return a + arguments[1]}" )
from js2py.pyjs import *
var = Scope( JS_BUILTINS )
set_global_object(var)
# Code follows:
var.registers([u'$'])
#Js
def PyJsHoistedNonPyName(a, this, arguments, var=var):
var = Scope({u'a':a, u'this':this, u'arguments':arguments}, var)
var.registers([u'a'])
return (var.get(u'a')+var.get(u'arguments').get(u'1'))
PyJsHoistedNonPyName.func_name = u'$'
var.put(u'$', PyJsHoistedNonPyName)
Updated
Now several (4) years later this (almost certainly) can be done; though certainly not with RegEx.
I suggest future readers look to #Piotr Dabkowski's answer..
Or some of the other answers. (I don't know having not tried them)
Original Answer
Hm this is a hard one.
The definition of a compiler is translates from a higher level language to a lower level language.
eg python to machine-code.
or java to javascript (google has a rather famous compiler for this somewhere - its' what makes google doc easier to make)
Python to javascript compilers abound.
technically javascript to python would be a decompiler. (afaik)
I found some speculation about a javascript-python converter here: follow the tread through. it mostly speaks of how it wouldn't be too hard to do.
I can't find anything , but that doesn't mean it's no out there.
Regex is not suitable, regex is suitable only for regular languages.
programming languages are not normally regular languages. see this
This answer might be about 2 years late but how about js -> CoffeeScript -> python? If you use something like http://js2.coffee/ to convert to cs, then things like indentation and lists are already done for you.
If what you are asking is converting a few regexs in javascript to Python equivalent, the basics of regular expressions are mostly pretty standard. check out the Python re module doc. See if what you are using is documented. Also of interest to you is this page.
If you are talking about converting javascript code to Python equivalent, the best converter is you. Learn about Python, and then convert them manually. there is nothing else better than the human being. Programming constructs like loops, variables, arrays are pretty common and standard you will recognize instantly how to use them straight away.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
JavaScript source code can be converted to an AST. I am using SHIFT AST Parser to create AST from JavaScipt code.
Now I want to convert the generated AST back to source code.
I am very much confused here and trying to understand the fundamentals. I am hearing from my colleagues that AST can't be converted back to the source code. But for what reason?
One of colleague told me AST does not preserve the spacing and indentation will be lost while converting AST to source code.
Is it the only reason?
First of all, it depends on what you mean by "original source" code.
If you mean the exact same file on the exact same file system that you were editing when you wrote the software, the answer is that you can't. Obviously.
If you mean code which is character for character identical to the code you wrote, it is technically possible but unlikely in practice.
If you mean code that works exactly the same and "looks mostly the same", then yes, you can. (Depending on "mostly".)
The answer also depends on what AST implementation you are talking about.
Some AST implementations don't preserve comments or spacing / indentation.
Other AST implementations apparently can preserve comments; e.g. as decorations on the tree nodes.
It is theoretically possible for an AST implementation to preserve absolutely everything needed to reconstruct identical source code. (But I don't know of an example that does. It would be memory expensive and kind of pointless.)
What is the harm in not being able to recover comments?
Well it depends on what you want to use the regenerated source code for. If you intend to be able to replace the original code, then there are clear problems:
You have lost any (hopefully) useful comments that the programmer included to help people to understand the code.
It is common to embed formal API documentation in the form of stylized source code comments that are then extracted, formatted, etc. If those comments are lost, it becomes harder to keep the API documentation up to date.
Some 3rd-party tools use stylized comments for specific purposes. For example, a comment could be could be used to suppress a false positive from a static code analyzer; e.g. a # noqa comment in Python code suppresses a pep8 style error.
On the other hand ... this kind of thing may not be relevant for your use-case.
Now from the tags I deduce that you are using Shift-AST. From a brief scan of the documentation and source code, I don't think this preserves either comments or indentation / spacing.
So that means that you cannot recover source code that is character for character identical with the original code. If that is what you want ... your colleague is 100% correct.
However, character for character identical code may not be necessary, so this may not be a limitation. It depends on your use-case.
And you could investigate Babel as an alternative. Apparently it can preserve comments.
One of colleague told me AST does not preserve the spacing and indentation will be lost while converting AST to source code. Is it the only reason?
Clearly, No. (As my answer explains.)
Nope. An abstract syntax tree is abstract in the way that it abstracts away ambiguous grammar, such as whitespace and possibly also comments (if these are irrelevant to further processing). As there is usually no purpose in storing this information, it is worth dropping during parsing.
While one can't go back to "original source code", one can still go back to an equivalent representation which is usually called the canonical form.
Well, it's possible. If you're using shift-ast you can do it.
Step 1:
npm install shift-codegen
Step 2:
import codegen from "shift-codegen";
let programSource = codegen(/* Shift format AST */);
ProgramSource will return string. Write it to your file and use prettier to format your code.
There is an alternative to shift-ast is called babel gives so many benefits, transforms and template features. Also provides typescript, flow, jsx and comments and minification features.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
In the perl word (which I'm coming from), adding a final comma when creating an object does not have any bad side effects - in fact it's encouraged in case you want to add fields later;
this article, (one of many possible sources) says:
my %weekly_temperature = (
monday => 65,
tuesday => 68,
wednesday => 71,
thursday => 53,
friday => 60,
);
A couple more tips when working with key value pairs of a hash: the code is more readable if you vertically align the fat comma (‘=>’) operators and unlike C, Perl allows the last element to have a trailing comma, which makes it easier to add elements later without generating a compile error.
In the javascript world - as I understand it - the last comma is advised against - again, a sample tip from this (one of many) article:
var car = {
colour:'red',
wheels:4,
hubcaps:'spinning',
age:4
}
The main gotcha in this notation is IE. Never ever leave a trailing comma before the closing curly brace or you’ll be in trouble.
How can I catch this and similar "gotcha's" in my javascript code?
There are lots of ways to do javascript validation. I have a plugin that runs jslint in my IDE. We also have jslint running as a build task when we build our web application.
We even do gated check-in, failing the CI build if the javascript don't comply with the jslint validation, keeping a minimum level of integrity for our javascript code. Have a look at how to do this with your favourite build system.
Also, have a look at Gulp.js. It's a command line script tool that can trigger on save and run all kinds of tools, for instance javascript integrity tools like jshint or jscs.
Here's a tutorial on how to set up Gulp.js to do just that. You will need to install node.js first, as it uses NPM - the node package manager.
https://isimmons.github.io/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is there a good classification of standard javascript errors? For example, in java like programs, there are errors like ArrayIndexOutOfRange, resource leaks, race conditions etc.
Also, in Javascript few errors are not reported as exceptions (e.g., divide by zero). Are there any other similar behaviors that are not reported as runtime exceptions in javascript?
MDN has a great article about this, they can put it better than I ever could:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error#Error_types
Also, good classification here in the ECMA standard:
ECMAScript 5.1 (Current): http://www.ecma-international.org/ecma-262/5.1/#sec-15.11.6
ECMAScript 6 (Coming soon, some features already here in certain browsers): http://www.ecma-international.org/ecma-262/5.1/#sec-15.11.6
In terms of "not being reported as runtime errors", there are some evaluations of expressions that do not halt execution of code but return indicators like NaN, e.g.:
var a = "Hello";
var b = 3;
var c = a / b; // c is "NaN"
You can use the isNaN() function to check for this. Unfortunately I don't know of an offical definite list of these scenarios (if there are more) or even how you would classify them. I guess it comes down to experience and learning the features (or quirks depending on your perspective!) of the language.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Languages such as C++ will not work if semicolons are forgotten but other languages such as JavaScript will automatically include them for you.
I know from this article Do you recommend using semicolons after every statement in JavaScript?, that it is recommended to use semicolons and there are scenarios that can create unwanted ambiguities (such as dangling else in C++ when braces aren't used).
At some point in time there must have been a decision to make them optional (e.g. when the creators of JavaScript made the conscious choice to make it optional).
I would like to know why this decision was made and how it is beneficial to users of these languages.
Background: I am a novice coder and have only recently began learning JavaScript.
EDIT: To the comments that are saying it is bad in JavaScript, I know. I'm asking why it is allowed to happen in the first place, if most people consider it bad practice.
Regarding JavaScript, Douglas Crockford explains the origins of the idea in this video. (It's a great talk and it's really worth your time to watch it if you intend to continue pursuing JavaScript.)
This is a direct quote from the talk:
Semicolon insertion was something intended to make the C syntax easier for beginners.
As far as how it's beneficial to users of the language, Crockford explains in detail a few reasons why it's not beneficial, but rather how it introduces very serious ambiguities and gotchas into the syntax. One of the most notable cases is when attempting to return an object literal using a braces-on-the-left coding style (source from the video):
return
{
ok: false
};
Which actually returns undefined, because semicolon insertion adds one after return, and the remaining intended object literal gets parsed as a code block, equivalent to this:
return;
{
ok: false;
}
Trying to make a language easier for beginners can be a great source of well-intentioned blunders.
The author of the JavaScript language, Brendan Eich, has a blog post on this subject called The infernal semicolon on the topic of Automatic Semicolon Insertion (ASI).
Relevant quotes:
ASI is (formally speaking) a syntactic error correction procedure.
I wish I had made newlines more significant in JS back in those ten days in May, 1995. Then instead of ASI, we would be cursing the need to use infix operators at the ends of continued lines, or perhaps or brute-force parentheses, to force continuation onto a successive line. But that ship sailed almost 17 years ago.
My two cents: be careful not to use ASI as if it gave JS significant newlines.
Long ago, in the distant, dusty past, things like this were done primarily to make up for the fact that compile/link/run cycles were measured in hours at a minimum, and often ran more than a day. It could be (okay: was) extremely frustrating to wait hours for a result, only to find that the compiler had stopped at line 3 (or whatever) because of some silly typo.
To try to combat that, some compilers of the time tried to second-guess your intended meaning, so if a typo was minor enough (for some definition of "minor enough") it would assume it knew what you really intended, and continue compiling (and potentially even executing) despite an error.
Those who fail to study history are doomed to repeat it. A few who are just too arrogant to learn from history repeat it as well. There's probably room for considerably debate about the exact sort of character defect that would lead a language designer to make this mistake at the present time. There is much less room (none at all, really) for argument about whether it is a mistake though--it clearly is, and an inexcusable one at that.
in javascript, the semi colon is a statement seperator, but so is newlines, so you don't need them if you have a statement per line.
other languages, like C++, only have ; as a seperator, and whitespace like newlines, do nothing. There are pros and cons
in C++ it means the syntax is consistent
if you write
int x=0;
x++;
if you then compress to one line, its the same general syntax :-
int x = 0; x++;
in javascript if you write
var x=0
x++
then if you compressed to one line
var x=0 x++
would be a problem
you'd need to do var x=0; x++
So, the big thing is whether whitespace is significant or not. Ideally a language would consistently use one mechanisim. But for javascript it is mixed so it leaves a bit of ambiguity when to use ;
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
JavaScript is said to be a "loosely-typed" language. This is due to the fact that the runtime allows operations to be performed on operands of different types (via coercion):
var number = 6;
var bool = true;
var result = number + bool; //result is 7
Coming from a mostly statically-typed, strongly-typed background, I am having a hard time reasoning about the benefits of this type of approach. Sure, it can make for some pretty concise syntax, but it also seems like it could cause a nightmare when trying to track down bugs. So, besides conciseness, what are some of the benefits of loose typing and implicit type conversions?
Loosely typed languages have a number of differences which can be taken as advantages:
There is no need of interfaces. As long as an object has the method name that you need, call that method. Not using interfaces can simplify coding and reduce code size.
There is no need of generics, for very similar reasons.
"by type" function overloads are handled more simply If a function needs a string parameter, then just cast the incoming value to a string. If type checking is needed, it can be added there.
We don't have, or need, classes. The [almost] everything is an object makes passing values around much easier. No need to auto-box, no need to cast values coming out.
Objects are easily extended without breaking code. You can create an array then drop replace the indexOf method to use one uses the binary search. The end result is smaller, and IMHO, cleaner code.