IronPython-0.6 is now available!

[Neuruss]

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

[John]

> > OK! I am unaware of any. Can you point me to some.

Well, the one I "crashed" into was when I (by mistake) had compiled
Microsoft's free ASP.Net container (Cassini) using version 1.0 of the
framework, while my ASP.Net application was compiled using version 1.1
of the framework. The result was that the container complained that it
could not find the superclass for my page, since the 1.0 version of
System.Web.HttpApplication is *not* the 1.1 version of
System.Web.HttpApplication. It doid not even try to use it.

In Java, I *might* later have received a runtime exception about a
missing method, if I actually used a method that was too "new".

(The solution to the Cassini problem was to manually write an
application .config XML file that told it to use the 1.1 framework.
This config file is also where you define any dependencies to
particular versions of libraries; by default an application will use
the newest available.)
That is more of a side effect of versioning features. Interesting case
anyway. I will keep that in mind.

Yes! Why do I have to list every jar file I use for the application in
the classpath? Why can't I just drop them in the same folder with the
app and expect the JVM to find them.

You can, if the jars are included in your "main jar"'s manifest's
Class-Path value, e.g.

Main-Class: some.Application
Class-Path: library.jar stuff.jar

Setting this up is, as in the case of .Net, a task for your IDE.

I had some facts wrong about .NET for that bit. I looked up after your
post and I know better now.
I've used JBuilder and JDeveloper almost exclusively; I never could
get my head around the "project-less" directory-focused and slow
NetBeans.
OK! JBuilder does not look intimidating. I never got excited about the
JDeveloper's layout of tools.
Because it hides the .Net complexities from the developer. Is that a
good thing?

Hiding complexities from newbies and intermediate users is not a bad
idea. The project files are XML anyway. MS is mostly good at catering
to the needs of that market. Most Java tools don't seem to do that.
The impression I often get is Java is developed primarily for the
enterprise.

They seemed to compile Quake 2 fine.

How much of it ended up as unmanaged code? An application that runs
outside of the managed container is not a .Net application.

I wasn't talking in just performance terms. I meant how the language
fit. But that's a good point. That would be interesting to know. Even
then, the prospect of being able to seemlessly add unmanaged code for
performance bottlenecks without the additional cognitive overhead of
integration API is nice.

[Valentino Volonghi aka Dialtone]

On Sat, 31 Jul 2004 13:37:35 +1000, Derek Thomson wrote:

So, why can't it just be basically:

object.echo("hello network")

... as it is in CORBA and (other) XML-RPC and SOAP toolkits I've used.
I don't think that calling:

object.echo("hello network")
instead of
object.callRemote('echo', 'hello network')

is making any difference at all... Actually the CORBA author is evalutaing
twisted for his next needs (IIRC). Add this to the fact that doing
callRemote() you are not moving any objects around, Perspective Broker
let's you copy objects from the remote side to the client side and then
you would be able to call

object.echo('hello network')

for instance.
I also have a problem with the insistence on the use of asynchronous
callbacks. In order to use the result of the RPC call later in the
main flow of my code, I have to somehow block in the main thread for
the the result to be returned from the server via the callback - this
is something that can be done for me, and is handled simply and
transparently in other RPC toolkits/mechanisms I've used.
Clearly you do not know deferreds. Twisted won't wait for your response
blocking the whole thread. It will just send the request and when the
response comes back it will call your code for you.
I'll try to characterize this with a simple example. How would I write
something like this, where I have three distributed objects:

i = an_object.get_value()
j = another_object.get_value()
k = yet_another_object.combine(i, j)

... and now finally use "k" in my code?
You will use it in a callback.

Obviously if you don't like callbacks you won't like twisted, but this
doesn't make RPC with twisted primitive. I would say that you simply don't
like the way you write code with twisted.
I could be missing something, but isn't that going to turn into a mess
of dependant callbacks in Twisted? Aren't I going to have to write a
whole lot of code that blocks until the results come back? I don't
mean this as a challenge or a judgement anything, I'd honestly like to
know - I would like to look further into Twisted but was pretty much
put off by this issue right from the start.

