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

[Steve Holden]

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