constant in python?

[Alex Martelli]

"Bernd Nawothnig" <Bernd.Nawothnig at t-online.de> wrote in message
news:slrn9nvq2n.3vvtj2j.Bernd.Nawothnig at Asterix.t-online.de...
    ...
> >> Hear, hear!  Designers aren't omniscient
>
> They are not omniscient but they should have visions. And accepting these
> visions and live and work with them (of course after choosing a suitable
> design first) seems to me being far more better than using brute force and
> quick hacks which only means: Only my point of view is right, nothing else
> and my first choice would be programming against any idea which is not
mine.

It seems you've never found yourself in a situation where you *have* to
use a given framework (e.g., MFC) because of corporate policy.

When using such a framework, you may find yourself unable to satisfy
some specs of the system because the framework authors did not provide
the needed 'hooks' in their design.  For example, some objects may be
generated inside the framework by directly instantiating a class of the
framework itself, rather than by a flexible factory-pattern that lets you
plug-in your own class for such objects.

If the language in use has allowed (indeed, encouraged) the framework
designers to cast in stone their defective design, your choices are:
    -- fork the framework (assuming you can get or reverse-engineer
        the sources) -- and commit to spending the next N years of your
        life retrofitting new framework releases to your fork, porting the
        forked framework to all architectures you must support, etc;
    -- resign from your job.

If the language just doesn't allow the framework designers to bind your
hands so tightly, you still have both of these choices if they appeal to
you.  You also have others, which *don't* mean "only my point of
view is right" -- they DO mean "I know this darned specific concrete
class they're instantiating cannot do the job I *HAVE* to do, so I'll
have them instantiate another instead" -- just as with a fork, but
without anywhere like as many hassles.

If you've always had free rein in choosing the frameworks you are to
work with, you're in a very unusual situation in this industry.  And
the omniscience problem is then just shifted from the frameworks'
designers to you -- once you have coded tens of thousands of lines
to that framework, which instantiates that particular concrete class
in such-and-such situation, what do you do when you THEN find out
that in release N+1 of your program you absoutely need _another_
class for those generated objects?  You basically have the above
choices plus (in theory) that of throwing everything you have away
and recoding it all from scratch (supposing you can find a different
framework that will meet your every need forever and ever... yeah,
right, not too bad, although I think that, as fables go, Rapunzel is
far more realistic -- she COULD have unusually strong hair...).


Alex