Code won't block. You should read how deferreds work (note: they are not
making your blocking code into non-blocking code, but they will be waiting
in the background for an answer to a request, without blocking everything).

BTW Twisted provides 2 different ways of making you blocking code
non-blocking.

You can use deferToThread, if you have a very long atomic operation (like
querying a remote database), or you can divide your very-big-function into
many different steps and call each other with
reactor.callLater(0, nextStep)
Which makes the call happen the next cicle in the reactor (so to allow the
reactor to handle some requests in the meantime).

Usually for third party modules with blocking logic the most used choice
is deferToThread. But I suggest you reading the documentation from
www.twistedmatrix.com which is a lot more helpful.

HTH

--
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: http://vvolonghi.blogspot.com
Home Page: http://xoomer.virgilio.it/dialtone/

[Ely Stob]

Ivan Voras <ivoras@__geri.cc.fer.hr> writes:

Elbert Lev wrote:

C# IS a good language and .NET is a very good environment. Recently I .... Important - Python realities (not exotic) map on C# perfectly.

My experience exactly - this is what I was fishing for. While I
wouldn't say 'perfectly', it is good, and certainly 'good enough'.

Interesting comment.

Anybody have recommendations (and warnings-off...) for books on C#, .NET,
and associated gubbins? (ASP.NET, ADO.NET, Windows Forms, ...)

I'm guessing that I'll need a good half-tonne of dead tree if I'm to get a
grasp of it <0.5 wink>. Figuring out *which* half-tonne might be even
more time-consuming than reading that dry mass, though...

Some books that caught my own eye - all comments much appreciated:
C# and .NET
===========

Jesse Liberty; Programming C#

Andrew Troelsen; C# and the .Net Platform

Anders Hejlsberg, Scott Wiltamuth, Peter Golde; The C# Programming Language

Box, Sells; Essential .NET

Stephen Teilhet, Jay Hilyar; C# Cookbook; (O'Reilly)

Peter Drayton, et al; C# in a Nutshell; (O'Reilly)

J Richter; Applied Microsoft .NET Framework Programming
Windows Forms
=============

Chris Sells; Windows Forms Programming in C#

Matthew MacDonald; User Interfaces with C SHARP: Windows Forms and Custom Controls
ASP.NET
=======

Jesse Liberty, Dan Hurwitz; Programming ASP.NET

Fritz Onion; Essential ASP.NET with Examples in C#

N. Kothari; Developing ASP.NET Server Controls and Components
ADO.NET
=======

D. Sceppa; Microsoft ADO .NET (Core Reference)
Misc
====

R. Jeffries; Extreme Programming Adventures in C#
I see Petzold is soldiering on, too :-/
ely

[Ely Stob]

"Martin v. Löwis" <ma****@v.loewis.de> wrote in message news:<41**************@v.loewis.de>...

I have worked a lot with C# and .NET lately, and found two things:
- the VM is very well designed. It does not really work for languages
other than C#, though (and, yes: I believe that it does not work
well for Python either, despite IronPython's existance (*))

^^^
Where is the referent of your asterisk?

I'm very much interested in why you insist that the CLR does not work
well for Python, in the face of an apparently solid existence proof,
in the form of IronPython, that that simply isn't the case.

I know you have a sound understanding of Python, and sometimes
understanding beats apparent empirical evidence...
Ely

[John J. Lee]

si************@yahoo.co.uk (simo) writes:

flacco <fl*******@spambadTwilight-systems.com> wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

