Article of interest: Python pros/cons for the enterprise

[Paul Boddie]

Could Boo or Cobra fit the bill ? If not, what's missing at a
technical level (i.e. ignoring current maturity, community size,
marketing, etc.) ?

Boo and Cobra have their interesting sides, although I doubt that I'm
alone in finding it hard to take them as seriously as I might because
of various blatant, seemingly gratuitous, incompatible differences
with Python. And although one can always say that we should ignore
community size, what we've seen from Python-oriented projects like
PyPy and Shed Skin is that without being able to use a lot of existing
code, people don't hang around considering using something seriously
for very long, even if there's merit in hanging around and reworking
existing code.

Both Boo and Cobra are quite focused on the CLR, which isn't
necessarily appealing for a number of reasons (technical, legal [*]).
They both promote static typing plus type inference, although it
doesn't seem to be particularly extensive type inference and may
benefit from working against a load of statically typed libraries.
Both have language extensions which people have argued for in Python,
but choose different ways of doing things: Boo's property declarations
are minimal but seem out of place; Cobra's property declarations add a
bit more syntax; Boo provides some support for preconditions (as far
as I can see); Cobra has syntax for contracts. Boo also adds a load of
extra stuff for interfaces, abstract methods, and so on.

I don't blame people for going off and doing their own language: it's
clear that Python is moving in it's own direction and introducing
syntax incompatibilities which aren't justified by high level
objectives such as performance or compile-time tests. But since the
days of Vyper (a defunct Python implementation in OCaml which added
stuff like regular expression syntax) people judge new languages by
the extent of the differences to Python and on their perception of the
value of such differences. For example, I'm still unimpressed by the
eager introduction of type declarations in such new languages when we
already have things like Pyrex which provide similar capabilities, and
when I think that there's a certain amount of investigation to be done
to determine whether such things are really worthwhile, given the
potential impact of people writing "value as int" all over the place.

I also think that in order to achieve certain objectives many new
languages make the mistake of adding new syntax rather than
principally removing confusing stuff from Python. It should be more
about "Python 300" than "Python 30000", in my opinion.

Paul

[*] Yes, Mono is Free Software, but no-one has really addressed the
Microsoft patent issues other than just giving people the brush-off
and telling them not to worry about it. I don't think the Microsoft-
Novell agreement did much to make people feel any better about this.

 

[Nicola Musatti]

In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII.

Ok, I'll bite. Here's a straightforward Python expression:

a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]

Consider how many intermediate objects are being allocated in figuring
out that listcomp. Do you REALLY want to manage all the deallocation
with something like RAII?

What makes you think that a translation of a similar expression would
involve explicit dynamic allocation at all? Barring bugs, here's an
equivalent example:

#include <iostream>
#include <map>
#include <vector>

int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }

std::map<int, int> izip(int i, int j) {
std::map<int, int> m;
m = j;
m[j] = i;
return m;
}

class A {
int i, j;
public:
A(int ii, int jj) : i(ii), j(jj) {}
int frob() { return i + j; }
};

A h(int i, int j) { return A(i, j); }

int main() {
int m1 = 3;
int m2 = 4;
std::vector<int> a;
std::map<int, int> m = izip(m1, m2);
for ( std::map<int,int>::iterator i = m.begin(); i != m.end(); ++i )
{
if ( h(i->first, i->second).frob() == 7 )
a.push_back(f(i->first) + g(i->second));
}
for ( std::vector<int>::iterator i = a.begin(); i != a.end(); ++i )
std::cout << *i << '\n';
}

As you can see the standard library takes care of all memory
management.

Cheers,
Nicola Musatti

 

[Bruno Desthuilliers]

Nicola Musatti a écrit :

Nicola Musatti a écrit : [...]

So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.

Sorry but I don't buy your arguments.

I suspect nobody seriously does, not even in C++ newsgroups ;-)

Mmm... Feel like I've been trolled !-)

Oh, I'm convinced that Python wins in many contexts, but I believe
that it has more to do with the number of batteries that come with the
package rather than to its being a dynamically typed language. Is this
controversial enough? ;-)

