[Python-Dev] __del__ and tp_dealloc in the IO lib
rasky at develer.com
Fri Jan 23 16:48:21 CET 2009
On 1/23/2009 4:27 PM, Guido van Rossum wrote:
> On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo <rasky at 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
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.
More information about the Python-Dev