Python/Wx dot net

[HankC]

Hello:

Sorry if I'm asking obvious questions but I'm still a little on the
fringe of the python scene...

I'm slowly migrating from Delphi/Kylix to Python/Wx to facilitate
cross-platform development. Python in particular is a really good fit
for the type of development I do. I'm also a little shakey on the
ramifications of dot net but it seems conceivable that at some point
any [former]Win32 apps will need to run as managed code. Looking a
little long term...

What's the status of python as a dot net language?

What's the status of Wx as a dot net gui toolkit?

What's the probability of something like BOA being able to target dot
net?

I'm sure there are some links somewhere but the stupidity of the name
(re: .net) is making my searches ineffective. Any links/comments in
general appreciated.

TIA!

 

[Lawrence Oluyede]

What's the status of python as a dot net language?

Python as a language for the CLR is not on the way.
There was a project by Mark Hammond but I think is quite
dead, but if you want to try is there:
http://starship.python.net/crew/mhammond/dotnet/

There is another project (Python bindings for .NET)
that you can find there:
http://www.zope.org/Members/Brian/PythonNet

 

[Peter Hansen]

I'm slowly migrating from Delphi/Kylix to Python/Wx to facilitate
cross-platform development. Python in particular is a really good fit
for the type of development I do. I'm also a little shakey on the
ramifications of dot net but it seems conceivable that at some point
any [former]Win32 apps will need to run as managed code. Looking a
little long term...

What's the status of python as a dot net language?

What's the status of Wx as a dot net gui toolkit?

What's the probability of something like BOA being able to target dot
net?

Here's the question I would ask: what's the future of dot net?

Python has outlasted at least two major new Microsoft initiatives,
I believe, and seems likely to outlive .NET as well.

I hvae more faith in the Python community to provide useful,
cross-platform, robust, and fun environments than I do in Microsoft
to do provide any single one of those.

My suggestion: learn to use Python well. Use it to solve problems.
If at some point it supports .NET, you'll be well positioned to
write to that API, but you'll also still be able to write good
programs long after .NET is yet another footnote in history.

-Peter

 

[Mike C. Fletcher]

Peter Hansen wrote:
....

Here's the question I would ask: what's the future of dot net?

Shane's web-site might be a decent link here to get the view of a small
software development company who'd considered moving to .NET and decided
to skip it:

http://www.skippingdot.net/

Of course, there's a bias there (as everywhere). Still, .NET does
appear to be falling by the wayside as a marketing strategy, and
marketing is 90% of the .NET story.

There are lots of things that can be salvaged from the train-wreck
(there were lots of good ideas; introspectable bundles, standards for
cross-language module interface definitions, built-in networking
libraries), but jumping on the train just before it hits the stantion to
try to pull them out seems less than useful.

Spending precious resources binding wx to .NET, or Python, for that
matter, seems rather a waste. Sure, if there's a particular problem you
run into where you need it, devote the time, but without that, it
doesn't seem a particularly good engine to pull the Python train.

$0.02CDN,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

 

[HankC]

Here's the question I would ask: what's the future of dot net?

Well, this is the question, isn't it. IMO, I think programming in
XXX.NET will be the *norm* (for Windows programming) within 1-2 years.
Look at the development tools MS is putting out. Look at the focus of
Borland now. When a 64bit version of Windows is available it will be
even more popular.

I think it's conceivable that MS will disallow native code at some
point. When, I don't know but I'd guess in 3-5 years.

Python has outlasted at least two major new Microsoft initiatives,
I believe, and seems likely to outlive .NET as well.

I agree.

I hvae more faith in the Python community to provide useful,
cross-platform, robust, and fun environments than I do in Microsoft
to do provide any single one of those.

I agree.

My suggestion: learn to use Python well. Use it to solve problems.
If at some point it supports .NET, you'll be well positioned to
write to that API, but you'll also still be able to write good
programs long after .NET is yet another footnote in history.

My feeling is that if Python doesn't support .net, and if non-.net
apps won't run under windows at some point, I'll be looking for
another language. If a Python/Wx solution will work indefinately I'd
be a lot happier.

Thanks for your comments!

 

[HankC]

Of course, there's a bias there (as everywhere). Still, .NET does
appear to be falling by the wayside as a marketing strategy, and
marketing is 90% of the .NET story.

