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]

ha***@nospam.com (HankC) writes:

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

--
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
rh****@NOSPAMmyself.com

[Peter Hansen]

HankC wrote:

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]

On Sun, 05 Oct 2003 09:39:02 -0400, Peter Hansen <pe***@engcorp.com>
wrote:

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!
-Peter

[HankC]

On Sun, 05 Oct 2003 11:23:31 -0400, "Mike C. Fletcher"
<mc******@rogers.com> wrote:

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]

On Sun, 05 Oct 2003 11:08:06 +0200, Lawrence Oluyede <ra***@dot.com>
wrote:

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

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

Thanks!

[JanC]

ha***@nospam.com (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...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[HankC]

On Mon, 06 Oct 2003 02:10:05 GMT, JanC <us*********@janc.invalid>
wrote:

ha***@nospam.com (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...

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]

On Mon, 6 Oct 2003 00:45:17 -0700, "Carl Waldbieser"
<wa*****@attglobal.net> wrote:

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 :-)

[HankC]

On 07 Oct 2003 17:58:09 +0100, jj*@pobox.com (John J. Lee) wrote:

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.

[Carl Waldbieser]

"John J. Lee" <jj*@pobox.com> wrote in message
news:87************@pobox.com...

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).

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)?

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/de...us/dndotnet/ht
ml/pdc_eiffel.asp

Carl Waldbieser

[John J. Lee]

"Carl Waldbieser" <wa*****@attglobal.net> writes:

"John J. Lee" <jj*@pobox.com> wrote in message
news:87************@pobox.com...

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

[...]

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++.

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)?

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/de...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]

"John J. Lee" <jj*@pobox.com> wrote in message
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


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).

[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.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <

[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

[Tim Roberts]

Larry goodman <la***********@yahoo.com> wrote:

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

No, not easily, depending on how you define "unit". The original poster is
correct. Remember that Managed C++ emits MSIL, not x86 assembler, and
requires the Common Language Runtime to even get started.

An MC++ program can certainly call into unmanaged C++ DLLs, but you can't
link to unmanaged C++ object files.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.