Copy constructors

[Michael Robin]

I think this is a good tradeoff.
I use Python becuase of its source availibility, clarity, and strong
run-time support. (And the possibility of using JPython in the
future.)
All IMHO, of course, but the two things that I don't like the extreme
dynamicism and (lack of) run-time speed. Yes, I can write a C
extension, but as fast as it is to code in Python, its all that much
faster if I don't have to.
I like to think that *most of the time* obj.attr gets a obj reference
from a slot (if possible) or a dict-like object (at worst), and that
obj.fn() does something more. I think counter examples should be made
explicit by something like __dynamic__=1. (I know that in this case
we're dealing with attr names - similar issue.) Personally, I like to
use an explict fn call syntax for *anything* that activates user-level
code for this reason.
Judicious use of __getattr__s and __call__s, et. al., can made code
pretty unreadable when x += 1 can potentially re-format your hard
drive.
In "mini-language building languages" such as Prolog and various
LISPs, this extreme dynamic nature is more expected, and they also
have the benefits of re-configurable parsers and extensive macro
capibilities, respectivily, so that your app-specific semantics also
have their own syntax, as apposed to "overloading" Python's. In the
future more meta-language (different than meta-classes which are *in*
the language) features may also be added to python.
Python (Mr. van Rossum, tell me if I'm wrong) was never billed as a
laguage construction kit, but a "get it done" language. (Insofaras
these features do help you "get it done", that's good - but there's
usually a more explict way to do things.) The fact that you may be
able to emulate Actor or CLOS/Loops/Flavors or Scheme/Dylan or
Smalltalk, etc., may be intersting, but was never garanteed. There is
a tradeoff between referential transparency/dynamicism and
understandable code. Another issue is the ability to translate to
other languages (including a C extension).

Anyhoo, this "power" isn't being taken away, just made explicit, which
seems in-line with Python's meta-goals from the start.

I understand that the reasons that people use languages is personal
and fluid - just my current 2 cents for this moment...

mike

Guido van Rossum <guido at python.org> wrote in message news:<mailman.997702822.11005.python-list at python.org>...
> [Christian Tanzer]
> > Would it be possible to possible to write a meta-class allowing the
> > dynamic change of __class__? And if so, how difficult would that be?
> 
> That would be possible if you're willing to write it in C.  It would
> be somewhat difficult if you wanted to make sure that abuse couldn't
> lead to core dumps, because you'd have to implement a hairy check
> (which I haven't figured out yet but which I believe is possible in
> principle) that determines whether the old and the new __class__ have
> compatible instance structure.
> 
> > I'd like to support the proposal of Glyph and Alex to make 0 the
> > default for `__dynamic__`. IMHO, optimization should be restricted to
> > those few modules where it is really necessary.
> 
> See my response earlier in this thread.
> 
> > Dynamicity is one of the really strong points of Python -- eye popping
> > as Glyph just called it.
> 
> Eye popping can be a negative point too.  I'd prefer a warning before
> my eyes are popped.
> 
> > > Understood.  Nevertheless, all evidence suggests that Twisted is not
> > > typical Python code. :-)
> > 
> > What is typical? I'd assume that a tiny percentage of Python code uses
> > the really dynamic features.
> 
> Tiny indeed.
> 
> > OTOH, this tiny percentage might itself be used by a lot of other
> > code. At least in my applications some modules do make use of some
> > eye-popping features and they tend to be used all over the place.
> 
> Because __dynamic__ is inherited, if you inherit from an eye-popping
> class, your class will automatically be eye-popping too.
> 
> > Please be careful in this crusade... The language you *wanted* to design
> > might have been not quite as
> > excellent/wonderful/<insert-your-favorite-exclamation-of-insane-
> > greatness-here> as the one you came up instead :-) 
> 
> Please trust me...  The changes I have in mind might not be so
> devastating for Python's beauty as you seem to be thinking. :-)
> 
> > I wouldn't mind if I had to ask for some dynamic features more
> > explicitly than now but I'd really be hard hit if they went away
> > entirely. I'd love to get better performance but not at the price of
> > loosing all this dynamicism. I if wanted to use a non-dynamic language
> > I'd know way too many candidates vying to make my life unhappy <0.1
> > wink>
> 
> Some people like Python for its extreme dynamicism.  But there are
> other languages in that niche (like Lisp).  Most people like Python
> because it's so darn readable and maintainable.  Unbridled dynamicism
> goes against that.  I am striving for a balance that allows most forms
> of dynamicism, but requires a declaration in advanced for the more
> extreme kinds.
> 
> > Separate explicit mechanisms would be much better than just dropping
> > dynamicism. In fact, despite the need for changing working code
> > <sigh>, making an external change of a module explicit would probably
> > be a good thing.
> 
> Exactly.  I'm not planning to drop dynamicism -- I'm planning to make
> it more explicit.
> 
> > Maybe module objects could even grow `get-set` magic in the process
> > <duck>.
> 
> You probably don't realize it, but you can write modules with get/set
> magic now, by stuffing an instance in sys.modules[__name__].
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)