Hello Mark and others,
thank you for the clarification. Very interesting, I hadn't though of
these two distinct use cases, i.e. :
-on the one hand embedding Python scripting in .NET applications
-on the other hand calling .NET assemblies from applications that
otherwise run outside of the .NET scope.
My background with .NET is more into monolytic business applications
that don't have embedded scripting. It might be worthwhile to upgrade
the "Python for .NET" website and clarify these different use cases.
Both technologies now seem to have a clear use case and rationale.
good evening.
Emmanuel
Quoting "Mark Tigges" <[email protected]>:
On Mon, Jan 10, 2011 at 4:18 AM, Emmanuel Lambert
<[email protected]> wrote:
Hi Oleksii Bidiuk,
While access to the native Python libraries is apprently a nice feature
of "Python for .NET", I don't think it is very useful in real-world .NET
centric projects (in a corporate environment for example).
An implementation like IronPython restricts itself to the use of
native .NET features and thus cannot cause dangerous side-effects that
inflict memory leak for example. With "Python for .NET", that is not the
case.
Therefore, in my opinion, IronPython looks like an implementation that
is potentially useful for real-world projects, while "Python for .NET"
looks more experimental in its nature...
Emmanuel
Emmanual,
You're very mistaken. In our "corporate environment" (a large game
studio), we use both. IronPython is used where we want to extend a
.net environment with python scripting capabilities. PythonDotNet is
used when we want to use our .net assemblies from another program
which has cpython embedded. PythonDotNet allows us to extend Maya &
MotionBuilder by leveraging all the .net code we write for our tools.
Your opinion is yours, but trust me, while PythonDotNet is a little
rough around the edges it is hugely beneficial to us and others.
We use a cpython distribution augmented with PythonDotNet as our
standard python for distribution to client machines. The only place
we use IronPython is embedded in our tools. The start up time for
IronPython (about .5 secs) the last time I checked pretty much makes
it useless.
Mark.
On Mon, 2011-01-10 at 09:55 +0100, Oleksii Bidiuk wrote:
Hi Emmanuel,
The basic differences are highlighted in several discussions like
http://stackoverflow.com/questions/1168914/ironpython-vs-python-net
In short IronPython is a complete managed implementation of Python
interpreter in .NET (developed parallel to the regular Python or
CPython), just like Jython. Python for .NET on the other hand is
a .NET wrapper around the CPython interpreter providing access to the
CPython from .NET application and back. There are differences in
implementation (e.g. no GIL in IronPython) and in the accessibility of
the libraries (no access to the C libraries from IronPython out of
box).
I am also interested in any hints to the roadmaps of the both
products. IronPython seem to be more mature, but it is also way more
effort than Python for .NET. So far I have difficulties to choose
strategically for either one as both are lagging behind the solid
community of CPython. Comments are more than welcome!
2011/1/10 Emmanuel Lambert <[email protected]>
Dear all,
I was wondering : what is the difference between PythonDotNet
and
IronPython? It looks like IronPython is rapidly becoming a
maturing
implementation for the .NET platform, with also a plugin for
Visual
Studio becoming available : http://ironpython.net/
The distinction between the two implementations, future
roadmaps, etc,
is not clear to me. Any comments are welcome...
regards
Emmanuel
_________________________________________________
Python.NET mailing list - [email protected]
http://mail.python.org/mailman/listinfo/pythondotnet
--
oleksii
_________________________________________________
Python.NET mailing list - [email protected]
http://mail.python.org/mailman/listinfo/pythondotnet
_________________________________________________
Python.NET mailing list - [email protected]
http://mail.python.org/mailman/listinfo/pythondotnet
