Giovanni Bajo wrote: > On 1/23/2009 4:27 PM, Guido van Rossum wrote: >> On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo <ra...@develer.com> wrote: >>> I miss to understand why many Python developers are so fierce in trying >>> to push the idea of cross-python compatibility (which is something that >>> does simply *not* exist in real world for applications) or to warn about >>> rainy days in the future when this would stop working in CPython. I >>> would strongly prefer that CPython would settle on (= document) using >>> reference counting and immediate destruction so that people can stop >>> making their everyday code more complex with no benefit. You will be >>> losing no more than an open door that nobody has entered in 20 years, >>> and people would only benefit from it. >> >> You are so very wrong, my son. CPython's implementation strategy >> *will* evolve. Several groups are hard at work trying to make a faster >> Python interpreter, and when they succeed, everyone, including you, >> will want to use their version (or their version may simply *be* the >> new CPython). > > I'm basing my assumption on 19 years of history of CPython. Please, > correct me if I'm wrong, but the only thing that changed is that the > cyclic-GC was added so that loops are now collected, but nothing change > with respect to cyclic collection. And everybody (including you, IIRC) > has always agreed that it would be very very hard to eradicate reference > counting from CPython and all the existing extensions; so hard that it > is probably more convenient to start a different interpreter > implementation. > And everybody knows that the past is an infallible guide to the future ... not.
>> Plus, you'd be surprised how many people might want to port existing >> code (and that may include code that uses C extensions, many of which >> are also ported) to Jython or IronPython. > > I would love to be surprised, in fact! > Well both Django and Twisted are on the list of "interested in porting". > Since I fail to see any business strategy behind such a porting, I don't > see this happening very often in the business industry (and even less in > the open source community, where there are also political issues between > those versions of Python, I would say). I also never met someone that > wanted to make a cross-interpreter Python application, nor read about > someone that has a reasonable use case for wanting to do that, besides > geek fun; which is why I came to this conclusion, though I obviously > have access only to a little information compared to other people in here. > Exactly. > On the other hand, I see people using IronPython so that they can access > to the .NET framework (which can't be ported to other Python versions), > or using Java so that they can blend to existing Java programs. And > those are perfectly good use cases for the existence of such > interpreters, but not for the merits of writing cross-interpreter > portable code. > Well, they use IronPython so they can access the .NET framework FROM PYTHON. Would you willfully isolate those users from access to other Python code? > I would be pleased if you (or others) could point me to real-world use > cases of this cross-interpreter portability. > Any code that *can* be run on multiple interpreters is a candidate for use in multiple environments. I don't understand this wish to cripple your code. >> Your mistake sounds more like "nobody will ever want to run this on >> Windows, so I won't have to use the os.path module" and other >> short-sighted ideas. While you may be right in the short run, it may >> also be the death penalty for a piece of genius code that is found to >> be unportable. > > And in fact, I don't defensively code cross-OS portable code. Python is > great in that *most* of what you naturally write is portable; which > means that, the day that you need it, it's a breeze to port your code > (assuming that you have also picked up the correct extensions, which I > always try to do). But that does not mean that I have today to waste > time on something that I don't need. > Perhaps not, but just because you assess it to be a YAGNI in your own case that doesn't mean the same arguments should be applied to (for example) standard library modules. >> And, by the way, "for line in open(filename): ..." will continue to >> work. It may just not close the file right away. This is a forgivable >> sin in a small program that opens a few files only. It only becomes a >> program when this is itself inside a loop that loops over many >> filenames -- you could run out of file descriptors. > > I do understand this, but I'm sure you realize that there other similars > example where the side effects are far worse. Maybe you don't care since > you simply decided to declare that code *wrong*. But I'm unsure the > community will kindly accept such a deep change in behaviour. Especially > within the existing 2.x or 3.x release lines. The community is, I suspect, more in line with Guido's approach than with yours. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com