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.
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!
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.
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.
I would be pleased if you (or others) could point me to real-world use
cases of this cross-interpreter portability.
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.
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.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.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
