How much is set in stone?

[Jive Dadson]

Chris Barker wrote:
> 
> While nothing is actually set in stone, some things are pretty well
> cemented in.
> 
> Jive Dadson wrote:
> > Thanks.  Before I submit a formal proposal, let me run it by you guys.
> 
> That is a good idea, most PEPs start as a discussion here. AN a whle lot
> more start that way and nver make it to a PEP.
> 
> > I've looked through all the PEPS and I was surprised that my suggestion
> > is not already there.  So, here it is.  Please comment.
> 
> You can bet that this has been proposed by people new to Python again
> and again and again ...


What does that tell you?


> ... and I can promise you that this is one thing that
> is very well cemented in. If there is one thing that makes Python
> Python, is that it is a highly dynamic language. THat is not going to
> change.


You must have misunderstood what I wrote.  I'm not proposing anything
that would make it "lowly dynamic".


> 
> > option explicit
> >
> > def initialized = 0
> > def init_everything():
> >         blah()
> >         blah()
> >         blah()
> >         initialized = 1
> >
> > The above code would work as anticipated.  No pesky "global" qualifier.
> 
> Actually, no it wouldn't. The second initialized here is a local
> variable, and it should remain so. Having a variable in a function be
> either local or global depending on something that is outside of the
> funciton is asking for trouble. 


I didn't propose anything like that.  The compiler will know that
"initialized" is not local to init_everything because it is not declared
there with a "def".  That has absolutely nothing to do with anything
outside the function init_everything.


> If you start changing that too, you
> really won't have Python anymore!!
> 

The changes I've proposed do not conflict in any way with the
"Python-ness" of the language.  If you don't put "option explicit" at
the top of your module, it will behave exactly the same as it did
before.

What we are discussing is not uniquely "Python".  Other languages have
had the dubious feature that the first assignment to a variable is its
declaration. Invariably, people discover that it was a lousy idea.  The
people who USE it discover that.  They misspell a variable name and in
doing so they introduce a bug.  The bug may not manifest itself until
the code is already shipped.  Even if they do notice the bug before it's
too late, it may be very difficult to track down.  I've been down that
road a lot of times.

There's a pragmatic reason I'm asking for this feature.  One of our
customers has suggested that we implement scripting using Python.  I've
looked into Python, and I am very impressed with what I see.  But I
would have grave misgivings giving it to customers with variable
declarations the way they are now.  I'm not sure I could sell the boss
on it, and don't know if I would want to.  The situation is quite
different from writing code on ones own computer to be used in-house. 
These programs will run equipment, often in foreign countries, that can
break literally a million dollars worth of merchandise, and could even
hurt somebody.  It is very important to find bugs BEFORE a program goes
into production use.  I won't have any say over who writes these
programs, but bugs that appear to be compiler bugs ("Why doesn't that
variable change when I assign to it?") will get bounced right to me.

Of course, since the source code is freely available, I could implement
it on our copy only.  But that would be inefficient.  By your own
account, lots of other people want the feature also.

Jive