[Python-Dev] __del__ and tp_dealloc in the IO lib

[Giovanni Bajo]

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 
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