Python handles globals badly.
steve at pearwood.info
Wed Sep 16 03:13:44 CEST 2015
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:
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"
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
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
More information about the Python-list