121–130 of 558 posts
I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
Isn't that what C is?
I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
Earlier quoted context omitted.
Oh come on, it doesn't.
My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ? They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student…
There are already so many complicated semantics about mutability, iteration, bytes/strings, scoping, et al. And yet somehow a tiny piece of syntax that finally lets us stop writing "while true/break" is the big pain point?
Earlier quoted context omitted.
I see what you're saying, but I kinda like the gets ":=" operator.
But now there are two ways to do assignment. That's not very pythonic, is it?
a = 17
print("a=", a)
print("a=" + str(a))
print("a=%s" % a)
print("a={}".format(a))
print(f"a={a}")
# python 3.8 =>
print(f"{a=}")
But, if it sounds like I agree with you, I actually don't. I feel that the Zen of Python has taken on an almost religious level of veneration in people's minds, and leads to all sorts of unproductive debates. One person can latch onto "there should be one obvious way to do it" and another onto "practicality beats purity" and another onto "readability counts." Who's right? All can be. Or none. All could be applied to this particular case.
The Zen of Python is just a set of rough heuristics, and no heuristic or principle in the field of software development applies 100% of the time, IMHO. <= except for this one ;)
Walrus operator looks like a great addition, not too much syntax sugar for a common pattern. Why were folks arguing about it?
I don't know how you read it - 'if x is assigned the value y'? Most other things in Python can just be read out loud.
Earlier quoted context omitted.
You could read "if x := y()" as "if x gets a truthy value from y()." For what it's worth, "x = y()" is one of the harder things for new programmers to translate to English in the first place -- it reads most naturally as "x equals y," but leads to better intuitions as "x gets the value of y". I think that's what makes this clunky to verbalize, rather than the "if truthy" bit.
So := is 'gets a truthy value from'? That seems to work. > For what it's worth, "x = y()" is one of the harder things for new programmers to translate to English in the first place Right... so why have we added more complexity to something known to be very complicated?
Earlier quoted context omitted.
Disagree. In my experience (albeit, not very long, been writing Python since 2007 or so), assigning to a value and checking for truthiness is a very common pattern.
Very common pattern, confusing nonetheless. It does two different things at once where traditionally Python is explicit and only does one thing at once.
Earlier quoted context omitted.
You could read "if x := y()" as "if x gets a truthy value from y()." For what it's worth, "x = y()" is one of the harder things for new programmers to translate to English in the first place -- it reads most naturally as "x equals y," but leads to better intuitions as "x gets the value of y". I think that's what makes this clunky to verbalize, rather than the "if truthy" bit.
So := is 'gets a truthy value from'? That seems to work. > For what it's worth, "x = y()" is one of the harder things for new programmers to translate to English in the first place Right... so why have we added more complexity to something known to be very complicated?