By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,383 Members | 2,063 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,383 IT Pros & Developers. It's quick & easy.

ownership problem?

P: n/a
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) |
\-----------------------------------------------------------------------/
Nov 22 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
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" ?
Nov 22 '05 #2

P: n/a
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" ?
Nov 22 '05 #3

P: n/a
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
Nov 22 '05 #4

P: n/a
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
Nov 22 '05 #5

P: n/a
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++?
Nov 22 '05 #6

P: n/a
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++?
Nov 22 '05 #7

P: n/a
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>

Nov 22 '05 #8

P: n/a
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>

Nov 22 '05 #9

P: n/a
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.
Nov 22 '05 #10

P: n/a
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.
Nov 22 '05 #11

P: n/a
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.

Nov 22 '05 #12

P: n/a
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.

Nov 22 '05 #13

P: n/a
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>

Nov 22 '05 #14

P: n/a
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>

Nov 22 '05 #15

P: n/a
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
Nov 22 '05 #16

P: n/a
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>

Nov 22 '05 #17

P: n/a
> 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) |
\-----------------------------------------------------------------------/
Nov 27 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.