Yeah, very pre-alpha from the few tests I did, but I'm very excited
about this, especially as it seems the Parrot guys have given up on
Python :-(

[...]

Hey, I just realised how many Python implementations there are now:

Useful:

CPython
Jython
Stackless
psyco

On their way:

IronPython
PyPy
parrot?
Starkiller?

Not such a short list.

Maybe standardisation committees are just round the corner. Oh joy.
and a few close descendants, of course:

Pyrex
Prothon
Boo
Vyper (defunct)
John

[Terry Reedy]

"Ely Stob" <el******@elvis.com> wrote in message
news:b8**************************@posting.google.c om...

I'm very much interested in why you insist that the CLR does not work
well for Python, in the face of an apparently solid existence proof,
in the form of IronPython, that that simply isn't the case.

Does IronPython currently run the whole test suite as well as CPython on
Windows? (Has anyone even tried?) I presume from the 0.6 designation that
it might not, in which case the existence proof would not yet be solid.

Has anyone independently verified J.H's timing claims?

Terry J. Reedy

[Martin v. Löwis]

Ely Stob wrote:

Where is the referent of your asterisk?
Oops. It slipped under the table. Here it is:

(*) A lot of languages which appear to be supported on .NET really
aren't, atleast not in their original form. Instead, a .NET version
of the language gets defined, which deviates in its semantics and
feature set from the original syntax. I would expect the same to be
the case for IronPython.
I'm very much interested in why you insist that the CLR does not work
well for Python, in the face of an apparently solid existence proof,
in the form of IronPython, that that simply isn't the case.

I know you have a sound understanding of Python, and sometimes
understanding beats apparent empirical evidence...

So far, I believe it is hard to tell, because IronPython is still
not complete. However, I firmly believe that you cannot make a
full Python implementation (i.e. with the language reference and
the portable standard libraries) on .NET which is also CLS
compliant. Maybe IronPython does not aim at being CLS compliant,
which might improve the chances that it is Python.

To see what I mean in other languages: Managed C++ is a language
different from C++, for example, the delete operator has a different
meaning in managed C++ than it has in standard C++. Likewise, J#
is a language different from Java. Essentially, I believe that
all these .NET languages are just different ways to write C#.

Regards,
Martin

[Michael Hudson]

"Edward Diener" <el******@earthlink.net> writes:

Tor Iver Wilhelmsen wrote:

Lawrence Oluyede <ra***@dot.com> writes:

Nesting classes is an unneeded complication, and AFAIK is not pure
MI. I think that the only "bare MI support" that Java does have are
MI of interfaces...

There is nothing pure about MI. But that's a religious dicussion.
Python handles it better than C++ at least.

Why do you say that ? In other words, what in Python's implementation of MI
is superior to C++'s implementation of MI ?

Cooperative super calls and the notion of an MRO are *vastly* superior
to the horrors of C++.

MI with classic classes in CPython kinda sucks in comparison.

Cheers,
mwh

--
"I lacked the courage to investigate the weaknesses of the wicked,
because I discovered they are the same as the weaknesses of the
saintly." -- The Name Of The Rose, Umberto Eco

[Shawn Wheatley]

The only one I would say I can't do without is "Pragmatic ADO.NET".
It is _the_ reference for any database stuff you want to do with .NET.
All the code is in C#. So once you have C# down, check this book
out.

Shawn

On 2 Aug 2004 15:24:58 -0700, Ely Stob <el******@elvis.com> wrote:

Ivan Voras <ivoras@__geri.cc.fer.hr> writes:

Elbert Lev wrote:

C# IS a good language and .NET is a very good environment. Recently I .... Important - Python realities (not exotic) map on C# perfectly.

My experience exactly - this is what I was fishing for. While I
wouldn't say 'perfectly', it is good, and certainly 'good enough'.

Interesting comment.

Anybody have recommendations (and warnings-off...) for books on C#, .NET,
and associated gubbins? (ASP.NET, ADO.NET, Windows Forms, ...)

I'm guessing that I'll need a good half-tonne of dead tree if I'm to get a
grasp of it <0.5 wink>. Figuring out *which* half-tonne might be even
more time-consuming than reading that dry mass, though...

Some books that caught my own eye - all comments much appreciated:

C# and .NET
===========

Jesse Liberty; Programming C#

Andrew Troelsen; C# and the .Net Platform

Anders Hejlsberg, Scott Wiltamuth, Peter Golde; The C# Programming Language

Box, Sells; Essential .NET

Stephen Teilhet, Jay Hilyar; C# Cookbook; (O'Reilly)

Peter Drayton, et al; C# in a Nutshell; (O'Reilly)

J Richter; Applied Microsoft .NET Framework Programming

Windows Forms
=============

Chris Sells; Windows Forms Programming in C#

Matthew MacDonald; User Interfaces with C SHARP: Windows Forms and Custom Controls

ASP.NET
=======

Jesse Liberty, Dan Hurwitz; Programming ASP.NET

Fritz Onion; Essential ASP.NET with Examples in C#

N. Kothari; Developing ASP.NET Server Controls and Components

ADO.NET
=======

D. Sceppa; Microsoft ADO .NET (Core Reference)

Misc
====

R. Jeffries; Extreme Programming Adventures in C#

I see Petzold is soldiering on, too :-/

ely
--
http://mail.python.org/mailman/listinfo/python-list

[Indrek Kruusa]

Elbert Lev wrote:

C# IS a good language and .NET is a very good environment. Recently I
had to write a little program. "one of a kind", "throw away". It took
2.5 hours to finish the proto. Worked fine, but would requere night to
run. Had to rewrite in... C++ or C#. Having the proto in Python, C#
program was written almost as fast as Python's one. The run finishhed
in 1 hour.

A little comparison of C#, perl and python here (Speed test in menu):

http://www.tuleriit.ee/progs/

rgds,
Indrek

[Peter Hansen]

Indrek Kruusa wrote:

A little comparison of C#, perl and python here (Speed test in menu):

http://www.tuleriit.ee/progs/

After a quick glance over it, I would say that is not Python!

Or rather, it's just the same C# code implemented in primitive
Python that doesn't try to take advantage of the libraries
that exist (except for time.strptime).

There is a "csv" module which should eliminate much of the
drudgery of parsing the csv files containing the data.
I suspect there are some other significant improvements
that could be made as well.

Language comparison is a hard thing: what happens when you
pick a test case that can be handled much more easily in
one language than in another? Do you pick a new test case,
or write inefficient code that no programmer experienced in that
language would actually write? I'm not sure of the answer...
but would probably be helpful to explain which choices you
have made, so as not to mislead readers who are unfamiliar
with one of the languages. (For example, I suspect the Perl
code could be much shorter as well, but I don't know much
Perl so I couldn't say. What I do see there would give me
no reason at all to consider Perl instead of C# or Python.)

-Peter

[Indrek Kruusa]

Peter Hansen wrote:

Indrek Kruusa wrote:

A little comparison of C#, perl and python here (Speed test in menu):

http://www.tuleriit.ee/progs/

<snip>

Do you pick a new test case, or write inefficient code that no
programmer experienced in that
language would actually write? I'm not sure of the answer...

This is just an attempt to provide something more fun and "real" than
just simple measuring of millions of iterations over a+=1 in different
languages. It includes simple string operations, date manipulating, some
calculating and I/O.
Those things are somehow comparable in the means of execution speed. To
compare fullblown solutions...I don't know...you can write thesis about
it but among other aspects you definitely need a fair and simple speed
test and then I suppose you will find my 2c quite usable :)

Indrek

[Jorgen Grahn]

On 30 Jul 2004 13:48:02 GMT, Duncan Booth <[e-mail]> wrote:
....

BTW, elsewhere in this thread someone said that C++ doesn't fit well into
.Net framework so it is worth mentioning that vs2005 also includes
completely revamped support for C++. Naturally this is incompatible with
their earlier attempt, but it really is much improved.

I suppose you mean "C++/CLI", which is a superset of ISO C++. Well, it adds
a completely new object model to the language, new keywords and everything
.... so the statement "C++ doesn't fit well into .Net framework" still
applies, IMHO.

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[AdSR]

Peter Hansen <pe***@engcorp.com> wrote in message news:<aZ********************@powergate.ca>...

<snip>
Language comparison is a hard thing: what happens when you
pick a test case that can be handled much more easily in
one language than in another? Do you pick a new test case,
or write inefficient code that no programmer experienced in that
language would actually write? I'm not sure of the answer...

Well, for me the most interesting test would be to actually use all
features available in each of the compared languages. So, if the
standard distribution of a given language includes a library to do a
task, use that library. If there is a syntax feature that makes things
easier, use that too. And so on...

I think this is far more useful in real life than just plain
interpreter/compiled code speed comparison.

I do mostly Java, PHP, and SQL for living. My projects often involve
some obscure algorithms. I usually pick Python for prototyping those
algorithms because the builtin collections and other features allow me
to code faster, read more easily, and thus arrive at the right
solution (or discard a wrong one) more quickly. Then I can rewrite
that in the project's language using more primitive ways like I would
otherwise, but I don't have to switch between thinking about algorithm
and implementation details anymore.

AdSR

[ziller]

> After reading a tutorial on c#, I see immediately that it has all the

features that I disliked in Java.

1) Everything is derived from "Object"
Pure OO is supposed to be an advantage. Otherwise casting hacks have
to be used and understood.
2) Some things have value semantics, some have reference
Like arrays having reference semantics? That's how memory is layed
out in assembler, C, <real programming language writing against the
machine>. This just shows how you need a little understanding of how
the architecture works under the hood to really grasp why things are
done a certain way in a language. It's intuitive and correct if you
understand it properly (and there is no alternative if speed is a
concern).
3) No multiple inheritance
This has been covered to death. MI implementation is a nightmare.
I'm sure some design pattern would map any 'needed' MI solution to an
equivalent one using interfaces and SI.
I'm not sure about 2 others:

