ownership problem?

[Gabriel Zachmann]

Is it correct to say that the typical ownership problem, which frequently
arises in C++, does not occur normally in Python?

Best regards,
Gabriel.

--
/-----------------------------------------------------------------------\
| Any intelligent fool can make things bigger, more complex, |
| or more violent. It takes a touch of genius - and a lot of courage - |
| to move in the opposite direction. (Einstein) |
\-----------------------------------------------------------------------/

 

[Jeffrey Schwab]

Is it correct to say that the typical ownership problem, which
frequently arises in C++, does not occur normally in Python?

What "typical ownership problem" do you feel frequently arises in C++?
If you are referring to the sometimes difficult task of determining
which object owns a particular resource, why would it occur less in
Python than in C++?

 

[Ben Finney]

Is it correct to say that the typical ownership problem, which
frequently arises in C++, does not occur normally in Python?

Could you explain what you mean by "the typical ownership problem"?

 

[Fredrik Lundh]

What "typical ownership problem" do you feel frequently arises in C++?
If you are referring to the sometimes difficult task of determining
which object owns a particular resource, why would it occur less in
Python than in C++?

the problem isn't determining who owns it, the problem is determining
who's supposed to release it. that's not a very common problem in a
garbage-collected language...

</F>

 

[Bruno Desthuilliers]

Gabriel Zachmann a écrit :

Is it correct to say that the typical ownership problem, which
frequently arises in C++, does not occur normally in Python?

What is this "typical ownership problem" ?

 

[Jeffrey Schwab]

Jeffrey Schwab wrote:




the problem isn't determining who owns it, the problem is determining
who's supposed to release it. that's not a very common problem in a
garbage-collected language...

Yes it is. Memory is only one type of resource. There are still files
and sockets to close, pipes to flush, log messages to be printed, GDI
contexts to free, locks to release, etc. In C++, these things are
generally done by destructors, which are called automatically and
deterministically. I am not a Python Guru, but in Perl, Java, and other
languages that have built-in garbage collectors, these tasks have to be
done explicitly. I find that this forces a procedural approach, even in
an otherwise object-oriented program.

If you want something like automatic garbage collection in C++, I
recommend the use of Factories with destructors that release the
Factories' products. The zeitgeist in c.l.c++.moderated seems to prefer
the use of smart (reference-counted) pointers, which also rely on
destructors to release resources automatically. Plentry of free,
open-source implementations are available.

 

[elbertlev]

Yes!
Python uses auto garbage collection. As soon as the object reference
count becomes 0 it is removed from existence. So the problem typical
for C/C++: accessing pointers
to already deleted objects does not exist in Python.

 

[Fredrik Lundh]

Yes it is. Memory is only one type of resource.

Python's garbage collector deals with objects, not memory.

I am not a Python Guru

from the sound of it, you haven't written serious programs in any of the
languages you mention.

</F>

 

[Jeffrey Schwab]

Jeffrey Schwab wrote:




Python's garbage collector deals with objects, not memory.

But you don't want to spin and wait for the garbage collector to release
the object that happens to be holding a thread lock...

from the sound of it, you haven't written serious programs in any of the
languages you mention.

You would be wrong there.

 

[Fredrik Lundh]

But you don't want to spin and wait for the garbage collector to release
the object that happens to be holding a thread lock...

no, but arguing that sockets and thread locks are objects that suffer
from ownership problems is rather silly. if their use isn't localized to a
single function or a single manager object, your design is flawed.

</F>

 

[Jeffrey Schwab]

Jeffrey Schwab wrote:




no, but arguing that sockets and thread locks are objects that suffer
from ownership problems is rather silly.

Why? Are those resources somehow less important than memory?

if their use isn't localized to a
single function or a single manager object, your design is flawed.

!

I disagree. Suppose some code is written to work with any file-like
object. Now suppose a file-like object is passed in that represents
some URL. The first time the object is read, the object opens a
suitable network connection. When is it safe to close that connection?
The client code can't say, because it doesn't even know any network
connection has been opened. In a language with deterministic
destructors, the destructor can be relied on to close the connection as
soon as the object goes out of scope.

 

[Donn Cave]