Brillant !-)

 

[Roy Smith]

Yet I'm convinced that even such partial guarantee is worth having.

Partial guarantees are like being a little bit pregnant.

 

[Lou Pecora]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Carl Banks
Sent: Wednesday, February 20, 2008 8:39 PM
To: (e-mail address removed)
Subject: Re: Article of interest: Python pros/cons for the enterprise

C++ is a compile-time, type-checked language, which means it is
totally safer for newbies than Python. Yep, your big company is
totally safe with newbie C++ programmers.

Eh, don't laugh too hard. Since Python code isn't type-checked until
the actual code block is executed, you have to go through the extra step
of testing/running every line of code before you'll find an error.
Then there's the problem of how mutable Python objects are. So even if
you execute every line of code, you might not have executed the code
with every possible type of object combination.

Compared to a statically typed language, it can get very expensive to
write comprehensive test cases for python scripts. So I wouldn't be
quick to dismiss the notion that Java/C#/C++ are more newbie-safe than
Python. =/

An amusing case in point was where I had a type-cast error in an
exception's catch block's print statement. This simple error caused the
program to stop with an unhandled exception. Something that basic would
have been caught in a statically typed language very early in the dev
cycle when it's cheaper to fix the problem. And the idea of
running/testing exceptions or simple print statements isn't always
foremost in people's minds. =P[/QUOTE]


Well, you're technically right about static typing. That could head off
some bugs... But my experience over several years has been that this has
never happened to me. That is, where I need to test every line of code
or even half of them. What usually happens is that I get an error, I
get the line and module, go there, and realize I tried to use data that
didn't fit the expression (e.g. an object without the required method).
Usually, a one-step fix. What still occasionally gets me is mutable
objects where I just use "=" to set two things (accidentally) equal to a
mutable object instead of copying. Then modify one and get and error
when the other object is used since they were the same object. I know
better, but I have a half life on this of about 4 months which means
that about twice a year this one gets me.

Looking at it the other way having done C++ development, I am w a y
more productive in Python and overall spend far less time debugging.
Just my experience. YMMV.

 

[Nicola Musatti]

Partial guarantees are like being a little bit pregnant.

Yes, and I'm sure your tests cover all possible paths through your
code.

Cheers,
Nicola Musatti

 

[Chris Mellon]

In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII. GC deals with memory very
reasonably, but makes it more complicate to deal with other resources.

There are many different kinds of resource and they have different
optimal handling techniques. Memory in particular is really easily
handled by GC - it's a resource that you can reclaim under pressure,
so deferring it's collection and release makes sense, and it's even
common these days for high quality GC to beat manual management in
performance (never mind correctness). Other kinds of resource are much
more timely, and require tight control over scopes, like mutexes and
other locks. RAII is fantastic for these sort of things. Shared but
limited resources like files work best with refcounting (closing a
file that something else holds a reference to is usually an error).

Optimally, you would have a language that provides all three in easy,
transparent ways. Python only provides two, but the first on is the
least important so Python manages at least a B. C++ provides all 3,
but importantly there's no language level enforcement of use, so you
can (and people do, and this is a common source of bugs) accidentally
bypass the mechanisms.

If I had to use C++ these days, I'd use D instead.

 

[Marc 'BlackJack' Rintsch]

In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII.

Ok, I'll bite. Here's a straightforward Python expression:

a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]

Consider how many intermediate objects are being allocated in figuring
out that listcomp. Do you REALLY want to manage all the deallocation
with something like RAII?

What makes you think that a translation of a similar expression would
involve explicit dynamic allocation at all? Barring bugs, here's an
equivalent example:

#include <iostream>
#include <map>
#include <vector>

int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }

std::map<int, int> izip(int i, int j) {
std::map<int, int> m;
m = j;
m[j] = i;
return m;
}

class A {
int i, j;
public:
A(int ii, int jj) : i(ii), j(jj) {}
int frob() { return i + j; }
};

A h(int i, int j) { return A(i, j); }

