Python handles globals badly.

Antoon Pardon antoon.pardon at rece.vub.ac.be
Fri Sep 11 09:28:23 CEST 2015


Op 10-09-15 om 16:21 schreef Michael Torrie:
> On 09/10/2015 01:27 AM, Antoon Pardon wrote:
>> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>>> In fairness to the C creators, I'm sure that nobody back in the early
>>> seventies imagined that malware and security vulnerabilities would be as
>>> widespread as they have become. But still, the fundamental decisions made
>>> by C are lousy. Assignment is an expression?
>> What is wrong with that?
> Makes for a common error of putting an assignment in a conditional
> expression like:
>
> if (a=4) this_is_always_true();

No it doesn't. You confuse a semantic characteristic with the
specifix syntax that was chosen to express it in C.

Should C have chosen '<-' as token for assignment, that error
would have been far less common.

The error is also facilitated because C doesn't have booleans
and so everything can be used as one. If C would have had
proper booleans and only allowed those as conditions in if
and while statements, most of those errors would have been
caught too, because the expression a=4 wouldn't produce a
boolean.

> GCC will give you a warning over that these days.  But many C
> programmers still adopt a notation of
>
> if (4 == a) do_something();
>
> to protect them if they accidentally leave out one =.  If assignment was
> not an expression, then the compiler would properly error out every time
> you used a solitary = in the conditional of an if statement.

A language can provide this kind of protection and still allow
assignment as an expression. A lousy syntactical choice, doesn't
invalidate a particular choice in semantics.

> Python strikes a good compromise.  You can chain = in an assignment
> statement, but you can't use them in a conditional expression.

Python could have chosen other options, like a different assignment
token, like providing a proper boolean type and expection such a type
in a condition context. It could reverse the assignment so that you
would have to write: expression = var, so that if someone accidently
writes if var = expression instead of if var == expression, that would
have been caught. It could combine some of these options.

Now you possibly don't like these possibilities, but they show there
are multiple syntactical possibilities that all allow for assignment
as expressions, and that are less vulnerable than C for a specific
kind of error.

-- 
Antoon Pardon



More information about the Python-list mailing list