On Sun, 29 Aug 2010 17:52:38 -0700, Paul Rubin wrote: >> That's a problem with the CPython API, not reference counting. The >> problem is that the CPython API is written at too low a level, beneath >> that at which the garbage collector exists, so naturally you have to >> manually manage memory. > > Care to give an example of a reference counted system that's written any > other way?
The complexity of the ref counter is invisible when writing pure Python code, and I believe it is also invisible when writing code in Cython. The difficulty of dealing with ref counts is abstracted away. The argument that "it will work if we always do this" means that it won't work is a nice quip, but it doesn't stand up. It's possible to defeat even Pascal compilers' type checking and do unsafe things by dropping down into assembly. So don't do it! It's not hard to not do something, although sometimes you might choose to do it anyway, because otherwise there is no way to get the code you need/want. But such code should be a rare exception. I'm not saying that ref counting systems can avoid incrementing and decrementing the ref counts. That would be silly. But I'm saying that it is an accident of implementation that writing C extensions requires you to manually manage the counts yourself. That's a side-effect of permitting coders to write C extensions in pure C, rather than in some intermediate language which handles the ref counts for you but otherwise compiles like C. If people cared enough, they could (probably) make the C compiler handle it for them, just as it currently handles incrementing and decrementing the return stack. There's nothing *fundamental* to the idea of ref counting that says that you must handle the counts manually -- it depends on how well insulated you are from the underlying machine. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