int main() {
int m1 = 3;
int m2 = 4;
std::vector<int> a;
std::map<int, int> m = izip(m1, m2);
for ( std::map<int,int>::iterator i = m.begin(); i != m.end(); ++i )
{
if ( h(i->first, i->second).frob() == 7 )
a.push_back(f(i->first) + g(i->second));
}
for ( std::vector<int>::iterator i = a.begin(); i != a.end(); ++i )
std::cout << *i << '\n';
}

As you can see the standard library takes care of all memory
management.

Aaah, that's much nicer and easier to understand than the list
comprehension. After this great example I'll switch to C++. ;-)

But somehow you still manage memory by writing in a style that favors
value types.

SCNR,
Marc 'BlackJack' Rintsch

 

[Nicola Musatti]

Aaah, that's much nicer and easier to understand than the list
comprehension. After this great example I'll switch to C++. ;-)

You should. As you can see C++ is waaaaay more explicit than
Python ;-)

But somehow you still manage memory by writing in a style that favors
value types.

Certainly, but this is a natural C++ programming style, at least for
those that aren't too deeply rooted in their C heritage.

Cheers,
Nicola Musatti

 

[Paul Rubin]

Yes, and I'm sure your tests cover all possible paths through your code.

That is the point of type checking. With a sound type system, "int x"
makes sure, at compile time, that x stays an integer through every
possible path through the code and never becomes a string or anything
like that. That's why Pierce's book on type systems describes them as
"lightweight formal methods".

The happening thing in language research these days is designing more
and more powerful type systems so that you can make sure, at compile
time, that any predicate that you can describe mathematically remains
true through all possible paths through the code. So you can have the
compiler make sure, through every possible path through the code, not
just that x is some integer, but is the actual integer that you want,
e.g. if you want x to be the largest prime number smaller than 3*y,
you can define a type for that, and then if your program to compute x
passes the type checker, it cannot compute the wrong value.

Python is a very pleasant and productive environment for banging out
code quickly that does practical things straightforwardly, but in some
ways it feels almost like assembly language, in that you have to keep
track in your head of what types of values your program is computing,
instead of being able to rely on the compiler to catch errors.

 

[Paul Rubin]

a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]

Consider how many intermediate objects are being allocated in figuring
out that listcomp. Do you REALLY want to manage all the deallocation
with something like RAII?

What makes you think that a translation of a similar expression would
involve explicit dynamic allocation at all? Barring bugs, here's an
equivalent example: ...

There you replace one line of code with 40+ lines to get around the
absence of GC. Sounds bug-prone among other things.

int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }

That is not a reasonable translation, since you've assumed the output
of f and g are integers that don't need to be dynamically allocated.
Maybe in the Python example, f and g and x and y are all bignums or
matrices or something like that.

 

[Jeff Schwab]

The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)

How difficult would that be? Could it be done in stages? I would be
willing to spend some time on that kind of project. Since I know almost
nothing about Python internals, though, I'd appreciate it if a
C++-fluent Python expert could give an estimate in person-months. Also,
what would be the general break-down? Maybe:

(1) Prepare a build environment appropriate for Python, supporting code
in both C and C++. Include unit-test targets, and a mechanism for
module developers to add unit tests to those targets.

(2) Get all the headers C++-clean.

(3) Begin translating one module at a time. Different people could work
on different modules, and add their test-cases to the global target.

One potential problem would be linkage. Would Python-internal C++
modules still have to provide C-linkable APIs, so that they could be
invoked from other parts of Python? A breakdown of module dependencies
would help address this issue, so that it would be clear which parts of
the code-base would be directly affected by translating a given module
to C++.

At the external API level, would it still be important to support
C-style linkage, even if the implementation code isn't written in C? I
don't know whether it's realistic for people embedding Python in non-C++
applications to have to work directly with C++ APIs.

 

[Jeff Schwab]

If you have garbage collection, the management of memory is
consistent, and mostly automated.


Managing resources is just not that difficult,


Especially if the there are fewer resources to manage than there would
have been heap objects....


A special language feature more managing dynamically allocated robs
the programmer of a reliable way to free memory automatically,


