Why Python won't work on .net

[Allenabethea]

Jython is 100% java coded python.
Python objects work with javacompilers and Virtual machines.

I am a hobby programmer so the technical reasons are probably beyond me...
Why is python incompatible with .net? Why can't python be coded in C#?

I see the the MONO project on linux/unix is advancing. .Net seems to be a
juggernaut especially if programmers will be able to use their favorite(most
productive) language to program in. (every language but python)

I am a new python tinkerer. I love the language. But what is its future but as
a legacy tool?

allen

[Martin v. Löwis]

Re: Why Python won't work on .net

allenabethea@ao l.com (Allenabethea) writes:
[color=blue]
> Why is python incompatible with .net? Why can't python be coded in
> C#?[/color]

Who says that it cannot be coded in C#. It is a matter of fact that it
currently isn't, but it would be possible to reimplement the Python
interpreter in C# (instead of implementing it in C).

As for generating MSIL byte codes: This is also possible, and has been
demonstrated. It also has been demonstrated that an initial
implementation is likely to be *very* slow.

The question is whether a Python implementation for .NET would be CLS
compliant (CLS == Common Language Specification). The existing
implementation has shown that this is not possible without giving up
parts of the Python semantics.

[color=blue]
> I am a new python tinkerer. I love the language. But what is its
> future but as a legacy tool?[/color]

No. Instead, most .NET users will find out that .NET is *not* a
juggernaut, but restricted to C#, in practice. So Python might even
survive .NET :-)

That said: If you think the Python-.NET story should be a better one,
feel free to contribute. Python is a volunteer effort, and without
volunteers, there will be no progress. Before starting, please have a
look at the excellent Python-for-.NET, which uses the native-code
Python implementation to host .NET, giving Python programs full access
to the framework.

Regards,
Martin

[Gustavo Campanelli]

Re: Why Python won't work on .net

Allenabethea wrote:[color=blue]
> I am a new python tinkerer. I love the language. But what is its[/color]
future but as[color=blue]
> a legacy tool?
>
> allen[/color]

As far as I've learned so far, .net is good for client server but not
that great for standalone because of the need for the .net runtime to
run things, which creates a large overhead. Performance is an issue too,
as everything compiles JIT. I think that's why although .net is a great
idea, a lot of languages will remain language of choice for
standalone/no runtimes/speed critical/cross platform aplications. I
could be wrong, but I don't think I'm far from the truth.

Gustavo Campanelli

[Ville Vainio]

Re: Why Python won't work on .net

allenabethea@ao l.com (Allenabethea) writes:

[color=blue]
> I am a new python tinkerer. I love the language. But what is its
> future but as a legacy tool?[/color]

What, has .NET suddenly turned out to be popular while I wasn't
watching? The whole world is hardly jumping on the .NET platform,
actually mostly people seem to be ignoring it...

Or is this a troll of some kind?

You might also want to take a look at:

http://zope.org/Members/Brian/PythonNet/

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Cameron Laird]

Re: Why Python won't work on .net

In article <m3isksttf8.fsf @mira.informati k.hu-berlin.de>,
Martin v. Löwis <martin@v.loewi s.de> wrote:

[Martin v. Löwis]

Re: Why Python won't work on .net

Ville Vainio wrote:
[color=blue]
> What, has .NET suddenly turned out to be popular while I wasn't
> watching?[/color]

Where I work, .NET is pretty popular. People are fascinated of
introspection/reflection, (relative) platform-independence,
ubiquitous serialization, powerful development tools, and the
back-up of a large company.

Of course, they all use C#, and consider the other .NET languages
toys.

Regards,
Martin

[Duncan Booth]

Re: Why Python won't work on .net

martin@v.loewis .de (Martin v. =?iso-8859-15?q?L=F6wis?=) wrote in
news:m3isksttf8 .fsf@mira.infor matik.hu-berlin.de:
[color=blue]
> As for generating MSIL byte codes: This is also possible, and has been
> demonstrated. It also has been demonstrated that an initial
> implementation is likely to be *very* slow.
>
> The question is whether a Python implementation for .NET would be CLS
> compliant (CLS == Common Language Specification). The existing
> implementation has shown that this is not possible without giving up
> parts of the Python semantics.
>[/color]
The main problem is that functions are first class objects in Python, but
not in the CLS. The CLS uses delegates to refer to functions, and a
delegate encapsulates both an object and a pointer to a method.

The CLS does have pointers to methods, but the situations in which they can
be used are limited by the code validator: there are two MSIL code
sequences which may be used to construct delegates, one for static
methods, one for non-static, both involve pushing a function pointer onto
the stack and then calling the delegate constructor, but in neither case
can the function pointer come from a variable.

To model Python within the environment, you can use a delegate to refer to
a static function (the object reference is null in this case), or to refer
to a bound method, but you cannot easily create a delegate to refer to an
unbound method. This makes any Python code using classes extremely hard to
model.

The original attempt at porting Python to this environment used the
reflection classes to get around this. Using reflection you can get objects
which indirectly reference classes and their methods, you can then create a
delegate from a System.Reflecti on.MethodInfo object at the point where the
unbound method becomes a bound method. Unfortunately, creating a delegate
from a MethodInfo is a couple of hundred times slower than creating a
delegate from a pointer to a method.

It is even possible to get a pointer to a method and then create a delegate
from it entirely within the constraints applied by the code validator, but
again this uses the Reflection classes and is at least as slow as using the
MethodInfo object.

