www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Python to D translator?

reply Georg Wrede <georg.wrede nospam.org> writes:
Any thoughts on this?

One might say that D has the productivity of Python, combined with C's 
to-the-metal programming and C++'s power.

A lot of the Python crowd are fed up with the inefficiency of 
non-trivial Python applications.

But is it feasible to try to create such a source code translator?
Any obvious gotchas?
Nov 15 2005
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Georg Wrede wrote:
 Any thoughts on this?
 
 One might say that D has the productivity of Python, combined with C's 
 to-the-metal programming and C++'s power.
 
 A lot of the Python crowd are fed up with the inefficiency of 
 non-trivial Python applications.
 
 But is it feasible to try to create such a source code translator?
 Any obvious gotchas?

I thought part of the usefulness of python was that it was interpreted and therefore isn't tied to any one system (same code works on any machine with interpreter) and it can be embedded in C/C++ as a scripting language. IMO I'd rather see C and C++ --> D translators, or a C++ --> C wrap --> D generator, but I'm not a python programmer. Goodluck. ~ Clay
Nov 15 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <437A894D.4070402 nospam.org>, Georg Wrede says...
Any thoughts on this?

One might say that D has the productivity of Python, combined with C's 
to-the-metal programming and C++'s power.

A lot of the Python crowd are fed up with the inefficiency of 
non-trivial Python applications.

But is it feasible to try to create such a source code translator?
Any obvious gotchas?

I am not a Python programmer, but I play one online. ;) I apologize in advance if these 'gotchas' are at all obvious. Offhand, I'd say that there are some things that Python does that won't translate into D very cleanly. Co-routines come to mind as being a problem: you'd need a shim or two in order to support those, and the resulting code wouldn't be anywhere near as clean. Also, Python is *rediculously* introspective, which is something that even in its more modest forms is way outside of what D does. D also doesn't have the runtime linking/binding support that Python has, but I'm doing what I can to fix that part (DDL). Python's treatment of variables as variants also stands out in my mind as a problem. One would hope that std.boxer is up to task for this, otherwise it means more shims for the effort. So you can most certainly translate Python programs into D, but your output is going to have a tendency toward unmaintainable code (read: inscrutable and machine generated). I guess that is fine if all your looking for is a path for direct-compilation of Python. FYI, in trying to search around for simliar projects, all I could find was Jython, which is very close to what you propose. I could not find one single gcc front-end, which is just... wierd. I think you're on to something here. :) http://www.jython.org/docs/whatis.html - EricAnderton at yahoo
Nov 15 2005
prev sibling next sibling parent Factory <t t.com> writes:
In article <437A894D.4070402 nospam.org>, 
georg.wrede nospam.org says...
 Any thoughts on this?
 
 One might say that D has the productivity of Python, combined with C's 
 to-the-metal programming and C++'s power.
 
 A lot of the Python crowd are fed up with the inefficiency of 
 non-trivial Python applications.
 
 But is it feasible to try to create such a source code translator?
 Any obvious gotchas?

Yes, Python is a dynamically typed language, whereas D is statically typed, this is one of the main features of both lanugages. Trying to make D dynamically typed will just make it have most of the performance inefficiencies of Python. - Factory
Nov 15 2005
prev sibling next sibling parent "John S. Skogtvedt" <jss2k2 chello.no> writes:
Georg Wrede skrev:
 Any thoughts on this?
 
 One might say that D has the productivity of Python, combined with C's 
 to-the-metal programming and C++'s power.
 
 A lot of the Python crowd are fed up with the inefficiency of 
 non-trivial Python applications.
 
 But is it feasible to try to create such a source code translator?
 Any obvious gotchas?

http://shed-skin.blogspot.com/ http://sourceforge.net/projects/shedskin/
Nov 16 2005
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Georg Wrede wrote:

[...]
 Any obvious gotchas?

Isn't python classified as a glue language? If it is, then 1) you have to fight your position with arguments, that convince everyone of the wrongness of this approach, or 2) you have to state, that you are designing a rescue implementation of Python for badly managed projects, or 3) you find a way to show, that it is possible to find an automatic or a semiautomatic tradeoff between interpretation and compiling in general and especially for python. Therefore a Dython project does not look very promising to me. -manfred
Nov 16 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:437A894D.4070402 nospam.org...
 Any thoughts on this?

 One might say that D has the productivity of Python, combined with C's
 to-the-metal programming and C++'s power.

 A lot of the Python crowd are fed up with the inefficiency of
 non-trivial Python applications.

 But is it feasible to try to create such a source code translator?
 Any obvious gotchas?

If a 100% Python to D translator could be built, then one could also build a Python compiler that generates native code. But nobody has built the latter, so I suspect there's a fundamental problem doing it. That said, if one could live with a less than 100% perfect translation, it might be very doable.
Nov 17 2005
next sibling parent Munch <Munch_member pathlink.com> writes:
 A lot of the Python crowd are fed up with the inefficiency of
 non-trivial Python applications.

 But is it feasible to try to create such a source code translator?
 Any obvious gotchas?

If a 100% Python to D translator could be built, then one could also build a Python compiler that generates native code. But nobody has built the latter, so I suspect there's a fundamental problem doing it. That said, if one could live with a less than 100% perfect translation, it might be very doable.

What about the *other* contracts language, Eiffel? At present one of the main implementations (http://www.eiffel.com/) currently compiles down to C. This is mainly for speed and deployability, but also to allow interfacing with C. However I can't help thinking that they lose a lot of the flavour of the original language in using C. If they compiled down to D they could represent the contracts and *some* of the structure of the type system (Eiffel has a very nice type system "proper OO" if you like) directly in D, whilst still maintaining deployability, speed, and ability to interface with C. I guess it's them I should be putting this idea to though, rather than you! It seems like an obvious partnership though. Cheers Munch
Nov 17 2005
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

[...]
 But nobody has built the latter, so I suspect there's a
 fundamental problem doing it. 

That got me rethinking number three of my earlier remark with the result that a Dython project might be doable. -manfred
Nov 18 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Manfred Nowak wrote:

[...]
 a Dython project might be doable.

... but to no avail, because according to the coupling of those pieces of python scripts, that must be compiled to native code in order to perform faster, are 1) not coupled at all or they 2) are coupled to the rest of the system. In case 1) a glue language fulfills the goal. In case 2) the coupled parts must be recompiled, which may lead to the recompilation of the whole system, raising all the pitfalls of untyped dynamic interpreted languages. -manfred
Nov 19 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Manfred Nowak wrote:
 Manfred Nowak wrote:

Thanks, Manfred and guys!
Nov 20 2005