without bringing
anything of particular value to the table.

It cuts both ways, chief.

You like managing your own memory, be my guest. But please don't
imply that you're putting forth less effort because of it. You're
just putting forth different effort.

I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.

But I guess we'll agree to disagree.

 

[George Sakkis]

How difficult would that be? Could it be done in stages? I would be
willing to spend some time on that kind of project.

Yeah right.. what we need is yet another implementation of Python. At
least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a
better motivation than "my language is better than yours". I am sure
your time, skills and experience would be much appreciated in more
useful projects.

George

 

[Marc 'BlackJack' Rintsch]

Certainly, but this is a natural C++ programming style, at least for
those that aren't too deeply rooted in their C heritage.

Or are used to think of OOP as a graph of objects that are communicating
with each other. In the value type style you are "talking" to copies of
objects all the time which I find a bit confusing because *I* have to keep
track of which maybe not so identical twin brother of an object I'm
talking at each point.

Also it seems odd to me to copy large collections around instead of
passing references. Your `izip()` creates a quite small `map` -- what
about big ones. With mutable objects!?

I like C and until I discovered Python, I liked Java. Then I looked at
C++ and find it really ugly and confusing. Even Haskell looks somewhat
easier to me. Someone mentioned D -- that's a good step between C++ and
Java IMHO. Garbage collection plus an easy way to declare "scoped"
variables that are destroyed when the names goes out of scope. So one can
leave memory management most of the time to the runtime but use RAII for
files, locks and other resources. The `main()` of your C++ example looks
like this in D:

void main()
{
auto m1 = 3;
auto m2 = 4;
scope a = new int[0];
scope m = izip(m1, m2);
foreach (int first, int second; m) {
if (h(first, second).frob == 7) {
a ~= [f(first) + g(second)];
}
}
foreach (int i; a) writef("%d\n", i);
}


Ciao,
Marc 'BlackJack' Rintsch

 

[Jeff Schwab]

Jeff Schwab a écrit :

Carl Banks a écrit :
You Used Python to Write WHAT?
http://www.cio.com/article/185350
"""
Furthermore, the power and expressivity that Python offers means
that it may require more skilled developers.
[...down to the summary...]
Python may not be an appropriate choice if you:
[...]
* Rely on teams of less-experienced programmers. These
developers may benefit from the wider availability of training
for languages like Java and are less likely to make mistakes with
a compile-time, type-checked language.
"""

(snip)

C++ is a compile-time, type-checked language, which means it is
totally safer for newbies than Python. Yep, your big company is
totally safe with newbie C++ programmers.


Mouarf ! Brillant demonstration, thanks Carl !-)

(and BTW, +1 QOTW)

NB: This is not a troll. (Please, nobody try to be cute with a "yes
it is" reply.)

NB : standard disclaimer about all the following being MVHO.

c.l.python seem to be about the most close-minded of any of the
currently popular language-specific news groups.

May I suggest you take a tour on c.l.lisp then ?-)

It's just taken for granted that Perl and C++, two of my personal
favorite things in this world, inherently favor ugly, buggy code.

I wouldn't say so.

It's a fact that C++ is a really complex language with quite a lot of
room for BigMistakes(tm), and that there's something like a
'my-code-is-more-cryptic-than-yours' culture in Perl. You cannot
seriously argue on this.

I'm not going to argue, because I'm tired of arguing. But I think
you're SeriouslyMistaken(tm).

Now this has nothing to do with the respective merits of both languages
(FWIW, Perl, as a 'Practical Extracting and Reporting Language', beats
any other language I know pants down), and I'd be sorry if you were to
confuse what is mostly on the friendly jokes side with mere bashing. You
may not have noticed, but quite a lot of people here have a working
experience with either C++ and/or Perl.

Yes. These "jokes" don't strike me as friendly, though. They strike me
as ignorant and hostile.

As for my above comment, it doesn't imply anything else than the fact
that C++ is way harder to learn than Python (or Ruby etc...), and that
bugs in C++ code are likely to have way more nasty results.

