constant in python?

[Bernd Nawothnig]

On Sun, 19 Aug 2001 21:00:34 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:

>>>> 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. [...]

I am in such a situation *g* I have to use Python together with PostgreSQL.
This is what i *have* to do but it would be stupid for me to see it as a
restriction in the negative sense. We are searching together for a suitable
framework and if one has an objection it is heard to i.e. nothing is
happening above our heads.

I don't want to start a religious war but i deeply believe that such policy
you have described above will lead into agony on long terms. It means the
death of every dynamic developement process which needs some freedom of
choice and the freedom of information. If you have this guaranteed it would
be easy for you to accept 'open' restrictions. Open because you can look
into the source code and hopefully understand the reasons for the
restrictions - or change it. Nothing is created for eternity :-)

The general goals in designing a new programming language should not mainly
be oriented to work in such unfree environments. 

This is my point of view but - as i said above - we should avoid a religious
flame war about open source. I'm new to this NG (and new to Python too) and
mainly interested in Python related things :-)

BTW: this all does _not_ mean that i'm deeply missing private and protected
in Python. 

> 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.  

Nobody is totally free and it is not necessary to have the freedom to choose
the framework by yourself but to have the possibility to change things you
can't live with. And there must be a good feeling in general. 

That's enough - for me :-)

> And the omniscience problem is then just shifted from the frameworks'
> designers to you 

In this special case: yes

> -- 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?  

Crying: "Shit!" - what else? *gg*

But seriously: First I will have to accept that something went wrong with my
ideas. And then i would try to redesign the whole thing avoiding as much
ugly quickhacks as possible. 

> You basically have the above choices plus (in theory) that of throwing
> everything you have away and recoding it all from scratch 

'mercilessly refactoring' was the keyword ... But it is a big difference
stucking deep into the problem and writing all from scratch knowing
basically nothing. At the point you described _many_ code fragments are
written in your head before you start. Not so if you are unexperienced. We
had this discussion a few days ago. One told me he had lost a floppy disc
with all his source code a few years ago (no back up - of course :-). He
needed months to write the code first but only days to do the work again.
And the second version was better than the lost one. 

Hmm, one should delete all of his source code some times :-)





Bernd