tag:blogger.com,1999:blog-21332048.post9191020702524708210..comments2023-08-24T09:22:20.836-04:00Comments on Developing Upwards: The Snake Pit is About to BurstCalvin Spealmanhttp://www.blogger.com/profile/07161631946662126734noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-21332048.post-5806961135481263232007-01-20T05:43:00.000-05:002007-01-20T05:43:00.000-05:00This is going to be fun! :)
For myself, I'm going...This is going to be fun! :)<br /><br />For myself, I'm going to switch to 3000 after google switches to it. So until then 2.4 is the standard implementation.<br /><br />People can write new things in IronPython if they want though...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21332048.post-50464722204667087442007-01-18T18:21:00.000-05:002007-01-18T18:21:00.000-05:00Hi Bill,
> I just now downloaded and ran pypy.
>...Hi Bill,<br /><br />> I just now downloaded and ran pypy. <br />> After it took the interpreter 15 <br />> seconds to start, it took about a <br />> minute to do "import cPickle".<br /><br />> Running py.py on a test for a <br />> generator of all n-tuples I recently <br />> wrote takes python .146 seconds and <br />> py.py 6.006 seconds.<br /><br />> The "complete" that I was talking <br />> about in my post is not just the <br />> implementation of the python language, <br />> but includes running programs in a <br />> reasonable amount of time.<br /><br />Ah, but that is running py.py on top of CPython, which is necessarily<br />very slow. The way to get a get a comparatively fast pypy is by<br />translating it to C. The result is an interpreter which is between 2-6<br />times slower than CPython, which is not so bad<br /><br />Cheers,<br /><br />Carl Friedrich BolzCarl Friedrich Bolz-Tereickhttps://www.blogger.com/profile/00518922641059511014noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-49305967717402528772007-01-18T17:02:00.000-05:002007-01-18T17:02:00.000-05:00>> 3) JPython and PyPy are not of
>> a sufficient ...>> 3) JPython and PyPy are not of<br />>> a sufficient completeness to work<br />>> with most project, and thus including<br />>> them here doesn't really help. You're<br />>> really talking about the only two<br />>> complete python implementations,<br />>> IronPython and CPython.<br /><br />> Sorry, but that's just nonsense. PyPy > is way more complete and bug-free as a > Python implementation than IronPython. > The main reasons for adopting <br />> IronPython are access to the .NET <br />> libraries, not because it is a <br />> complete Python implementation.<br /><br />Carl,<br /><br />I really respect what you guys are doing with Pypy, but I don't think we're arguing about the same thing here. There's no way that Pypy is of a sufficient maturity or speed to use in a serious project right now.<br /><br />(Alternatively, if it is, you guys are doing a terrible job selling it. I'd be extremely excited if it were.)<br /><br />I just now downloaded and ran pypy. After it took the interpreter 15 seconds to start, it took about a minute to do "import cPickle".<br /><br />Running py.py on a test for a generator of all n-tuples I recently wrote takes python .146 seconds and py.py 6.006 seconds.<br /><br />The "complete" that I was talking about in my post is not just the implementation of the python language, but includes running programs in a reasonable amount of time.Bill Millhttps://www.blogger.com/profile/10065077215311205545noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-36509839183055665172007-01-18T16:31:00.000-05:002007-01-18T16:31:00.000-05:00> 3) JPython and PyPy are not of
> a sufficient co...> 3) JPython and PyPy are not of<br />> a sufficient completeness to work <br />> with most project, and thus including<br />> them here doesn't really help. You're<br />> really talking about the only two <br />> complete python implementations,<br />> IronPython and CPython.<br /><br />Sorry, but that's just nonsense. PyPy is way more complete and bug-free as a Python implementation than IronPython. The main reasons for adopting IronPython are access to the .NET libraries, not because it is a complete Python implementation.<br /><br />Cheers,<br /><br />Carl Friedrich BolzCarl Friedrich Bolz-Tereickhttps://www.blogger.com/profile/00518922641059511014noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-5236629918214043512007-01-18T12:12:00.000-05:002007-01-18T12:12:00.000-05:00I think you're on to something, Calvin, but the em...I think you're on to something, Calvin, but the emphasis on IronPython misses the real issues: whether Python 3.0 will encourage existing users to adopt it, or whether it will instead just punish people who don't hop on board the new shiny thing straight away; whether endless language tweaking (as opposed to library and implementation improvements) gives steadily more marginal benefits for its community of users at increasing cost in other areas.<br /><br />Certainly, previous Python releases have always caused some ripples in the pond: as the day version 2.x comes out, someone's software inevitably declares that version to be a mandatory dependency. But the danger with 3.0 is that the number of changes won't be countable on one hand, nor will they all be superficial. Consequently, there may be a need to maintain multiple branches of one's projects if one seeks to support 2.x and 3.x over time, and as one sees with projects like mod_python (where Apache 1.x is supported by mod_python 2.x, Apache 2.x by mod_python 3.x) perhaps the support won't be as great for the established product, even if it may be more widely deployed.<br /><br />I suppose we have to be thankful that the featurefest that initially surrounded 3.0 subsided as the reality dawned that multimethods, static type declarations and a long list of bikeshed colour charts only make the process of delivering 3.0 longer, more controversial, and probably highly unsatisfactory. But the rush to 3.0 has quite nicely highlighted what some people already observed about CPython development vs. the supposedly unworthy Jython (which gets a lot of "real world" usage) and other implementations: if those implementations "drop anchor" for whatever reason, the claim to being a multi-implementation language whose textbooks aren't already dated before publication just vanishes in the hot air of the claimants.<br /><br />I wonder, with IronPython at 2.4, PyPy and CLPython targeting 2.4, and Jython's developers dreaming of 2.4 compliance, that we already have some kind of established standard, especially if the will to continually chase the 3.0 developers isn't there.Paulhttps://www.blogger.com/profile/01852251269492692660noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-85007400354947765012007-01-18T10:07:00.000-05:002007-01-18T10:07:00.000-05:00And this is the real link (ACK! sorry!):
Should ...And this is the real link (ACK! sorry!):<br /><br /><a href="http://tech.whit537.org/2007/01/should-i-support-ironpython-will-it.html">Should I support IronPython? Will it hurt?</a>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21332048.post-62067123370349893002007-01-18T10:03:00.000-05:002007-01-18T10:03:00.000-05:00This is a manual backlink:
"Everything I know abo...This is a manual backlink:<br /><br />"Everything I know about IronPython, I learned from Fuzzyman's titles passing through my feed reader. I see it as a neat hack: Python + Microsoft, lol. So when Calvin Spealman sounds an alarm that CPython and IronPython are in danger of forking, it makes me think that there's something more going on here."<br /><br /><a hread="http://tech.whit537.org/2007/01/should-i-support-ironpython-will-it.html">Should I support IronPython? Will it hurt?</a>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-21332048.post-2245791138847292952007-01-18T08:30:00.000-05:002007-01-18T08:30:00.000-05:00This comment has been removed by the author.Bill Millhttps://www.blogger.com/profile/10065077215311205545noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-15940211114805432232007-01-18T08:29:00.000-05:002007-01-18T08:29:00.000-05:001) I think having an interpreter as a standard is ...1) I think having an interpreter as a standard is better than having a written (probably incomplete) standard.<br /><br />2) While Zope and Twisted have stayed cpython-centric, there are lots of other important programs getting ported to work with IronPython.<br /><br />3) JPython and PyPy are not of a sufficient completeness to work with most project, and thus including them here doesn't really help. You're really talking about the only two complete python implementations, IronPython and CPython.<br /><br />4) I wouldn't say there's "a lot" of negative sentiment about IronPython. Evidence? I'd say there's basically an apathetic camp and excited camp, in my experience.<br /><br />5) CPython 3.0 is still so far off that IronPython can't begin implementing it, even if it wanted to. Furthermore, who's to say they won't? Have they said anything to that effect?Bill Millhttps://www.blogger.com/profile/10065077215311205545noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-16349840226401918332007-01-18T06:19:00.000-05:002007-01-18T06:19:00.000-05:00Sorry Calvin, but a lot of this comes across as FU...Sorry Calvin, but a lot of this comes across as FUD.<br /><br />"One of the most visible dangers (to me) is being ignored for various political, cultural, and non-technical reasons. IronPython's users are increasingly pushing IronPython-only recipes, libraries, and tutorials."<br /><br />On what do you actually base this? You offer no evidence, and as a member of both the Python community and the IronPython community it just seems completely wrong. Various people (Seo notably) are putting a lot of effort into ensuring that Python extension libraries <i>can</i> be used with IronPython.<br /><br />"Can you really consider IronPython a Python when you don't have os, pickle, or StringIO?"<br /><br />This is just plain incorrect. I've never used StringIO with IronPython (though it probably works). Both pickle and os work fine...<br /><br /><br />No one is talking about the transition of the alternative implemenations to CPython 3.0 compatability.Michael Foordhttps://www.blogger.com/profile/06229713779852499022noreply@blogger.comtag:blogger.com,1999:blog-21332048.post-31749607493203610482007-01-18T05:04:00.000-05:002007-01-18T05:04:00.000-05:00I agree that the CPython community as a whole hasn...I agree that the CPython community as a whole hasn't embraced IronPython but a few are trying to remedy the limited library support provided by the Microsoft distribution <a href="http://fepy.sf.net">http://fepy.sf.net</a>hexdump42https://www.blogger.com/profile/13884562284992556003noreply@blogger.com