I remember the .net hype of 1-2 years ago and agree that that
marketing strategy was a flop. Things are entirely different now,
.net is certainly gaining mindshare for a lot of developers.

 

[HankC]

http://starship.python.net/crew/mhammond/dotnet/

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

Thanks!

 

[JanC]

(e-mail address removed) (HankC) schreef:

I think it's conceivable that MS will disallow native code at some
point. When, I don't know but I'd guess in 3-5 years.

They can't. Other operating systems (e.g. Linux & MacOSX) would run
circles around Windows when playing the latest games and CPU-intensive
applications (like 3D-rendering) if they did...

 

[HankC]

(e-mail address removed) (HankC) schreef:


They can't. Other operating systems (e.g. Linux & MacOSX) would run
circles around Windows when playing the latest games and CPU-intensive
applications (like 3D-rendering) if they did...

From what I hear, the JIT compile causes a little delay when
initiating an app but the actual execution speed is really good. The
exception is GDI but within 3-5 years, if not a lot sooner, they will
have this fixed.

Furthermore, MS has the capability of just telling people/developers
what needs to be done. Assuming they get the crappy GDI portion of
net working fairly well, and they prohibit native execution (with I
suspect rare exceptions) do you really think game developers are
suddenly going to abandon Windows for Linux?

 

[Carl Waldbieser]

To me, it seems like it would be a very extreme position for Microsoft to
disallow native code on their future operating systems. I find myself
asking, "what would be the point?" If someone wanted to write a program
that they couldn't write using managed code, they couldn't use Windows. Why
would you want to shut out a potential customer? Also, not all the tools
Microsoft is putting out focus entirely on managed code. The Visual C++
tools seem (at least to me) to have been designed with an emphasis on
integrating native and managed code for mixed projects.

I am not worried if there is not a version of python that runs under .NET,
as long as there is some version of Python I can use on Windows. It seems
to me that when a need exists for different tools to communicate with each
other, someone usually comes up with a way so they can. Mark Hammond's
excellent COM extensions for Python didn't attempt to re-write Python as a
complete set of COM components-- instead, it provided a simple way for
Python to interact with COM components and visa versa.

Techniques already exist for Python and .NET apps to talk to each other.
I'm sure as the technology matures, better and simpler techniques will
emerge.

Carl Waldbieser

 

[HankC]

To me, it seems like it would be a very extreme position for Microsoft to
disallow native code on their future operating systems. I find myself
asking, "what would be the point?" If someone wanted to write a program
that they couldn't write using managed code, they couldn't use Windows. Why
would you want to shut out a potential customer? Also, not all the tools
Microsoft is putting out focus entirely on managed code. The Visual C++
tools seem (at least to me) to have been designed with an emphasis on
integrating native and managed code for mixed projects.

Carl, thanks for your comments - they're actually a little reassuring.
Not really to argue, but just to comment on the points above:

extreme position - yes indeed, but I can see it happening if it would
increase the control/power of MS.

the point? - Well, two quick ones: 1) controlling a framework that is
written to by a huge number of developers gives them a huge amount of
power; 2) if Windows runs managed code only the security of the
platform would increase substantially.

they couldn't use Windows - I think as .net matures there will be
very few apps that won't be capable of running as managed code.
Drivers and other low level stuff may be excepted with an MS
certification or something.

integration - Yeah, but it's still early, you would have to expect
integration at this point. I also understand that there will be no
thunking layer to run 32 bit native code from 64 bit managed code so
writing to Win64 will require either a 64bit compiler or managed code
exclusively.

I know some of those points are a little far fetched - I'm just
feeling a little bleak about the future lately

 

[John J. Lee]

they couldn't use Windows - I think as .net matures there will be
very few apps that won't be capable of running as managed code.
Drivers and other low level stuff may be excepted with an MS
certification or something.

[...]

Has anyone actually compiled (or tried to compile) CPython with a
..NOT C compiler?


John

 

[Carl Waldbieser]

they couldn't use Windows - I think as .net matures there will be
very few apps that won't be capable of running as managed code.
Drivers and other low level stuff may be excepted with an MS
certification or something.

Some of the moves Microsoft has made don't really seem to be following this
model. They have actually put a good deal of effort in making the latest
VC++ much more standard-compliant, and they have brought on board C++
luminaries like Herb Sutter, so it seems like they are paying more than
lip-service to the native-code side of their development tools.

