the demise of 'from foo import * and its implications?

Robin Becker robin at jessikat.fsnet.co.uk
Sat Mar 3 14:23:11 EST 2001


In article <2V8o6.1383$8q3.219969 at news1.rdc1.az.home.com>, Tim Hochberg
<tim.hochberg at ieee.org> writes
>
>"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
>
>[SNIP]
>
>> If we really want to improve visibility we could try to make
>>
>> >>> def bingo(a):
>> ...     if a<=1: return 0
>> ...     return bingo(a-1)*a
>> ...
>>
>> work naively, but I'm fairly sure this will be rejected as unpythonic or
>> somesuch.
>
>
>?????
>
>In what sense doesn't this work now? Under 2.0 or 1.5.2 or even, I think,
>under 0.9 this 'works' in the sense that it iterates for a while then
>returns 0. If one replaces "return 0" with "return 1" it even returns the
>factorial as I assume it should.
>
>What doesn't work is the following:
>
>def spam(n):
>   def fact(a):
>      if a <= 1: return 1
>      else: return fact(a-1)*a
>   return fact(n) + 42
>
>With the current three level scope rule this fails, so a function that works
>fine when defined at the top level fails miserably when defined at an
>intermediate level. Given your earlier statement that:
.....

you're right of course, this is what I meant. I haven't played with the
new statically scoped stuff, but I probably wrongly assumed that bingo
would remain invisible inside bingo.

>>my preference would be that statements legal in one context should be
>>legal in another where they make sense.
>
>This seems like it would be of concern to you as well.
>
>My understanding is we can have two of the following three options:
>
>1. Decent performance (~current performance)
>2. "Real" lexical scoping
>3. Unrestricted use of  "from X import *" at other than module scope.
>
>Given those choices I'd choose 1 and 2. Which is fortunate for me, since
>that's what were going to get anyway.
...

I don't really disagree. The optimisation is currently discardable in
favour of external language simplicity. The dynamic nature of python
bindings is somehow being more compromised with the new scope rule. I
hadn't really appreciated before now that python wishes to enforce a
fixed scope for references (for optimisation purposes) and that itself
seems to me to be wrong as it's more difficult as a concept than fixed
type. I get told about reference semantics and then find that these
pointers are somehow scope const.  Oh well :(

>Going off on a tangent: In listening to the various debates here, and when I
....
>
>If you've put up with my rambling to this point I congratulate you.
>
>Ramblin on,
>
>-tim
>
>
>
>
>
>
>
>
>.
>
>

-- 
Robin Becker



More information about the Python-list mailing list