How much is set in stone?

[Roeland Rengelink]

Jive Dadson wrote:
> 
> 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?
> 

That people who are new to a language tend to perceive that language in
terms of languages they have used previously. The most common requests
for language additions by new users tend to fall in the "can't you add
this really nice feature from language X to Python" category.

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

Well, you use the term 'variable declaration' which for most of us
carries the connotation of both the definition of a name, and a
restriction of the type of values that can be assigned to it. aka static
typing. The request for some kind of static typing is quite common.
Reasons given are usually 'catching bugs (using the same arguments you
give)' or speed. Python, however, happens to be dynamically typed.
Most of us feel that the advantages of dynamic typing far outweigh the
disadvantages.

However, I gather from the rest of your post, that you just want the
name definition part of variable declaration, and not the type
definition part. Why don't you want static typing. It allows the
compiler to catch even more bugs?

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

Yes you did ;) 

Most local variables shadowing global names, are intended to be local.
Therefore, the only reasonable thing for your 'option explicit' to do,
would be to raise an Error with "undefined variable initialized in
init_everything". Because, assuming that for the simple reason that
there is a global with the same name that was defined properly, the
undefined local variable is the same as the global one, will usually be
_wrong_. Unfortunately the most likely fix someone would apply is to
write 'def initialized' at the beginning of the function, which,
although usually the right solution, in this case, is an error which
will go just as undetected as the missing global. 

By the way, the only reasonable idiom for this example would be:

initialized = 0
def init_everything()
    # global initialized <- forgotten
    if not initialized: # and therefore this will be an error
        blah()
        blah()
        blah()
        initialized = 1

And the compiler catches that just nicely. Also, I just grepped approx
10k lines of Python code and I couldn't find a single 'global' statement
in there.

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

Yet, there are thousands of people happily using a language (Python)
that does have that feature. I'm sure you don't wish to imply that they
don't really USE the language ;)

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

I think it would be reasonable to assume that either
- Those of us that USE Python really don't encounter this problem that
often, or
- Those of us that USE Python have found ways to deal with this problem
that work so well that a language change is just a very expensive
alternative

Have fun,

Roeland
-- 
r.b.rigilink at chello.nl

"Half of what I say is nonsense. Unfortunately I don't know which half"