I have been playing around with a variant on the managed Python compiler,
and I think I have figured a way to implement Python which might just get
around this bottleneck. Unfortunately it requires a lot of refactoring from
the original model, and I'm only working on it occasionally in my spare
time. Basically the idea is to compile static wrapper functions for every
method (at runtime). Obviously this is slow, but at least you only take the
hit once per class. Every unbound method, or bound method can keep a
delegate to the static wrapper, and we lose the overhead of the reflection
classes. Wrapper functions can also wrap constructors.

So far most of my refactoring has been concentrating on replacing the
original runtime with one based on a class hierarchy and modelling some of
the more recent Python behaviour. This simplifies and also speeds up the
code somewhat, although I think I have just about reached the limits I can
achieve before I do the function wrappers.

--
Duncan Booth duncan@rcp.co.u k
int month(char *p){return(1248 64/((p[0]+p[1]-p[2]&0x1f)+1)%12 )["\5\x8\3"
"\6\7\xb\1\x9\x a\2\0\4"];} // Who said my code was obscure?

[Michael Hudson]

Re: Why Python won't work on .net

"Martin v. Löwis" <martin@v.loewi s.de> writes:
[color=blue]
> Ville Vainio wrote:
>[color=green]
> > What, has .NET suddenly turned out to be popular while I wasn't
> > watching?[/color]
>
> Where I work, .NET is pretty popular. People are fascinated of
> introspection/reflection, (relative) platform-independence,
> ubiquitous serialization, powerful development tools,[/color]

....
[color=blue]
> and the back-up of a large company.[/color]

Oh :-)

More sponsorship for the PSF, please!

Cheers,
mwh

--
I have a feeling that any simple problem can be made arbitrarily
difficult by imposing a suitably heavy administrative process
around the development. -- Joe Armstrong, comp.lang.funct ional

[Terry Reedy]

Re: Why Python won't work on .net


"Duncan Booth" <duncan@NOSPAMr cp.co.uk> wrote in message
news:Xns944B682 EF5078duncanrcp couk@127.0.0.1. ..[color=blue][color=green]
> > The question is whether a Python implementation for .NET would be CLS
> > compliant (CLS == Common Language Specification). The existing
> > implementation has shown that this is not possible without giving up
> > parts of the Python semantics.
> >[/color]
> The main problem is that functions are first class objects in Python, but
> not in the CLS.[/color]

Thank you for this and the persuant explanation. I had been wondering
whether a .NET subset would be sensible. Hah! The design principle of
'everything, including funtions, is a (first-class) object' is part of the
beauty and ease-of-use of Python. Demotion of functions would point toward
'calculator Python'.
[color=blue]
> The CLS uses delegates to refer to functions, and a
> delegate encapsulates both an object and a pointer to a method.[/color]
....[color=blue]
> I have been playing around with a variant on the managed Python compiler,
> and I think I have figured a way to implement Python which might just get
> around this bottleneck.[/color]

Good luck. Not directly useful to me, but success can only promote the
usage of Python.

Terry J. Reedy

[Martin v. Löwis]

Re: Why Python won't work on .net

Duncan Booth <duncan@NOSPAMr cp.co.uk> writes:
[color=blue][color=green]
> > The question is whether a Python implementation for .NET would be CLS
> > compliant (CLS == Common Language Specification). The existing
> > implementation has shown that this is not possible without giving up
> > parts of the Python semantics.
> >[/color]
> The main problem is that functions are first class objects in Python, but
> not in the CLS. The CLS uses delegates to refer to functions, and a
> delegate encapsulates both an object and a pointer to a method.[/color]

In addition, I think one problem is that in CLS, a class has a
pre-determined set of data attributes, whereas in Python, instances
grow new data attributes as they live.
[color=blue]
> I have been playing around with a variant on the managed Python compiler,
> and I think I have figured a way to implement Python which might just get
> around this bottleneck. Unfortunately it requires a lot of refactoring from
> the original model, and I'm only working on it occasionally in my spare
> time.[/color]

Very interesting. Are you willing to share the intermediate results
that you get? Publish early, publish often :-)

Regards,
Martin

[Cameron Laird]

Re: Why Python won't work on .net

In article <4redncaHtOe2LE miRVn-ig@comcast.com> ,
Terry Reedy <tjreedy@udel.e du> wrote:

[Y2KYZFR1]

Re: Why Python won't work on .net

"Martin v. Löwis" <martin@v.loewi s.de> wrote in message news:<br16eq$8v b$00$1@news.t-online.com>...[color=blue]
> Ville Vainio wrote:
>[color=green]
> > What, has .NET suddenly turned out to be popular while I wasn't
> > watching?[/color]
>
> Where I work, .NET is pretty popular. People are fascinated of
> introspection/reflection, (relative) platform-independence,
> ubiquitous serialization, powerful development tools, and the
> back-up of a large company.
>
> Of course, they all use C#, and consider the other .NET languages
> toys.
>
> Regards,
> Martin[/color]


only if you mean Windows 95, 98, ME, 2000, XP as "platform
independant"

..Net is and for all PRACTICAL PURPOSED be a WINDOWS ONLY development /
runtime environment.

[Martin v. Löwis]

Re: Why Python won't work on .net

jarrodhroberson @yahoo.com (Y2KYZFR1) writes:
[color=blue]
> only if you mean Windows 95, 98, ME, 2000, XP as "platform
> independant"[/color]

People enjoy running .NET applications on OS X, through Rotor.

Regards,
Martin

[Courageous]

Re: Why Python won't work on .net

[color=blue]
>Why is python incompatible with .net? Why can't python be coded in C#?[/color]

It's not. The .net virtual machine is Turing Complete.

C//

[Courageous]

Re: Why Python won't work on .net

[color=blue][color=green]
>> The main problem is that functions are first class objects in Python, but
>> not in the CLS.[/color][/color]

Functions are only addresses in C, the (main) language Python is
implemented in.

C//