[Python-Dev] Visibility scope for "for/while/if" statements

[Alexander Myodov]

Hello Josiah,

>> i = 0
>> while i != 1:
>>     i += 1
>>     j = 5
>> print j
JC> Maybe you don't realize this, but C's while also 'leaks' internal
JC> variables...
JC> int i = 0, j;
JC> while (i != 1) {
JC>     i++;
JC>     j = 5;
JC> }
JC> printf("%i %i\n", i, j);
Yeah, it may *leak* it in your example. But the advantage is that it
may *not leak* as well:
for (int i = 0; i <= 5; i++) { int j = 5; }
printf ("%i\n", j); // Won't be even compiled

Or in our "while" case:
int i = 0;
while (i != 1) {
    i++;
    int j = 5;
}
printf("%i %i\n", i, j);

JC> If you haven't yet found a good use for such 'leakage', you should spend
JC> more time programming and less time talking; you would find (quite
JC> readily) that such 'leaking' is quite beneficial.
I see such usages and realize the possible gains from it. But for
about five years of software development in a bunch of programming
languages, I've found good uses of non-leaking variables *as well*. Up
to the level of manually "enclosing" the temporary variables used only
once:

...
int i = input();
int result;
{
    int j = f1(i);
    int k = f2(i, j);
    result = f3(i, j, k);
} // Now j and k are dead
...

>> accustomed from other languages. That's my sorrowful story.
JC> So you mistyped something.  I'm crying for you, really I am.
Yeah, I did. Just forgot removing the usage / renaming of variable neved
initialized (I thought) before. And my error was that I relied upon
the interpreter to catch it, mistakenly assuming the locality of
variables inside loops as a consistency with other common languages.
Mea culpa, without any jeers. The only reason why I was wrote my email
was to get the understanding of community assessment of such
behaviour, and/or probable workarounds. No blame against Python - it's
great even with this unusualty.

>> But for the "performance-oriented/human-friendliness" factor, Python
>> is anyway not a rival to C and similar lowlevellers. C has
>> pseudo-namespaces, though.
JC> C does not have pseudo-namespaces or variable encapsulation in for loops.
Neither
  for (int i = 0; i <= 5; i++) { int j = 5; }
  printf ("%i\n", i);
nor
  for (int i = 0; i <= 5; i++) { int j = 5; }
  printf ("%i\n", j);
gets compiled though with "gcc -std=c99". That is, each loop
introduces a new scoping level.

JC> Ah hah hah!  Look ladies and gentlemen, I caught myself a troll!  Python
JC> does not rival C in the performance/friendliness realm?  Who are you
JC> trying to kid?  There is a reason why high school teachers are teaching
JC> kids Python instead of Pascal, Java, etc., it's because it is easier to
JC> learn and use.
Ohh, my slip made me considered a troll... I meant only that Python
does not rival C in such area as "performance by all means, even with
decrease of friendliness" (but the overall performance is indeed good,
I've seen even the VoIP solution written purely on on Python). And I
believe noone of Python developers want it to be rival.

JC> What you are proposing both would reduce speed and
JC> usability, which suggests that it wasn't a good idea in the first place.
Yes, it lacks performance, but I still believe that an opportunity to close the
visibility of variables (*opportunity* rather than *behaviour
change*!) is better in terms of "friendliness" rather than lack of it.
Just because it offers the alternatives. Because C-style closed
visibility can emulate the variable lack, but not vice versa.
At least one voice here (of Gareth McCaughan) is not-strictly-against
it. So I cannot agree that such *option* can reduce usability.

>> "for (int i = 0; i < 10; i++)" works fine nowadays.
JC> I'm sorry, but you are wrong.  The C99 spec states that you must define
JC> the type of i before using it in the loop.  Maybe you are thinking of
JC> C++, which allows such things.
"gcc -std=c99" compiles the line "for (int i = 0; i <= 5; i++);"
perfectly. Along with another sample mentioned above   .
To this day, I relied upon gcc in terms of standards compatibility...

JC> Tes your ideas on comp.lang.python first, when more than a handful of
JC> people agree with you, come back.
Ok. Next time I shall be more careful. Sorry again, and thanks for
your time. And thanks for more-or-less patient answers.

-- 
With best regards,
 Alexander                          mailto:maa_public at sinn.ru