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]

On Feb 2, 2:09 pm, Michal Hantl <michal.ha...@gmail.com> wrote:
>  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]

On Thu, Feb 2, 2012 at 11:30 AM, Paul Moore <p.f....@gmail.com> wrote:
> 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

[Michal Hantl]

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

[andrea crotti]

2012/2/2 Amirouche Boubekki <amirouche...@gmail.com>:
> 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]

On Thu, Feb 2, 2012 at 3:53 PM, andrea crotti <andrea....@gmail.com> wrote:
> 2012/2/2 Amirouche Boubekki <amirouche...@gmail.com>:
>> 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).

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]

On Fri, Feb 3, 2012 at 9:53 AM, andrea crotti <andrea....@gmail.com> wrote:
> 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]

On 3.2.2012 02:19, Ian Kelly wrote:
>> 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.

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.des...@gmail.com]

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

[Nathan Rice]

>> 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.

You can generalize the dictionary based dispatch used for "case"
statements to do this. The main downsides are:

1.) You have to define your functions ahead of time or use lambdas
2.) The syntax is not quite as nice as it could be (e.g.)

foo = DispatchDict({
Pattern1: f1,
Pattern2: f2,
etc...
})

Reminds me more of javascript than I would like.

>> 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.

I think maintaining the output can be valuable. There are going to be
things that can be expressed in the more verbose expanded form that
will not be easily expressible in the terse pre-translated macro.
Unfortunately, most macro writers don't put much time into making sure
their macro produces concise code.

>> And proving that your translator is always correct
>

> That's what unit tests are for.

I have a love hate affair with unit tests. You need them, but I'd
really rather analytically prove that my software is correct under
some set of assumptions.


Cheers,

Nathan

[andrea crotti]

2012/2/3 Dennis Lee Bieber <wlf...@ix.netcom.com>:
> On Thu, 2 Feb 2012 18:19:22 -0700, Ian Kelly <ian.g...@gmail.com>
>        <hah!>
>
>        I spent nearly 20 years having to maintain the /output/ of such 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]

On Feb 3, 8:42 pm, Matej Cepl <mc...@redhat.com> wrote:
> 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.