Yes it is. Memory is only one type of resource. There are still files
and sockets to close, pipes to flush, log messages to be printed, GDI
contexts to free, locks to release, etc. In C++, these things are
generally done by destructors, which are called automatically and
deterministically. I am not a Python Guru, but in Perl, Java, and other
languages that have built-in garbage collectors, these tasks have to be
done explicitly. I find that this forces a procedural approach, even in
an otherwise object-oriented program.

If you want something like automatic garbage collection in C++, I
recommend the use of Factories with destructors that release the
Factories' products. The zeitgeist in c.l.c++.moderated seems to prefer
the use of smart (reference-counted) pointers, which also rely on
destructors to release resources automatically. Plentry of free,
open-source implementations are available.

You may be gratified to learn that Python's main storage model
is reference counted objects, and when an object falls out of
all referenced scopes its finalizers run immediately.

This is however true only of the C implementation. The Java
implementation naturally has Java's limitations in this matter,
so documentation generally avoids the issue. The C implementation
has been around for over a decade, wonder if it had any influence
on your C++ zeitgeist?

Donn Cave, (e-mail address removed)

 

[Jeffrey Schwab]

You may be gratified to learn that Python's main storage model
is reference counted objects, and when an object falls out of
all referenced scopes its finalizers run immediately.

Thanks, that's good to know! For some reason I had it in my head that
Python always used mark & sweep. I'm used to ref-counted collection in
Perl, but I never relied on it because of a nagging (probably
ill-founded) worry about cyclic references. Does Python have any way
around this? Is there a Python equivalent to C++ destructors?

This is however true only of the C implementation. The Java
implementation naturally has Java's limitations in this matter,
so documentation generally avoids the issue. The C implementation
has been around for over a decade, wonder if it had any influence
on your C++ zeitgeist?

Possibly. Python has really caught on with the C++ crowd in a way that
other languages never did. I'm not sure why; not that I don't love
Python, but there are other good, dynamic languages that haven't made
the same in-roads.

I think Java has had a big influence, too. People just don't seem to
want to be bothered with thinking about object life cycles at all. This
seems unfortunate to me, because cleanup still has to be done, so it
just ends up getting moved outside the objects where it belongs. I
think this hurts abstraction.

 

[Alex Martelli]

Thanks, that's good to know! For some reason I had it in my head that
Python always used mark & sweep. I'm used to ref-counted collection in
Perl, but I never relied on it because of a nagging (probably
ill-founded) worry about cyclic references. Does Python have any way
around this? Is there a Python equivalent to C++ destructors?

Python (main implementation, known as CPython) uses mark-and-sweep (with
generations &c) to deal with cyclic garbage -- but destructors (__del__
methods) *interfere* with cyclic garbage collection (there may be no
safe order of freeing a bunch of cyclic garbage when objects have
__del__ methods, and Python can't find it if there is, anyway).

I think Java has had a big influence, too. People just don't seem to
want to be bothered with thinking about object life cycles at all. This
seems unfortunate to me, because cleanup still has to be done, so it
just ends up getting moved outside the objects where it belongs. I
think this hurts abstraction.

Python 2.5 should introduce a 'with' statement that may go partways
towards meeting your qualms; it's an approved PEP, though I do not
recall its number offhand.


Alex

 

[Fredrik Lundh]

Python 2.5 should introduce a 'with' statement that may go partways
towards meeting your qualms; it's an approved PEP, though I do not
recall its number offhand.

http://www.python.org/peps/pep-0343.html

(this is one in a series of PEP:s based on the observation that the
generator machinery can be used for a lot more than iterators...)

</F>

 

[Gabriel Zachmann]

the problem isn't determining who owns it, the problem is determining

who's supposed to release it. that's not a very common problem in a

that's about what i meant.
i think, in c++, the "ownership problem" means the problem to determine who
and when is to delete an object, or to keep track thereof.
The object could be something as simple as a list element.

Best regards,
Gabriel.

--
/-----------------------------------------------------------------------\
| Any intelligent fool can make things bigger, more complex, |
| or more violent. It takes a touch of genius - and a lot of courage - |
| to move in the opposite direction. (Einstein) |
\-----------------------------------------------------------------------/