Copy constructors

[Guido van Rossum]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> I don't see how that would help -- maybe I'm being thick.  How would
> the uninitialized C instance automatically initialize itself at need?

For example, you could have a __getattr__ that initialized the thing
as soon as it is touched.

> Let me give a real-life example (it was not done in Python, but it would
> have been so much simpler if it had).

I see your reputation for being verbose is not a fable. ;-)

This pattern can be programmed in lots of ways -- changing class is
just one way, and not necessarily the best.

Note that Python's dynamicism also allows other solutions to be coded
more efficiently than in C++ -- e.g. coding a proxy in Python is a
breeze using dynamic method lookup.

> > I'd rather not because it's a complicated check to write, and it may
> > be difficult to explain the restrictions.  Here's an example of the
> > kind of restriction that is unavoidable.
> 
> Doesn't this fall into an "identity of slots" case?  If the __class__
> can be changed only when the slots of the old and new class
> are identical, isn't this decently easy to check and explain?

That's the check I meant.  The problem is that the info about which
slots are defined is spread all over the place, and some of it
(e.g. slots accessed only in C) is not available for introspection.

> > I'm not sure what that means, but if you could live with weak
> > references, we could easily add a way to change the referent of a weak
> > reference object.
> 
> Now THAT might help in my case -- the UI server would hand out
> to the AE *weak* references to the Dialogs, and change the
> referent when needed.  The only issue would seem to be the
> very fact that the reference is weak -- what is going to hold the
> dialog object[s] alive just as long as the AE has some reference[s]
> to that object and then garbage-collect them?  Maybe, as well as
> changing the weak reference's referent, we need a way to ask
> for a weak reference that isn't really weak -- one that DOES keep
> the referent alive -- but IS 'reseatable'.  If such not-really-weak
> references (plus maybe some indeed-weak ones) were all the
> extant references to the object, then 'becomes' could be
> implemented for that case, and I believe this might be OK
> for the cases I have in mind.

I imagine you could probably do this the way persistency is typically
done, but I haven't thought about it that much.

> Absolutely no objection to THIS: if a mechanism is provided, then
> having it be more explicit to afford greater performance in the
> normal case seems quite OK to me.  What I'm afraid of (regarding
> the change of __class__) is the risk of being left without ANY
> simple and workable mechanism for tasks that, while perhaps
> rare, are very important.

It was introduced in Python 1.5, and I never really missed it before
-- I just added it because I noticed it was easy to add.  I think it's
not even documented, or if it is (I couldn't find it) it's marked
experimental.  I still think there are other ways of accomplishing the
same effect, maybe using a proxy pattern.

> (Regarding the __dynamic__=1, as discussed on another post, I have a
> different issue, namely, what should the default be; it seems to me
> that builtins being immutable as a default, and only changed via
> explicit mechanisms, is a fine match for the patterns of normal
> code, but *classes* being immutable by default and needing explicit
> turning off of this optimization isn't quite as smooth).

A dynamic class will be slower than a static class, so I prefer having
to request this explicitly.  But we can certainly quibble about that!
I expect that the new facilities will be seriously user-tested only
after 2.2 is released, and experience will learn how often people are
changing class variables.

--Guido van Rossum (home page: http://www.python.org/~guido/)