4) No serious generic programming support
It'll be there for 2.0. And the implementation is superb (much like
Eiffel's generics)
5) Only OO supported:

Good. I didn't like OO originally either. But if you just look at it
from the perspective of having another layer of abstraction then it
does make lots of sense pragmatically (a good thing: sort of like
modules->packages).

Isn't it...<insert party-line nonsense here>

[Lawrence Oluyede]

In data 7 Aug 2004 08:57:56 -0700, ziller ha scritto:

It'll be there for 2.0. And the implementation is superb (much like
Eiffel's generics)

I don't want to start a religion war, since I also develop with C# but I
don't see the "superb implementation", and to be honest I think it will
mess up the code more and more because of new keywords, new constructs and
so on. I'm not saying that generics has to be dropped but since you are on
a Python NG I think that your are clever enough to see what the limits of
C# are and why generics are getting all this hype

bye!

--
Lawrence (l dot oluyede at virgilio dot it)
"In IE we trust"

[Christophe Cavalaria]

ziller wrote:

After reading a tutorial on c#, I see immediately that it has all the
features that I disliked in Java.

1) Everything is derived from "Object"

Pure OO is supposed to be an advantage. Otherwise casting hacks have
to be used and understood.

With real generics you don't need casting hack.

3) No multiple inheritance

