Python handles globals badly.

[Steven D'Aprano]

On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:

> Op 12-09-15 om 05:48 schreef Steven D'Aprano:
>> I believe I already acknowledged that assignment-as-expression was fine
>> if it avoided the = versus == error, from the perspective of avoiding
>> errors. But from the perspective of a clean and logical programming
>> model, perhaps not so much. Assignment is imperative, not functional, and
>> requiring it to return a result is somewhat unclean.
> 
> I thought practicallity beats purity? AFAICS python doesn't use such a
> clean and logical programming model and it isn't given much critique over
> it. So I don't think it is fair to critique assignment as an expression
> because of this aspect.

Python is a remarkably clean and consistent language. There's only one kind
of value (the object -- everything is an object, even classes are objects).
The syntax isn't full of special cases. For example, there's nothing like
this horror from Ruby:

#!/usr/bin/ruby
def a(x=4)
    x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"


which prints:

7
7
7
3

This is not a bug in the language (well, yes it is, it's a design bug), but
it is a consequence of the syntax.

Python has nothing like this. Python's syntax is quite clean and consistent.


[...]
> But we are not talking about all commands, we are just talking about
> assignments. Sure an assignment has a side effect. But so has ls.pop(). So
> something having a side-effect and a value is not unheard of even within a
> python context.

Sure, I already said that some commands might return a value.

But assignment? Assignment is a pure command. There's nothing to return.
Having `x = 23` return 23 is, well, weird. If we start from the premise
that a return result is generated from a *calculation* or a *query*, we
have to ask what is being calculated or asked? 

I'm not quite willing to say that assignment-as-expression is an error,
because I acknowledge that it could be useful in some places. But it seems
bolted on and arbitrary, like having del return the name you just unbound:

assert (del x) == 'x'

And one other reason why I dislike it: it makes for a verbose and messy
interactive experience. Take Ruby:

irb(main):001:0> a = 23
=> 23


I don't need to see 23 printed, because I already know what the value is, so
that takes two lines where one would do. (On the rare case I did want to
see the value of something I had just assigned to, I could just print the
expression.)


-- 
Steven