[Python-Dev] Those import related syntax errors again...

Samuele Pedroni Samuele Pedroni <pedroni@inf.ethz.ch>
Wed, 21 Feb 2001 14:04:26 +0100 (MET)


Hi.

[As I imagined explicit syntax did not catch up and would require
lot of discussions.]

[GvR]
> > Another way is to use special rules
> > (similar to those for class defs), e.g. having
> > 
> > <frag>
> > y=3
> > def f():
> >   exec "y=2"
> >   def g():
> >    return y
> >   return g()
> > 
> > print f()
> > </frag>
> > 
> > # print 3.
> > 
> > Is that confusing for users? maybe they will more naturally expect 2
> > as outcome (given nested scopes).
> 
> This seems the best compromise to me.  It will lead to the least
> broken code, because this is the behavior that we had before nested
> scopes!  It is also quite easy to implement given the current
> implementation, I believe.
> 
> Maybe we could introduce a warning rather than an error for this
> situation though, because even if this behavior is clearly documented,
> it will still be confusing to some, so it is better if we outlaw it in
> some future version.
> 

Yes this can be easy to implement but more confusing situations can arise:

<frag>
y=3
def f():
 y=9
 exec "y=2"
 def g():
  return y
 return y,g()

print f()
</frag>

What should this print? the situation leads not to a canonical solution
as class def scopes.
or

<frag>
def f():
 from foo import *
 def g():
  return y
 return g()

print f()
</frag>

[Mark Hammond]
> > This probably won't be a very popular suggestion, but how about pulling
> > nested scopes (I assume they are at the root of the problem)
> > until this can be solved cleanly?
> 
> Agreed.  While I think nested scopes are kinda cool, I have lived without
> them, and really without missing them, for years.  At the moment the cure
> appears worse then the symptoms in at least a few cases.  If nothing else,
> it compromises the elegant simplicity of Python that drew me here in the
> first place!
> 
> Assuming that people really _do_ want this feature, IMO the bar should be
> raised so there are _zero_ backward compatibility issues.
I don't say anything about pulling nested scopes (I don't think my opinion
can change things in this respect)
but I should insist that without explicit syntax IMO raising the bar
has a too high impl cost (both performance and complexity) or creates
confusion.

[Andrew Kuchling]
> >Assuming that people really _do_ want this feature, IMO the bar should be
> >raised so there are _zero_ backward compatibility issues.
> 
> Even at the cost of additional implementation complexity?  At the cost
> of having to learn "scopes are nested, unless you do these two things
> in which case they're not"?
> 
> Let's not waffle.  If nested scopes are worth doing, they're worth
> breaking code.  Either leave exec and from..import illegal, or back
> out nested scopes, or think of some better solution, but let's not
> introduce complicated backward compatibility hacks.
IMO breaking code would be ok if we issue warnings today and implement
nested scopes issuing errors tomorrow. But this is simply a statement
about principles and raised impression.

IMO import * in an inner scope should end up being an error,
not sure about 'exec's.


We should hear Jeremy H. position and we will need a final BDFL statement.

regards, Samuele Pedroni.