Both of which I disagree with. I don't see how the same brain can
believe it's much harder to do good things, yet much easier to do bad
things, in the same language.

The joke is
not "against" C++, but about people asserting than static type checking
is safer than dynamic type checking without realizing that what is
really important is*runtime type checking - something C++ doesn't provide.

C++ does provide some run-time type-checking, whereas Python offers
virtually no static type-checking. Clearly, C++ does not natively have
a run-time environment as powerful as Python's, and that's one of the
primary reasons to use Python. If you need a heavyweight runtime
environment available from C++, you have to provide one. This is a
direct consequence of early design decisions intended to make C++
competitive with C. I have yet to see a runtime-heavy C++ library I
really like, whereas Python, Ruby, and Java all have fantastic sets of
run-time facilities.

NB : As a side note, and while being myself a bit passionated when it
comes to languages and my job in general, I would not go as far as
labelling any language or technology as "one of my favorite things in
this world".

That's OK. I really do feel that way, though. Call me a dork.

Indeed. Bad coders write bad code, period. And I think we've all been
bad coders one day, and that we're all still bad coders sometimes.

Aha! Now we're getting somewhere!

And of any other language. Now a decent C++ or Perl programmer can be
proficient in Python in a couple weeks and become a master within a year
at worst. And it seems that non-professional, occasional programmers
(hobbyists, gamers, scientists, and any other kind of power user) are
able to get their job done in Python without much pain.

They can get their jobs done with C++ without much pain, too, given even
a little bit of decent guidance. It's true that you *can* shoot
yourself in the foot with C++, but you kind of have to work at it. (One
good way is to write C code, and think it's C++.)

Sorry but I don't buy this.
OK...



Stating the obvious is not bashing. In my last shop I was working with
(very talented BTW) Perl programmer, and he was the first to make jokes
on Perl's abuse of cryptic syntax.

It's not abuse. It's meaningful and compact. The $scalars are
intuitive to anybody who has ever written a shell script, the @arrays
are immediately recognizable... I agree it takes some getting used to,
but then it becomes clear as day.

 

[Jeff Schwab]

Yeah right.. what we need is yet another implementation of Python. At
least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a
better motivation than "my language is better than yours". I am sure
your time, skills and experience would be much appreciated in more
useful projects.

Neither C++ nor C is "my" language, nor "yours." I love all my children
the same. That said, your point is well taken.

What I would like is not so much a new Python implementation, as a
vehicle to help demonstrate a few things to other Python users.
Recently, I've had a few replies in tones that imply I'm on the brink of
entering several kill-files, mostly because I express disagreement with
a few closely held beliefs of some other c.l.p posters. For example,
the following are widely held opinions with which I disagree:

(1) Python is a gotcha-free language.

(2) C++ is basically the same language as C, but more complicated.

(3) Garbage collection is at least as desirable a language feature as
deterministic destruction.

(4) Static typing is inferior to dynamic typing.

One of the things that's supposed to be great about Python is the user
community, and in many ways, that community is wonderful; for example,
both new and experienced users can quickly get a variety of solutions to
any given coding issue, just by asking for help.

In other ways, though, the Python community is just blindingly ignorant,
arrogant, and argumentative. I expect my use of Python to increase in
the coming years, so I want the best possible relationship with other
regular users, especially on Usenet. To do that, I think it would be
helpful to have an informed discussion. Instead, I mostly just the same
old justifications for baseless bigotry:

"I worked with crappy [Perl or C++] code for ten years, so when I tell
you [Perl or C++] encourages crappy code, I know what I'm talking about."

"These beliefs are accepted by just about everybody. You don't *really*
think all these bright people are wrong, do you?"

"C++ is not newbie-friendly; if you need proof, just look at all these
really low-level ways you can screw yourself."

When I see this silliness again and again, it really breaks my heart,
because the culture of the software development industry has a strong
effect on the quality of my own life. I care about clean air, because I
breath it; clean water, because I drink it; and I am starting to become
really concerned about the clarity of mind of the Python community,
because I hope to rely on it.

 

[Ryan Ginstrom]

On Behalf Of Jeff Schwab

When I see this silliness again and again, it really breaks
my heart

If you allow your heart to be broken by others' opinions, you're setting
yourself up for a lot of disappointment IMHO.

I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.

I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.

Regards,
Ryan Ginstrom

 

[Jeff Schwab]

If you allow your heart to be broken by others' opinions, you're setting
yourself up for a lot of disappointment IMHO.

It's not so much their opinions, as the fact that their opinions
strongly influence their work. But you're probably right, anyway.

I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself.> I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.

I'm not much of a Kool Aid drinker. I just tend to find, when I
develop anything non-trivial in a language other than C++, that I wish I
had used C++, because it would have allowed me to enforce design
semantics more efficiently. Optimization has nothing to do with it; I'm
a firm believer in profiling before you optimize.

I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.

For several reasons, even!

 

[Jeff Schwab]

Python has this too, except it's using a special type of scope
created by the "with" statement.

Yes, this seems to be the Python way: For each popular feature of some
other language, create a less flexible Python feature that achieves the
same effect in the most common cases (e.g. lambda to imitate function
literals, or recursive assignment to allow x = y = z).

CPython does not guarantee that the reference count will become zero
at the end of the statement. It only happens to work that way in your
example, because the file.read operation doesn't make any new
references to the file object anywhere.

It doesn't "happen" to work that way in the example; it works that way
by design. I see what you're saying, though, and it is a good point.
Given a statements of the form:

some_class().method()

The method body could create an external reference to the instance of
some_class, such that the instance would not be reclaimed at the end of
the statement.

Other code might well do
something different, especially in a complex multi-statement scope.
Your scheme's

It's not "my" scheme. I got it from Martelli.

determinism relies on the programmer accurately keeping
track of reference counts in their head, which is precisely what
automatic resource management is supposed to avoid.

This is a special case of the reference count being 1, then immediately
dropping to zero. It is simple and convenient. The approach is, as you
rightly point out, not extensible to more complicated situations in
Python, because the reference counting ceases to be trivial.

The point is that once you tie object lifetimes to scope, rather than
unpredictable garbage collection, you can predict with perfect ease and
comfort exactly where the objects are created and destroyed. If you can
then request that arbitrary actions be taken automatically when those
events happen, you can pair up resource acquisitions and releases very
easily. Each resource has an "owner" object whose constructor acquires,
and whose destructor releases. The resources are released in the
reverse order, which is almost always exactly what you want.

Suppose you are using objects that have to be closed when you have
finished with them. You would associate this concept with a type:

class Closer:
def __init__(self, closable):
self.closable = closable)
def __del__(self):
self.closable.close()

