Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IronPython Moving Forward Again

timothy posted more than 9 years ago | from the interesting-times dept.

Programming 61

immytay writes " Jim Hugunin (Jython, Numeric, and other projects) has issued the first release of IronPython since joining Microsoft in August of last year. IronPython runs on .NET and Mono and is supposedly faster than the C version of Python. This new version is 0.7, while 0.6 was released last summer and covered here. According to the IronPython mailing list, Jim has help from a Microsoft co-worker, and he plans to work toward IronPython 1.0."

cancel ×

61 comments

Sorry! There are no comments related to the filter you selected.

Claim on 1.x times faster and alpha (2, Interesting)

sporty (27564) | more than 9 years ago | (#12093710)

To quote Dilbert, "Is it ok if we do things really fast and really wrong?" I'll be amused if they reach the same speed at 1.0 release.

Re:Claim on 1.x times faster and alpha (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12093995)

Once the code is converted to IL code, the CLR is responsible for the speed. Since the CLR doesn't change much, I would say that if they get working code now, it will have the same performance in 1.0

Embrace. Extend. Extinguish. (-1, Flamebait)

jericho4.0 (565125) | more than 9 years ago | (#12093767)

nt

Read. React. Regurgitate. (4, Insightful)

Keith Russell (4440) | more than 9 years ago | (#12094635)

nt

No, I think we need t.

Every platform that has a .NET implementation already has a native Python implementation, which makes Hugunin's work, while interesting, ultimately redundant. I would love to hear how this little side project reinforces Microsoft's monopoly power in operating systems.

Re:Read. React. Regurgitate. (4, Insightful)

damiangerous (218679) | more than 9 years ago | (#12094770)

Not redundant at all. It's faster than CPython, and it can use both CLR and Python classes as well as extend CLR classes with Python.

you can't use python classes yet (2, Interesting)

llimllib (588506) | more than 9 years ago | (#12095281)

It can *hypothetically* use Python classes - if you look at the release, there's not actually much there that you can use. As the compiler gets more stable and modern, you'll be able to use more of the python library (hopefully).

You missed the point (1)

wyoung76 (764124) | more than 9 years ago | (#12097039)

I don't see it as being redundant at all. For Python developers on almost anything except Windows, you'll most probably have some native Python interpreter installed. You can do all your development, making a great application which targets the .NET CLR, and then deploy it to the world (which by that time will have probably upgraded to the version 2 .NET Framework/CLR). All these Windows users won't have to worry about downloading and installing a native interpreter to run your application, since they'll already have the .NET CLR installed, and if you've compiled to Mono+IronPython, you would reasonably expect that anyone on Windows will be able to use your amazing new application without any hassles. This is the whole point of cross-platform bytecode VMs like the Java VM, or the .NET CLR. It frees you from having to rely on the customer adding more and more stuff to their machines to make your program work. You increase your target market immensely, while using the environment you choose and are most comfortable in.

Except for Mono (0, Troll)

theantix (466036) | more than 9 years ago | (#12093922)

See this entry [usefulinc.com] from Edd Dumbill, author of the (very good) book Mono, A Developers Notebook. Turns out that in the new release, IronPython was made to depend on features that make it incompatible with Mono. How shocking, once the developer got hired by Microsoft the program no longer works with Open Source. How unbelievably shocking this is. So out of character for Microsoft...

Re:Except for Mono (5, Informative)

nightski (860922) | more than 9 years ago | (#12094016)

What you will find is that this is a bunch of BS. They took advantage of the new features in the .NET Framework 2.0 - which will be standardized in the CLI. .NET 2.0 isn't even out by Microsoft yet - so of course Mono isn't going to support it. But Mono is planning on eventually having full support for .NET 2.0. So it will work. Wait till 1.0 - everything will be working then.

Phrase it any way you like (-1, Flamebait)

theantix (466036) | more than 9 years ago | (#12094161)

I phrase it this way: since the lead developer was hired by Microsoft, IronPython was changed to work with Microsoft's implementation of .NET but not Mono's implemention of .NET. Yes, the Mono team will implement these features soon enough as well, but the fact is that IronPython was moved from being a mono-compatible project to one that is not currently.

You perhaps don't read anything sinister into that -- that is your right of course. I would argue that it is foolish to ignore the past history of Microsoft and come to the conclusion that this is yet again just another coincidence. They have repeatedly acted in ways to break compatiblity with alternative programs to increase their monopolistic lock-in power, and this seems to be yet another example of this sort of behaviour.

You are free to disagree and naively think whatever you wish, I don't care to argue the point any further.

Re:Phrase it any way you like (3, Informative)

chris_mahan (256577) | more than 9 years ago | (#12094288)

Someobody expand on that: I believe ironPython is not compatible with .Net 1.0 because of python itself, something to do with dynamic allocation in python. It's something that is supposed to work in 2.0

Re:Phrase it any way you like (3, Insightful)

Keeper (56691) | more than 9 years ago | (#12094366)

If you could demonstrate that the changes were superflous in nature, perhaps you'd have a point. But given that you have no idea what was changed or the reasons for it, you're just being paranoid (and/or trolling, given the nature of your post).

v1.1 of .Net lacked certain features necessary for running a dynamic language (ie: perf would blow). These features were added in v2.0 (ie: perf no longer blows).

Re:Phrase it any way you like (2, Insightful)

BerntB (584621) | more than 9 years ago | (#12094788)

you're just being paranoid [...]
v1.1 of .Net lacked certain features necessary [..]
Without looking into the matter, it might be needed extensions. As you write.

But... I'm not even going to Google for info on protocols, file formats, etc, etc.

Microsoft has a long history of using the standard monopolist tactics of restricting interoperability.

They will hardly stop doing it even if ordered to do so by a court (see recent EU problems). You certainly know that, too, so you are being disingenious.

Re:Phrase it any way you like (2, Insightful)

Keeper (56691) | more than 9 years ago | (#12095156)

So that makes it's ok to react in a knee jerk fashion and point fingers without knowing the actual facts involved? How does that add anything useful to the conversation?

It's not finger pointing if it is fact (1)

BerntB (584621) | more than 9 years ago | (#12098855)

It is not finger pointing if it is well documented facts.

You could of course be right -- Microsoft might be innocent in this particular case .... for now.

But I wouldn't bet money on it. They aren't so stupid they don't try to hide it when they can.

Re:It's not finger pointing if it is fact (1)

arkanes (521690) | more than 9 years ago | (#12099269)

Don't be stupid, and it *is* finger pointing. .NET 2.0 has many improvements over 1.1. That's why it's 2.0 and not 1.1. Not taking advantage of them would be stupid.

Re:It's not finger pointing if it is fact (1)

BerntB (584621) | more than 9 years ago | (#12099883)

I wrote:
You could of course be right -- Microsoft might be innocent in this particular case .... for now.
Multiple people have pointed out that this is typical behaviour of monopolists and the number of examples regarding Microsoft are numerous. They don't even follow court orders.

Noone has argued against that.

So your comment was not relevant. Your insult says more about ... why am I arguing with you? Good bye.

Re:It's not finger pointing if it is fact (0)

Anonymous Coward | more than 9 years ago | (#12104746)

Do you really think that IronPython would have the same requirements right now if he was working for Novell instead of Microsoft? The answer is of course not.

Re:It's not finger pointing if it is fact (0)

Anonymous Coward | more than 9 years ago | (#12099907)

It is not finger pointing if it is well documented facts.

Correct. But there are no documented facts that prove that Microsoft is doing what you claim in this instance: therefore, you are finger-pointing.

Perception / Reality (0)

smitty_one_each (243267) | more than 9 years ago | (#12098887)

Mr. Softy has a historical addiction to ugliness.
They "need" to pile up a lot of "sobriety" to reduce the tarnish on the image. The philanthropy of the Bill and Melinda Gates Foundation amounts to little in the technical community.
One little binge of historical practices will knock them off the wagon.
Mr. Softy wasn't addicted to coca^H^H^H^Hmonopolistic practices; he just liked the way they smelled.

Re:Phrase it any way you like (3, Informative)

IainCartwright (733397) | more than 9 years ago | (#12095449)

Paolo Molaro (one of the mono guys) said on the Ironpython mailing list:

"IronPython 0.7 compiles with the current mono from svn (not with the released 1.1.5, though the patch is minimal)."

And Jim Hugunin has said in the same place that if Ironpython does not compile because it deviates from the spec. then it is a bug and should be entered as such.

Try and avoid knee jerk reactions. You'll just annoy your high horse.

Re:Phrase it any way you like (0)

Anonymous Coward | more than 9 years ago | (#12098334)

MOD PARENT UP and mod that top level comment down!!! talk about flamebait!!!

Re:Except for Mono (0)

Anonymous Coward | more than 9 years ago | (#12096237)

> .NET 2.0 isn't even out by Microsoft yet - so of course Mono isn't going to support it.

Actually, Mono is up to speed with implementing the 2.0 features.

Re:Except for Mono (1, Insightful)

tigersha (151319) | more than 9 years ago | (#12098609)

Ok, this is it. Now I stop reading /.

This place has now changed into a cesspool of religious people who make their own dicks grow by out-hating Microsoft. Not any better than Osama bin Laden, only a different Great Satan. And just as senseless.

2 Things.

a) Why SHOULD Microsoft give a fuck about whatever works on a copy of a project of theirs? So goddamn what if it does not work? Its THEIR project and THEIR right to make work whatever on it. Open Source is not the friggin Messiah demanding absolute subservience.

b) They used features from another version which Mono has not copied yet or even tried to copy yet or claimed to copy yet or claimed to try to copy yet. Capice?

Hello, hello, kneejerk hatred puts YOU on the bad side. Idiot.

This place should be labelled a hate speech site.

Re:Except for Mono (1, Funny)

Anonymous Coward | more than 9 years ago | (#12099113)

Hello, hello, kneejerk hatred puts YOU on the bad side. Idiot.


This place should be labelled a hate speech site.


And thank you for contributing your own stone to the hate edifice.

Re:Except for Mono (0)

Anonymous Coward | more than 9 years ago | (#12101721)

no u

lol

Vs Psyco? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#12094291)

I'd be interested in seeing how this compares to Psyco [sourceforge.net] , the runtime compiler for regular Python.

Psyco is also rather easy to use. For basic usage, put these two lines at the beginning of your program:
import psyco
psyco.full()
..and your program is magically faster! You can also combine with the Py2Exe utility to convert your project to an executable program (although it will still only be compiled at runtime).

Re:Vs Psyco? (0)

Anonymous Coward | more than 9 years ago | (#12096836)

Also, how does IronPython compare to Parrot Python?

(I'd personally suspect Parrot will be the better long-run choice since it's designed with existing scripting languages in mind)

Re:Vs Psyco? (1)

Monkelectric (546685) | more than 9 years ago | (#12097519)

I second this. Psyco is *great*. Unfourtantely its only for the x86 platform, although, so is the MS CLR :)

Re:Vs Psyco? (2, Informative)

lupus-slash (132575) | more than 9 years ago | (#12097615)

Mono runs IronPython just fine on linux/ppc, OSX, amd64 etc.

Re:Vs Psyco? (1)

rffrff (787845) | more than 9 years ago | (#12108816)

would you mind telling us how well does it run on this platforms? IIRC iron python on .net is 1.8 times faster than CPython, and 1.3 times faster than CPython with mono on x86. How good is the performance on ppc wrt to CPython ? (I'm not sure if PyStone runs on ironpython, but that would be a simple number to read)

Re:Vs Psyco? (1)

lupus-slash (132575) | more than 9 years ago | (#12112829)

The ppc mono port has not been optimized as well as the mainstream x86 port, The pystones numbers are about 20% lower using IronPityhon on ppc vs CPython. Part of the issue is that the ppc systems I use still don't support the __thread C keyword which allows a faster runtime and GC implementation so my systems will benchmark a little slower.
We expect to improve the port speed though, of course.

Re:Vs Psyco? (0)

Anonymous Coward | more than 9 years ago | (#12104787)

I really don't know if using Psyco and Py2Exe together are really a good idea. Psyco has memory issues, especially ran as psyco.full().

If one is concerned about releasing executables then they should do the traditional thing and profile the code, find the hot spots, and since this is Python rewrite the hot spots in C. I don't like that but that is closest thing to the "right" thing right now.

OK, whatever (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#12094408)

Who cares?!

It's friggin Python for goodness sake.

Blech.

I feel dirty for even posting in this thread. Python?! What a joke.

Well maybe then they can... (2, Funny)

suitepotato (863945) | more than 9 years ago | (#12094517)

...write a really really fast app in it to convert mounds of Perl code over within my lifetime. And then maybe they can make Windows more stable. And then...

Screw it. I'll settle for the first thing if it ever happens.

Java and .NET Scripting (3, Interesting)

fm6 (162816) | more than 9 years ago | (#12094677)

There seem to be a lot of Java and .NET scripting languages that are just ports of Python or Perl. I suppose these have their uses, but the disconnect between the language and the concepts of the underlying runtime strike me as a problem.

Lately, I've become interested in Groovy [codehaus.org] , a JVM-based scripting language that combines concepts from Java (syntax, access to the class libraries) with concepts from Perl (dynamic typing, native syntax for collections and regular expressions). It would be interesting to see something similar for .NET.

Re:Java and .NET Scripting (0)

Anonymous Coward | more than 9 years ago | (#12095934)

am I missing something? You criticise Python and Perl ports to CLI/JVM for being too "disconnected", and then you say that you are interested in a Perl-like language running on a JVM? Do't you think that's a little hypocritical.

Re:Java and .NET Scripting (1)

hey! (33014) | more than 9 years ago | (#12096392)

Yes you are. You have to look at the language is like rather than making a snap judgement based on a rough analogy about one small aspect of the language.

If you want the skinny, Groovy gives you the power of Java with fewer LOC.

Re:Java and .NET Scripting (1)

Khelder (34398) | more than 9 years ago | (#12096493)

I'm not familiar with Groovy, but I find that Python and Java together in Jython is a good combo. I'm not sure what you mean by saying that Python is disconnected from the concepts of the JVM. At least at the language level, what I like about Jython is that Python and Java *are* different languages.

Two great tastes...

YMMV. Void where prohibited.

Re:Java and .NET Scripting (1)

frodo from middle ea (602941) | more than 9 years ago | (#12096585)

first of jpython is just too slow. with groovy you can compile the groovy script in to a .class and get the same performace (or the lack of ) as a regular java class.

Well almost, as groovy uses reflection for method invocation, it is slower than regular java method call, but this is being worked on.

The great thing about groovy is it supports junit from within, I have cut down my unit testing time drastically ever since I started using groovy.

Plus forget about writing complex build.xmls for your ANT . You can write much more elegant build scripts using groovy.

Groovy really looks like the step in right direction.

Re:Java and .NET Scripting (1)

fm6 (162816) | more than 9 years ago | (#12096634)

By "disconnected" I mean that Python has its own unique approach to objects. It's been a while since I worked with Python, but as I recall, it has some very un-Javaish notions about creating ad hoc object types. I assume Jython implements some kind of compatibility layer to handle this difference in object semantics. Groovy, by contrast, deals with objects in precisely the same way as Java does.

I'm curious to know what benefits you see from runing Python code on a JVM instead a native runtime.

Re:Java and .NET Scripting (1)

Khelder (34398) | more than 9 years ago | (#12099784)

Ok, I see what you mean about the different models of object. So far that hasn't been a problem for me.

As to the benefits of Jython vs. CPython: Sometimes I like to use some of the Java libraries in a Python program, such as Swing. (Although most of the time, if I'm writing the whole thing in Python, its large library base is sufficient.) Often I use Jython because I have a program that's partly in Java and I'm using Jython to debug it, or write a test wrapper, or do something else using my Java code from Jython.

Re:Java and .NET Scripting (0)

Anonymous Coward | more than 9 years ago | (#12104629)

The fact that Java the language and Python tackle the ideas of OO (slightly) differently really should not be a problem. It might require a little more thinking than we like for people trying to implement Python on the JVM but that should not concern the average user who just wants to use Jython. Python and Java's OO systems are not that different anyhow.

As a programmer I think it is important to know how to tackle a problem in several different ways. What this boils down to is knowing a lot of different languages. I have become a better Java programmer because I have learned Scheme and Common Lisp but they are different from Java in many ways.

Re:Java and .NET Scripting (1)

Tobias Luetke (707936) | more than 9 years ago | (#12097122)

Groovy is a bad port or ruby without the amazing syntax beauty ( one of rubys main virtues )

Re:Java and .NET Scripting (5, Interesting)

the quick brown fox (681969) | more than 9 years ago | (#12097412)

Check out Boo [codehaus.org] . It's really a phenomenal language, and much more mature and stable than the version number (0.5) would lead you to believe.

Groovy has been taking a lot [pyrasun.com] of heat [manageability.org] lately. Boo seems not to suffer from the management/community problems Groovy has. In fact, Boo is just plain more exciting; Groovy is just Ruby disguised in Java syntax, as far as I can tell, whereas Boo takes what's best about Ruby (heavy emphasis on closures/blocks), Python (indent-based scoping, first class functions), and C# (static typing, properties, annotations, "using", p/invoke, .NET native), and one-ups them with type inference. It really does provide the best of both static and dynamic typing; there is NO compromise here as far as I can tell.

As a bonus, the tool support is already very good. As with any self-respecting scripting language, it includes an interactive interpreter. (Boo scripts can be interpreted or compiled.) The Visual Studio .NET debugger already works with Boo, and if you write your Boo code in SharpDevelop (a free IDE for .NET platform) you can get code completion, syntax highlighting, code folding, etc. And since it's all statically typed, there is hope for IntelliJ-like refactoring tools, although I don't think any exist yet.

Bottom line, I think any Python, Ruby, or Groovy fan should take a long, hard look at Boo. You will find a whole lot to like.

Re:Java and .NET Scripting (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12117801)

Based on this post I went and downloaded Boo, SharpDevelop and the BooBinding for SharpDevelop.

I must say that I'm thoroughly impressed!

I started off exploring some features of the CLI and Boo was able to handle all of it with grace. Delegates are a joy to use since Functions are objects. The Type and reflection systems all work as expected. The Type Inference system is really innovative. It saves you typing through inference, but maintains strong type functionality with compile time error checking. Much of the python nonsense (self, self self), and some useufl perl features added in like literal regular expressions and string interpolation.

My jaw nearly dropped when I realized you can debug and step through code using the builtin .NET debugger. I don't know what happens with Mono.

I hope this project goes far. I'm only worried about the low amounts of news posts and mailing list traffic.

open source maybe, where's the community? (5, Insightful)

mike_sucks (55259) | more than 9 years ago | (#12096611)

As Edd Dumbil pointed out, there's a number of questions that need to be answered before it is worth getting behind IronPython, such as:

- Is it actually Free Software?
- Why do I need a passport account Passport to participate?
- Why are you bothering to release source code if you're not willing to
accept patches?
- Why don't you want to get it working with Mono?

And so on.

Re:open source maybe, where's the community? (1)

mike_sucks (55259) | more than 9 years ago | (#12096625)

Err, here is Edd's post [usefulinc.com] . Whoops.

Common Public License version 1.0 (2, Informative)

captwheeler (573886) | more than 9 years ago | (#12097408)

from www.ironpython.com

IronPython-0.6 is now available as Open Source Software under the Common Public License version 1.0 [eclipse.org] . A single zip file containing both the source code and the binary executables can be downloaded below.

Re:Common Public License version 1.0 (1)

mike_sucks (55259) | more than 9 years ago | (#12097827)

That's a start. It is Free Software, but too bad it isn't GPL compatible.

Re:Common Public License version 1.0 (1)

emidln (806452) | more than 9 years ago | (#12100922)

That's a very good start, and I think it should about stop there myself. The CPL has additional patent restrictions the GPL does not. In fact, it seems to be an all-around better license, except it is not GPL v2 compatible. Then again, the FSF doesn't think either Apache license, or a number of other licenses are compatible either. Just because they are not compatible with the GPL, doesn't necessarily make them a bad license. I think the FSF even had a statement on the CPL going something like (to paraphrase) "we don't necessarily disagree with the additional provisions of the license, but as it stands, it is incompatible with the GPL."

Re:open source maybe, where's the community? (1)

Jussi K. Kojootti (646145) | more than 9 years ago | (#12098453)

Why do you say he doesn't want Ironpython to work in Mono?
  • The first sentence on www.ironpython.com is IronPython is a new Python implementation targeting the .NET and Mono platforms.
  • Lupus@ximian said on the mailing list that ironpython 0.7 compiles with current SVN Mono code.
So... what's the problem?

This is what Hugunin said about accepting patches:

Given the company that I work for, I would have to spend a LOT of time with lawyers working out the right contribution policy in order to accept even small patches. This extreme level of legal caution is part of working for a large company. I don't believe that's the best way for me to spend my time right now in order to build the best IronPython 1.0. After 1.0, the value of building a strong external developer community goes up and I expect to revisit this question.
Personally I can understand that, and am willing to give him the benefit of doubt. By the way, he kind of promised to lessen the reliance on passport.

Re:open source maybe, where's the community? (2, Informative)

mike_sucks (55259) | more than 9 years ago | (#12098848)

Have a read of this message [dreamhost.com] . If some of these issues have been cleared up, then great!

If Hugunin has issues accepting patches because of who he works for, then that's a shame. I'm glad he thinks that that may change post 1.0, but why will these issues suddently be easier to work around just because the code has reached a stable version? If they can be worked around, why not do so now?

How long will it take for 1.0 to be released? Are people prepared to wait that long rather than forking, starting from scratch or getting behind an alternative effort right away? Will anyone still be around by then to be to be turned into an instant community? These things can't just get turned on or off.

If you'll still (lessend or not) need to get a Passort account and use gotdotnet to be part of the community, that will still be very off putting for many potential hackers. Having a Passport account is an identity theft waiting to happen. Why is required to be a part of the community? A web forum is a massively inefficient way of communicating when compared to a mailing list, why should people have to suffer it?

I still would want some answers to these (and Edd Dumbill's, Miguel de Icaza's and Paolo Molaro's) questions before getting behing IronPython. The fact that such questions are raised at all is troubling, however.

Re:open source maybe, where's the community? (2, Insightful)

Jussi K. Kojootti (646145) | more than 9 years ago | (#12099013)

If Hugunin has issues accepting patches because of who he works for, then that's a shame.
Of course it's a shame, but Hugunin might not be working on IronPython at all if MS didn't pay him -- which is better? You know, most employers put some restrictions on how their employees use their time.
I'm glad he thinks that that may change post 1.0, but why will these issues suddently be easier to work around just because the code has reached a stable version?
Hugunin thinks there are pros and cons to accepting patches, and that the cons currently outweigh the pros. Later, when the codebase is more mature, outside patches make more sense (patches generally touch less code, there are less conflicts , easier to review). I'm not sure his evaluation of the situation is 100% correct, but that does sound quite understandable to me.

I still would want some answers to these (and Edd Dumbill's, Miguel de Icaza's and Paolo Molaro's) questions before getting behing IronPython. The fact that such questions are raised at all is troubling, however.
Hugunin is participating [dreamhost.com] in this discussion. Really, he seems to be quite reasonable (gotdotnet and the web forums seem to be just tools for him -- if people really want to use something else, then that's what's going to happen).

The fact that questions are raised is not troubling, it just means there is real interest on this project. Different people, groups and companies will always have differing opinions on how a project like this should be run. Since it's a free software project, this is not dangerous - 'wrong' decisions by the project lead will result in a fork (only if the project really is interesting enough to warrant that much work though).

Re:open source maybe, where's the community? (1)

mike_sucks (55259) | more than 9 years ago | (#12099713)

> Later, when the codebase is more mature, outside patches make more sense
> (patches generally touch less code, there are less conflicts , easier to
> review).

Patches for FLOSS projects usually come in two forms: uber patches from major contributors and 2-line bug fixes from knowledgeable users.

By rejecting the former, you're discouraging people from becoming intimately familiar with the codebase early on - when it is usually easier to understand, so you're less likely to get such patches later on. If it's too much work to integrate a patch, politely reject it rather than rejecting all, carte blanch.

By rejecting the latter, you're adding to the work you have to do finding and fixing the bug, or you're releasing buggy software.

I really can't see much benefit for not accepting patches and unless he gets swamped by huge numbers of patches (which would be good from other perspectives anyway), I can't see any real downside to accepting them.

> Hugunin is participating in this discussion. Really, he seems to be quite
> reasonable (gotdotnet and the web forums seem to be just tools for him -- if
> people really want to use something else, then that's what's going to happen).

Yes, I realise he is talking to people, which is good. If these issues get sorted out, then IronPython has a much better chance of becoming a successful project.

> The fact that questions are raised is not troubling, it just means there is
> real interest on this project.

If I was generating interest but discouraging those who are interested, I would find that troubling.

Who cares? (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#12098677)

Ruby >>>>>>> Python

Re:Who cares? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12098730)

Yes, if you are female, 13 year old or a ass-to-mouth hardcore fagot.

winforms api (1)

immytay (743013) | more than 9 years ago | (#12099233)

I suppose the main benefit I saw was a more palatable way to tap into the winforms api. Of course, as another poster mentioned, it still needs a lot of work to be usable.

Re:winforms api (0)

Anonymous Coward | more than 9 years ago | (#12104697)

Winforms is probably at the bottom of the list ultimately. More than access to winforms it gives one access to *everything* .Net. Winforms really is not all that exciting.

well... (0)

Anonymous Coward | more than 9 years ago | (#12102407)

IronPython runs on .NET and Mono and is supposedly faster than the C version of Python.
...which isn't saying much!

Microsoft's claws (0, Interesting)

shitface (121619) | more than 9 years ago | (#12104224)

A lot of people have become slightly unhappy with IronPython. The development has been slow and private and the license is questionable.

Here is what Edd Dumbill, a Mono developer had to say about it:
Perhaps more seriously, third-party patches won't be considered until after the 1.0 release. Hugunin encourages people to be involved, but only in filing good bug reports and feature requests. And when doing this involves a .NET passport, and using the GotDotNet web forums rather than good old mailing lists, it's a bit of a disincentive.

Added to that, there's some uncertainty about the freeness of IronPython's license. While it looks free, it's got the same name, "Shared Source", as several Microsoft licenses that definitely are not free.

Does not sound good. Edd recommends for people looking for a Python experience on .Net to try boo [codehaus.org] which is similar to Python. I have read some Python blogs that think this is a bad idea but I think is because they are so Python-centric and the suggested solution is not called Python. Oh well, another tear for no one.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>