IronPython-0.6 is now available!

M

Michael Hudson

Edward Diener said:
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
 
S

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
 
I

Indrek Kruusa

Elbert said:
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
 
P

Peter Hansen

Indrek said:
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
 
I

Indrek Kruusa

Peter said:
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
 
J

Jorgen Grahn

On 30 Jul 2004 13:48:02 GMT said:
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
 
A

AdSR

Peter Hansen said:
<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
 
Z

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>
 
L

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

Christophe Cavalaria

ziller said:
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.
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.
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
 
A

Aaron Watters

Alan Kennedy said:
....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/generalmanagement/a/Pareto081202.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.
 
G

gabor farkas

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
 
G

grv575

Christophe Cavalaria said:
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?
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?
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/joelonsoftware/default.asp?cmd=show&ixPost=144778
 
L

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

AdSR

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/practical-building-a-unit-test-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
 
N

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

AdSR

<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/practical-building-a-unit-test-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
 
M

Michele Simionato

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


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
 
L

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

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top