SnakeScript? (CoffeeScript for Python)

[Michal Hantl]

Hello,
I've been looking for something similar to CoffeeScript, but for python.

Does anyone know of such project?


So far I haven't found any attempt to do this, so I took few regular expressions and hacked this:
https://plus.google.com/116702779841286800811/posts/56sBdwiZ4fT

Any advice on what parses to use for the CoffeeScript-like syntaxe? I would like to use parser written in Python so I don't introduce dependencies.

Any advice from Python gurus / language experimentators?

 

[Paul Moore]

 I've been looking for something similar to CoffeeScript, but for python.

Does anyone know of such project?

Isn't CoffeeScript just a compiler to convert a cleaner syntax into
Javascript? If so, why would you need such a thing for Python, where
the syntax is already clean and simple?

Paul.

 

[Devin Jeanpierre]

Isn't CoffeeScript just a compiler to convert a cleaner syntax into
Javascript? If so, why would you need such a thing for Python, where
the syntax is already clean and simple?

Coffeescript is a more functional syntax. On that note, Python isn't
as functional as it could be.

e.g. the "Python Coffeescript" could add pattern matching or TCO or something.

-- Devin

 

[andrea crotti]

They are solution to write Python code that translates to javascript see
this thread
http://mail.python.org/pipermail/python-list/2011-November/1283110.html

Mm I don't think it's what the OP is asking (unless I misunderstood...).
I think he wants to compile some syntax TO Python.
But I don't really see why you would something like this (if not for fun).

Then how are you going to maintain the code? Maintain the compiled
code or the source? And proving that your translator is always correct
I think it's quite a hard task too...

 

[Ian Kelly]

Mm I don't think it's what the OP is asking (unless I misunderstood...).
I think he wants to compile some syntax TO Python.
But I don't really see why you would something like this (if not for fun).

Maybe because you think that Python syntax could be improved upon --
for instance, Python with pattern-matching would be freaking awesome
-- but at the same time you want to leverage Python's extensive
ecosystem of libraries. So instead of creating your own brand-new
language with no third party libraries whatsoever, you create one that
just compiles down to regular Python.

Then how are you going to maintain the code? Maintain the compiled
code or the source?

As with all compiled software, you maintain the input, not the output.

And proving that your translator is always correct

That's what unit tests are for.

Cheers,
Ian

 

[Chris Angelico]

Mm I don't think it's what the OP is asking (unless I misunderstood...).
I think he wants to compile some syntax TO Python.
But I don't really see why you would something like this (if not for fun).

Then how are you going to maintain the code? Maintain the compiled
code or the source? And proving that your translator is always correct
I think it's quite a hard task too...

There's two similar concepts here.

1) Skeleton codegens. You do up some kind of template, run it through
a program, and get a ready-to-fill-in code structure. In this case,
you don't care so much about the translator's quality (if there's
bugs/limitations, you fix 'em after codegenning), and will maintain
the compiled code.

2) Compilation to Python. You write your program in some other
language, run it through a program, and get executable code out of it.
You want the translator to be perfect (so that you don't have to edit
the resulting code), and will maintain the original source.

I think the OP is looking for #2. I've used that sort of technique a
number of times (not with Python specifically, but with other
languages that lack certain handy features); usually the source is
trivially translateable into the output, with 99% of syntax identical
(for instance, one oft-wanted feature is a C-like #include - I've
written .php.m4 files that get processed through M4 to become PHP
files).

ChrisA

 

[Matej Cepl]

As with all compiled software, you maintain the input, not the output.

I don't think that's what was the question. CoffeeScript is a hopeless
hack in the hopeless situation of Javascript world where no language
development is available (meaning, time between filing a bug to the
moment the change is useful in The Real Worldâ„¢ is many many years).

Ask anybody developing in CoffeeScript/Vala how much they love debugging
when they have to go through different styles of errors, bugs in the
intermediate processes, etc. In the end all these languages IMHO either
develop a new frontend for gcc/clang/PyPy (or fork of CPython) or die,
because the former is not that much more difficult than writing your
preprocessor, I believe.

Best,

Matěj

 

[bruno.desthuilliers]

See the link I attached.
Ruby-like blocks would be nice too.
Implicit returns.
Better strings like """My name is #{name}""".

Uhu... Looks like you want Ruby, not Python <g>

 

[Dennis Lee Bieber]

As with all compiled software, you maintain the input, not the output.

<hah!>

I spent nearly 20 years having to maintain the /output/ of such a
translator.

The application had originated via a subcontractor who maintained
ownership of the translator, and my company only inherited the
translated output.

I had the joy of porting the application from PDP-11 to VAX-11. In
the early days, if any changes were needed to a program I tended to
rewrite the code entirely (the application was many small programs each
doing just one individual task on a common graphics display, and the
"controller" user interface which displayed pages of forms, wrote all
data to a binary file used to populate common blocks used by the
sub-programs). This was mostly to bring it down to manageable sizes --
the output used ASSIGNed GOTOs to implement subroutine calls (no
parameter passing, everything was global!) -- the only good thing was it
was easy to identify translator generated output as it was
right-justified on the lines:
ASSIGN 1001 TO I123
GOTO 2200
1001 CONTINUE

{subroutine call -- save return address, jump subroutine...}

After about 10 years of this, I was able to bloody CODE in that
style, rather than rewriting smaller programs into individual files.
Granted, as much as possible, IF NOT CONDITION GOTO statements were
changed into F77 styel IF CONDITION THEN ... ELSE... ENDIF; but the
local subroutine calls were left in place.

 

[andrea crotti]

On Thu, 2 Feb 2012 18:19:22 -0700, Ian Kelly <[email protected]>
       <hah!>

       I spent nearly 20 years having to maintain the /output/ ofsuch a
translator.

Yes I think that is the point, if the code you maintain and the code
which you have to debug differ because there is a translator in the
middle you're going to be in trouble before or later.

Moreover, unless you only work alone (which is very unlikely) I think
you should agree with everyone else in such a decision..
And if you really miss so much features that are not in Python at all,
why not just use another programming language which has them then?

 

[alex23]

Ask anybody developing in CoffeeScript/Vala how much they love debugging
when they have to go through different styles of errors, bugs in the
intermediate processes, etc.

I develop in CoffeeScript. I love debugging it because _it's just
javascript_.

CS doesn't replace JS in any way. It just provides some convenience to
cover a lot of the regular heavy lifting. If you're trying to write CS
without any understanding of JS at all, well, I can see how that might
be a problem, but that's hardly CoffeeScript's failing.