In any event, I think that something important to realize here is that just
because it might not be a good idea to have Python implemented *as* a .NET
language, doesn't mean Python couldn't be implemented *with* a .NET
language. Right now, Python is written in C, and Jython in Java (I never
used Jython, so I'm not sure how different it is). If someone really wanted
to, it's not inconceivable that they could implement Python in C++, or LISP,
or ADA, or even in Python! Of course, it is inconceivable that someone
would ever try to write Python in Perl-- that would just be too much of a
mind bending experience for either Perl or Python affictionados (Just
kidding, someone has probably already done such a thing, or maybe Guido and
Larry can have a rae to see who can write the other's language in their own
first.) By the same token, Python *can* be written in a .NET language. I
don't know if anyone has yet, but it should definitely be possible.

..NET has at times been accused of "homegenizing" languages to make them fit
the .NET mold. A lot of Visual Basic programmers are pretty upset by the
fact that Visual Basic .NET is best described as, "...and now for something
completely different...". If you take a look at managed C++, you see that a
lot of the C++ness was also sacrificed to make it play well with others.
When I hear about things like COBOL.NET or Eiffel.NET or Smalltalk.NET, I
have often stopped to wonder, how the heck could that really be like the
original language? The .NET infrastructure does cover a wide array of
features from various programming languages, but not nearly every
interesting feature from every programming language that has had its time in
the sun.

In this respect, I think it's actually good that Python-as-a-.NET language
has slowed down (stopped?) so that maybe more energy will be expended on say
a C# implementation of Python? I am not especially worried if such an
implementation of Python is actually compiled down into IL and then native
code, just as long as it runs my Python scripts! C-Python doesn't compile
down to native code. Extensions for C-Python are already written in C and
pre-compiled to native code, but surely a hypothetical C#-Python could have
C# extensions that compile into IL and then native code for the performance
critical bits.

Some features of Python are just a lot more powerful or flexible than they
could be if Python had to conorm to the .NET infrastructure. For example,
Python's reflection and metaclass capabilities are a lot more flexible than
what you are able to do with a .NET object in any managed language, as far
as I know. Add a method to or property to a class at run-time? Can this be
done easily with .NET? Can it be done at all? I would dread seeing Python
sacrifice its Pythoness just for the sake of conformity.

I know some of those points are a little far fetched - I'm just
feeling a little bleak about the future lately

I wouldn't worry about it. It is generally a good thing to think critically
about the future. After all, nobody expects the Spanish Inquisition! But
seriously, it is good that you voice your concerns. One of the great things
about Python are all the helpful Pythonistas in the community who are only
too eager to lend a helping hand. That is why I have complete confidence
that if the time ever came when Python positively, absolutely had to work on
platform XYZ, that someone would take up the challange and make it happen.

Carl Waldbieser

 

[John J. Lee]

.NET has at times been accused of "homegenizing" languages to make them fit
the .NET mold. A lot of Visual Basic programmers are pretty upset by the
fact that Visual Basic .NET is best described as, "...and now for something
completely different...". If you take a look at managed C++, you see that a
lot of the C++ness was also sacrificed to make it play well with others.

[...]

Ah. I had assumed managed C++ was enough like C++ to make porting C
and C++ easy. Is that wrong? I guess the problem is memory
management? -- pretty fundamental to C.

When I hear about things like COBOL.NET or Eiffel.NET or Smalltalk.NET, I
have often stopped to wonder, how the heck could that really be like the
original language? The .NET infrastructure does cover a wide array of
features from various programming languages, but not nearly every
interesting feature from every programming language that has had its time in
the sun.

This is interesting. Do you have any references / links on this (I
mean specifically on this -- I don't want to read a pile of general
stuff about the CLR)?

In this respect, I think it's actually good that Python-as-a-.NET language
has slowed down (stopped?) so that maybe more energy will be expended on say
a C# implementation of Python? I am not especially worried if such an
implementation of Python is actually compiled down into IL and then native
code, just as long as it runs my Python scripts! C-Python doesn't compile
down to native code. Extensions for C-Python are already written in C and
pre-compiled to native code, but surely a hypothetical C#-Python could have
C# extensions that compile into IL and then native code for the performance
critical bits.

[...]

Presumably .NET still has links of some kind to native code (other
than through COM)? If so, is there any advantage ATM in having a C#
implementation?


John

 

[HankC]

Ah. I had assumed managed C++ was enough like C++ to make porting C
and C++ easy. Is that wrong? I guess the problem is memory
management? -- pretty fundamental to C.

My guess (being a borland customer) is that the answer is what your
compiler vendor gives you. Borland is releasing a product soon that
you will write Delphi (object pascal) code but the compiler will emit
..net programs. Unsupported data types, like pascal sets, will still
work through some sort of compiler magic.

I'd guess that MS/Borland/others will or have already released similar
products that would allow you to write c++ code and target .net.

 

[John J. Lee]

Managed C++ constrains you to what the framework allows, so currently, that
means no templates, no multiple inheritence (this one affects Python as a

[...]

So would CPython compile as a managed app, with a bit of work?

(yes, I realise that's not the same as having Python as a first-class
..NET citizen)

[...]

restrictions. I can recommend ".NET Architecture and Programming Using
Visual C++" by Peter Thorsteinson and Robert J. Oberg as a good book on the

[...]

Thanks, but no thanks!-) I only had just enough passing interest to
wonder if CPython could be compiled with Managed C++.

Err, I'm not exactly sure if you mean links about various .NETified
programming languages or something else. I think this link is where I first
read about Eiffel for .NET:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/pdc_eiffel.asp

I'm not interested in particular languages in themselves (it's easy
enough to find the .NET implementations). I was interested in any
discussion of the general issue of how well .NET supports unusual
language features (or even just slightly nonstandard ones).