The C++-style paradigm would then let you do this:

def my_func(a, b, c):
a_closer = Closer(a)
b_closer = Closer(b)
c_closer = Closer(c)

# ... arbitrary code ...

If an exception gets thrown, the objects get closed. If you return
normally, the objects get closed. This is what "with" is supposed to
replace, except that it only seems to cover the trivial case of a
single, all-in-one cleanup func. That's only a direct replacement for a
single constructor/destructor pair, unless you're willing to have an
additional, nested with-statement for each resource.

Now suppose there is an object type whose instances need to be
"released" rather than "closed;" i.e., they have a release() method, but
no close() method. No problem: You have the Closer class get its
action indirectly from a mapping of types to close-actions. Whenever
you have a type whose instances require some kind of cleanup action, you
add an entry to the mapping.

class Closer:
actions = TypeActionMap()

# ...

def __del__(self):
actions[type(self.closable)](self.closable)

The mapping is not quite as simple as a dict, because of inheritance.
This is what function overloads and C++ template specializations are
meant to achieve. Similar functionality could be implemented in Python
via pure Python mapping types, represented above by TypeActionMap.

If you want
reliable destruction it's better to set it up explicitly, using
"with".

That's true of the current language. I don't have enough experience
with "with" yet to know whether it's a realistic solution to the issue.
IMO, they are at least preferable to Java-style finally-clauses, but
probably not a replacement for C++-style RAII.