This has been covered to death. MI implementation is a nightmare.
I'm sure some design pattern would map any 'needed' MI solution to an
equivalent one using interfaces and SI.

We have MI in Python and it works somewhat. And I'm sure SI isn't needed
anyway. There must be some design patter mapping SI in assembler or even on
a turing machine.

I'm not sure about 2 others:

4) No serious generic programming support

It'll be there for 2.0. And the implementation is superb (much like
Eiffel's generics)

They aren't out yet and people are already complaining that they are too
limited. So far, despite an horrible syntax and horrible error messages the
C++ templates are still much more powerful than C# generics. And the best
thing is that the constraint system you can find on boost.org for C++
templates is more powerful than the one you have in Eiffel either :D

[Aaron Watters]

Alan Kennedy <al****@hotmail.com> wrote in message news:<D%*****************@news.indigo.ie>...

....IMHO, Microsoft have always been masters of the 80/20 rule: making it
very simple for users to do 80% of what they want, but leaving them
bending over backwards to do the last 20%. Practicality beats purity.

http://management.about.com/cs/gener...reto081202.htm

But I think MS have done a much better job with the .Net CLR ( == java
the virtual machine) and C# ( ~= java the programming language ). They
hired lots of clever people, asked them to come up with something
java-like, but (better|simpler). The result is, IMHO, quite nice: I
felt pretty at home writing C# pretty quickly, mostly because of my
java experience....

I felt at home right away primarily because of my Python
experience. As an exercise I wrote a bplustree implementation

http://bplusdotnet.sourceforge.net

in C#/.NET and translated it to java and python later. The java
port was the most irritating primarily because java methods cannot
return more than one "new" value (a real pain in the ***). Another
java irritant was having to declare all the possible exceptions for
all methods (I punted -- everything "throws Exception"). The
python port was a tad bit simpler than the C#
-- primarily in the derived classes
-- but the speed and safety advantages of type checking in C# were
great advantages.

