Emulating C++ coding style

William Tanksley wtanksle at dolphin.openprojects.net
Mon Apr 26 00:30:56 EDT 1999


On Fri, 23 Apr 1999 13:28:12 +0100, Alan Gauld wrote:
>> >2. stream class
>> >  e.g. cout << "hello python."<<endl;

>> VERY bad idea.  Bad even in C++.

>Why?

Very good question.  Okay, so I like hyperbole.  Thanks for calling me on
it ;-).  You're right.

>Its one of the 'improvements' over C that allows 
>overridding of the << operator so that you can 
>write a class to any stream. Python does similar 
>with the _str_ mechanism but that doesn't allow 
>chaining of types together, which I do like in C++

>so why is it a bad idea?

The reason I don't like it -- or why I didn't when I posted -- is that
it's a yukky overloading.  It makes a symbol mean something _entirely_
different from its usual meaning.

The reason I'm eating my words is that although it may be bad to _design_
an operator function which behaves so badly, it's not always bad to use an
already (badly) designed operator, so long as it's unambiguous.  And
whatever I might say about C++'s << operator, it's not ambiguous in
practice.

In other words, the designer(s) of C++ may have given the C++ world a bad
example with the << op, but they sure did a good job choosing which
operator to implement.

>Since its off-topic for the group respond by email 
>if you want...

Someone else asked, so I figger it's okay.

Plus, since Python 2.0 is in its early requirements-gathering phase, maybe
it wouldn't hurt to think about issues like this.

>> In proper C++, your const will be contained inside a class (probably
>> static) to keep it out of the global namespace.  

>Hopefully not. It should be contained within a C++ namespace.

Okay, I'll bite.  Why "hopefully not" a class?  I know namespaces are new
and cool, but classes seem to have done the job very well in the past.
Have they been secretly causing bloat in our code all along ;-)?

>Alan G.

-- 
-William "Billy" Tanksley
"But you shall not escape my iambics."
           -- Gaius Valerius Catullus




More information about the Python-list mailing list