digitalmars.D - Python to D translator?
- Georg Wrede (7/7) Nov 15 2005 Any thoughts on this?
- clayasaurus (9/19) Nov 15 2005 I thought part of the usefulness of python was that it was interpreted
- pragma (22/29) Nov 15 2005 I am not a Python programmer, but I play one online. ;)
- Factory (9/19) Nov 15 2005 Yes, Python is a dynamically typed language, whereas D
- John S. Skogtvedt (4/14) Nov 16 2005 There is already a Python->C++ compiler.
- Manfred Nowak (12/13) Nov 16 2005 Isn't python classified as a glue language? If it is, then
- Walter Bright (7/14) Nov 17 2005 If a 100% Python to D translator could be built, then one could also bui...
- Munch (12/22) Nov 17 2005 What about the *other* contracts language, Eiffel? At present one of the...
- Manfred Nowak (6/8) Nov 18 2005 [...]
- Manfred Nowak (12/13) Nov 19 2005 ... but to no avail, because according to the coupling of those
- Georg Wrede (3/4) Nov 20 2005 ...
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
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
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
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
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?There is already a Python->C++ compiler. http://shed-skin.blogspot.com/ http://sourceforge.net/projects/shedskin/
Nov 16 2005
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
"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
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 MunchA 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
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
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
Manfred Nowak wrote:Manfred Nowak wrote:... Thanks, Manfred and guys!
Nov 20 2005