One of the cooler other things in C# is structs -- which means that C#
can really conveniently be used for high performance numerics, whereas
java can't imo.

Here's hoping mono continues to improve... -- Aaron Watters

===

nothing exceeds like excess.

[gabor farkas]

On Wed, 2004-07-28 at 23:53, Neuruss wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

what i wonder is:
1. class libraries..what class libraries should an ironpython developer
use?
the (c)python ones? the dot-net ones?
so ironPython imho does not mean that now we can run our python programs
in dot-net. it means that if someone wants to write a program using
dot-net libraries, he can now use python...

and..well...what i like in python is not just the language syntax. i
also like the way the python libraries are written, that they are very
easy to use and so on.

so for me a python language which runs on the dot-net classes is not
that much interesting..(unless i need to access dot-net classes).
and also... python is nice, but at the point when you will want to write
a class that can be used from other dot-net languages, you will have to
make it dot-net compliant, so you will have to make it statically typed
(i am not sure that i am using the correct terminology here. what i mean
that you will have to specify the types of the variables and function
return values and so on).

the other aspect are for example binginds...

for example GTK.

there is the pyGTK project.
but there is also the gtk# project.

so imagine that i want to create a program using python+gtk. what should
i use? ironPython + gtk#? (c)python + pygtk?
and to look a little bit into the future: should the pygtk devels switch
to gtk# instead? ;)

i don't know what's the good answer...i am just thinking....

yes...microsoft made the dot-net thing cross-language, but the class
library was defined/specified imho in a way with is mostly suited only
for java-like languages...
gabor

[grv575]

Christophe Cavalaria <ch*************@free.fr> wrote in message news:<41**********************@news.free.fr>...

ziller wrote:

After reading a tutorial on c#, I see immediately that it has all the
features that I disliked in Java.

1) Everything is derived from "Object"

Pure OO is supposed to be an advantage. Otherwise casting hacks have
to be used and understood.

With real generics you don't need casting hack.

Ok then how do you get all classes to have some universal behaviors
(like getType() or whatever) otherwise?

3) No multiple inheritance

This has been covered to death. MI implementation is a nightmare.
I'm sure some design pattern would map any 'needed' MI solution to an
equivalent one using interfaces and SI.

We have MI in Python and it works somewhat. And I'm sure SI isn't needed
anyway. There must be some design patter mapping SI in assembler or even on
a turing machine.

If you want MI to specify that a class is both A and B...then which
semantics (method implementation) should it use if A and B have
different implementations of a certain method? Don't you really just
want to specify the class is A and is B to the extent that it
implements the interface of A and the interface of B? Really MI
causes more issues and confusion than it solves.

Also isn't C++ just syntactic sugar for assembler?

I'm not sure about 2 others:

4) No serious generic programming support

It'll be there for 2.0. And the implementation is superb (much like
Eiffel's generics)

They aren't out yet and people are already complaining that they are too
limited. So far, despite an horrible syntax and horrible error messages the
C++ templates are still much more powerful than C# generics. And the best
thing is that the constraint system you can find on boost.org for C++
templates is more powerful than the one you have in Eiffel either :D

The jury is still out as well.

http://discuss.fogcreek.com/joelonso...&ixPost=144778

[Lawrence Oluyede]

In data 9 Aug 2004 22:56:55 -0700, grv575 ha scritto:

Really MI
causes more issues and confusion than it solves.

Do you know about Python new style classes and MRO?

--
Lawrence (l dot oluyede at virgilio dot it)
"In IE we trust"

[AdSR]

ar**********@yahoo.com (AdSR) wrote in message news:<b8**************************@posting.google. com>...

Peter Hansen <pe***@engcorp.com> wrote in message news:<aZ********************@powergate.ca>...

<snip>
Language comparison is a hard thing: what happens when you
pick a test case that can be handled much more easily in
one language than in another? Do you pick a new test case,
or write inefficient code that no programmer experienced in that
language would actually write? I'm not sure of the answer...