John

 

[Carl Waldbieser]

Ah. I had assumed managed C++ was enough like C++ to make porting C
and C++ easy. Is that wrong? I guess the problem is memory
management? -- pretty fundamental to C.

Managed C++ constrains you to what the framework allows, so currently, that
means no templates, no multiple inheritence (this one affects Python as a
..NET language), no unmanaged heap. Also, no free functions-- everything is
modeled as a static memebr of a class (ala Java?). Garbage collection is
the norm, so you typically don't have to worry too much about your own
memory management. The scheme used is technically different than the
resource management used in C-Python, but similar to Jython in some
respects.
On the other hand, you can pretty easily compile unmanaged apps, and it is
pretty easy to get managed and unmanaged code to work together under various
restrictions. I can recommend ".NET Architecture and Programming Using
Visual C++" by Peter Thorsteinson and Robert J. Oberg as a good book on the
subject. Seeing how C++ interacts with the framework in cotrast to C# or
Visual Basic gives some decent insights into how the whole thing works (at
least for me it did). Or, you can jsut read the C++ .NET reference in the
mdn library (http://www.msdn.microsoft.com).

This is interesting. Do you have any references / links on this (I
mean specifically on this -- I don't want to read a pile of general
stuff about the CLR)?

Err, I'm not exactly sure if you mean links about various .NETified
programming languages or something else. I think this link is where I first
read about Eiffel for .NET:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/pdc_eiffel.asp

Carl Waldbieser

 

[Dennis Lee Bieber]

John J. Lee fed this fish to the penguins on Tuesday 07 October 2003
09:58 am:

Presumably .NET still has links of some kind to native code (other
than through COM)? If so, is there any advantage ATM in having a C#
implementation?

This is stale hearsay, but I thought I'd read once that only VC++, in
the .NET version of VS, still had a native code capability (probably
just for the creation of drivers, et al) -- but you had to set an
option for that, and as soon as you did, you /lost/ all access to the
..NET framework.

--

 

[Carl Waldbieser]

So would CPython compile as a managed app, with a bit of work?

(yes, I realise that's not the same as having Python as a first-class
.NET citizen)

I have not really one any significant C++.NET apps, nor have I looked at the
CPython source recently. I would think that it should be possible though.
The key part of you question I guess is what constitutes a "bit of work".
There are some things that I think would translate to managed code pretty
well, but other things that would not. I am probably not in the best
position to suggest how easy / hard something like that would be, though.

Carl Waldbieser

 

[Larry goodman]

This is stale hearsay, but I thought I'd read once that only VC++, in

the .NET version of VS, still had a native code capability (probably
just for the creation of drivers, et al) -- but you had to set an
option for that, and as soon as you did, you /lost/ all access to the
.NET framework.

Im pretty sure you can mix managed and unmanage code even in the same
unit in c++.net