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) |
\-----------------------------------------------------------------------/

[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" ?

[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" ?

[Ben Finney]

Gabriel Zachmann <za**@in.tu-clausthal.de> wrote:

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

--
\ "Jealousy: The theory that some other fellow has just as little |
`\ taste." -- Henry L. Mencken |
_o__) |
Ben Finney

[Ben Finney]

Gabriel Zachmann <za**@in.tu-clausthal.de> wrote:

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

--
\ "Jealousy: The theory that some other fellow has just as little |
`\ taste." -- Henry L. Mencken |
_o__) |
Ben Finney

[Jeffrey Schwab]

Gabriel Zachmann wrote:

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

[Jeffrey Schwab]

Gabriel Zachmann wrote:

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

[Fredrik Lundh]

Jeffrey Schwab wrote:

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

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>

[Fredrik Lundh]

Jeffrey Schwab wrote:

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

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>

[Jeffrey Schwab]

Fredrik Lundh wrote:

Jeffrey Schwab wrote:

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

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.

[Jeffrey Schwab]

Fredrik Lundh wrote:

Jeffrey Schwab wrote:

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

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.

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

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.

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>

[Fredrik Lundh]

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.

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>

[Alex Martelli]

Jeffrey Schwab <je**@schwabcenter.com> wrote:
...

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?

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]

Alex Martelli wrote:

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) |
\-----------------------------------------------------------------------/