Well, for me the most interesting test would be to actually use all
features available in each of the compared languages. So, if the
standard distribution of a given language includes a library to do a
task, use that library. If there is a syntax feature that makes things
easier, use that too. And so on...

I think this is far more useful in real life than just plain
interpreter/compiled code speed comparison.
<snip>

From another thread, with minor correction:

An interesting comparison, if you want to check it for yourself, is
one between the unittest module and what is described on this page:

http://www.gigamonkeys.com/book/prac...framework.html

Both approaches are based on commonly used features and coding style
of their respective languages. I think this is good example of how
language vs. language comparisons should be done.

AdSR

[Neuruss]

This is from Ironpython's website:

"Integrated with the Common Language Runtime - IronPython code can
easily use CLR libraries and Python classes can extend CLR classes."

"Managed and verifiable - IronPython generates verifiable assemblies
with no dependencies on native libraries that can run in environments
which require verifiable managed code."

"Optionally static - IronPython also supports static compilation of
Python code to produce static executables (.exe's) that can be run
directly or static libraries (.dll's) that can be called from other
CLR languages including C#, VB, managed C++ and many more. Note:
static compilation is only partially implemented in the 0.6 public
release. This will need further development before being useful"

So this should clear most of your concerns.
The good thing about the future stable version of Ironpython, is that
your code will be able to interoperate with code written in other .NET
compliant languages, and its performance will be better than the
standard implementation.
Note that Jim Hugunin is now working for the CLR team, so he will have
full access to the inner "secrets" of this technology to improve it
and make it more suitable for scripting languages.
What's more, there are some new features for the future version of the
CLR that are specially suited for this purpose: lightweight code
generation, for example.

[AdSR]

ar**********@yahoo.com (AdSR) wrote in message news:<b8**************************@posting.google. com>...

<snip>
From another thread, with minor correction:

An interesting comparison, if you want to check it for yourself, is
one between the unittest module and what is described on this page:

http://www.gigamonkeys.com/book/prac...framework.html

Both approaches are based on commonly used features and coding style
of their respective languages. I think this is good example of how
language vs. language comparisons should be done.

And I forgot about the correction: How comparisons *could* be done is what I meant.

AdSR

[Michele Simionato]

Lawrence Oluyede <ra***@dot.com> wrote in message news:<1o*****************************@40tude.net>. ..

In data 9 Aug 2004 22:56:55 -0700, grv575 ha scritto:

Really MI
causes more issues and confusion than it solves.

Do you know about Python new style classes and MRO?

Even knowing about the MRO MI can be painful. Actually,
after fighting with MI in Zope I am starting to hate
it ... :-(
Michele Simionato

[Lawrence Oluyede]

In data 10 Aug 2004 07:07:04 -0700, Michele Simionato ha scritto:

Even knowing about the MRO MI can be painful. Actually,
after fighting with MI in Zope I am starting to hate
it ... :-(

Maybe because they use it *too much* ?
After seeing the (Twisted, Nevow, Atop) source code I recognized that MI
could be useful (they don't use it too much, but they do)

Ciao Michele :)

ps. anyway I'm agree with you, the lesser the better.

--
Lawrence (l dot oluyede at virgilio dot it)
"In IE we trust"

[Terry Reedy]

The good thing about the future stable version of Ironpython, is that
your code will be able to interoperate with code written in other .NET
compliant languages, and its performance will be better than the
standard implementation.

These are, of course, predictions, not facts. As to performance: IP ran
some features faster and some slower. It is possible the the features
tested are a biased sample. It will be interesting to see the final
result.

In any case, it is standard to do time-consuming numerical computation in
Python with the quasi-standard numerical extensions. Unless and until the
these are ported to .NET, such programs will not run. Even when they do,
there is no reason to think that they will be significantly faster.

So some programs may benefit, other may not.

Terry J. Reedy

[Neuruss]

> In any case, it is standard to do time-consuming numerical computation in

Python with the quasi-standard numerical extensions. Unless and until the
these are ported to .NET, such programs will not run. Even when they do,
there is no reason to think that they will be significantly faster.

Well, I don't want to play the advocate of .NET, but I think that we
have to take it with a very practical and pragmatic attitude.
Today, if you want to code something very computational intensive, you
have to resort to C for creating an extension.
Many programers can do it. I can't, because I don't know C and really,
I'm not interested in it.
However, in a .NET environment, you can code your apps in IronPython
(or whatever its name in the future) and when you need extra
performance, you can code this parts in C#. Believe me, I'm just a
newbie, but I can say that translating from Python to C# (if you
already have the python prototype) is a matter of minutes. No
extensions, no hassle...everything compatible and smooth.
Sounds good, don't you think?

[John Hunter]

>>>>> "Terry" == Terry Reedy <tj*****@udel.edu> writes:

Terry> In any case, it is standard to do time-consuming numerical
Terry> computation in Python with the quasi-standard numerical
Terry> extensions. Unless and until the these are ported to .NET,
Terry> such programs will not run. Even when they do, there is no
Terry> reason to think that they will be significantly faster.

As someone with *no* experience with .NET but with some python
extension code I may one day find myself trying to port to IronPython,
I wonder: does anyone have an idea of what is involved in porting a
python extension module to IronPython / .NET. Any thoughts on how the
use of extension building code interacts with this, eg boost::python,
pycxx or SWIG?

Thanks, John Hunter

[Duncan Booth]

John Hunter <jd******@ace.bsd.uchicago.edu> wrote in
news:ma**************************************@pyth on.org:

As someone with *no* experience with .NET but with some python
extension code I may one day find myself trying to port to IronPython,
I wonder: does anyone have an idea of what is involved in porting a
python extension module to IronPython / .NET. Any thoughts on how the
use of extension building code interacts with this, eg boost::python,
pycxx or SWIG?

I think you will find that it will be pretty much a case of rewriting from
scratch. Your extension module will need to be a .NET assembly and this
means writing managed code so you can pretty well forget about any existing
libraries. IronPython isn't likely to be supporting anything close to the
Python C Api.

If you really have to use an existing library then you can maybe write a
wrapper to make it generally usable in .NET. Once your library is usable in
..NET it should become usable by IronPython simply by importing it (assuming
of course that we are talking of some future, more stable version of
IronPython).

[Dieter Maurer]

gr****@hotmail.com (grv575) writes on 9 Aug 2004 22:56:55 -0700:

...
Really MI
causes more issues and confusion than it solves.

I recently implemented a core SGML/XML based content management
system within about 4 months.

It heavily uses mixin classes: PropertyManagement, History, WorkflowSupport,
Persistency, Skinnability, DOMSupport, Publishablity, Versionability, ...

Whenever a class needs some elementary feature, it simply inherits
the corresponding mixin class and (maybe) customizes (overrides)
some adapter methods.

Multiple inheritance is vital for this approach!
While it would (of course) be possible to implement such
a system with single inheritance (or even without inheritance),
I guess that the code size would be about 6 times as large
and it would have taken about twice as long:

A class that now just adds a mixin class to its inheritance
list would get littered with redefinitions
for the mixin class's public API functions.

Each redefinition would stupidly delegate to an embedded
instance of the mixin class, thus it is not difficult.
Nevertheless, it would clutter the code, make unnessary effort,
add potential for trivial bugs.
Dieter

[Peter Otten]

Neuruss wrote:

performance, you can code this parts in C#. Believe me, I'm just a
newbie, but I can say that translating from Python to C# (if you
already have the python prototype) is a matter of minutes. No
extensions, no hassle...everything compatible and smooth.

I that were true, no translation should be needed and no benefits of such a
translation be expected.

But then I'm just a skeptic, don't believe me. Try it.

Peter

[Neuruss]

>

I that were true, no translation should be needed and no benefits of such a
translation be expected.

But then I'm just a skeptic, don't believe me. Try it.

Peter

Even though IronPython will be fully compatible with trhe CLR, it will
still be a dynamic language, with the performance penalty that it
represents.
So in cases where speed is critical, you'll be able to replace the
bottlenecks with c# or other static typed .Net compliant language.
However, Jim Hugunin announced that in the future, Ironpython will
have optional static typing, theoretically making it as fast as c#.