On Wed, Feb 28, 2018 at 5:53 PM, Gregory P. Smith <greg@krypto.org> wrote:
My first concern for this proposal is that it gives parenthesis a non-intuitive meaning. ()s used to be innocuous. A way to group things, make explicit the desired order of operations, and allow spanning across multiple lines.
With this proposal, ()s occasionally take on a new meaning to cause additional action to happen _outside_ of the ()s - an expression length name binding.
Does this parse?
print(fetch_the_comfy_chair(cardinal) as chair, "==", chair)
SyntaxError? My read of the proposal suggests that this would be required:
print((fetch_the_comfy_chair(cardinal) as chair), "==", chair)
But that sets off my "excess unnecessary parenthesis" radar as this is a new need it isn't trained for. I could retrain the radar...
Hmm, interesting point. The value to be captured DOES need to be grouped, though, and the influence of the assignment is "until end of statement", which is usually fairly clear. Parentheses do already have quite a number of meanings. For instance, a function call does more than simply group a subexpression - there's a lot of difference between x=(1, 2, 3) and x(1, 2, 3) even before you look at all the other syntaxes that can be used inside function calls (eg keyword arguments). The way I see it, this proposal is about the "as" keyword being used for local name binding, and the purpose of the parentheses is to group the name with the value being bound.
I see people try to cram too much functionality into one liners. By the time you need to refer to a side effect value more than once in a single statement... Just use multiple statements. It is more clear and easier to debug.
This concern comes up frequently, and there are definitely times when it's true. But there are also times when the opposite is true, and pushing more syntax into a single logical action makes code MORE readable. For instance, Python allows us to quickly zero out a bunch of variables all at once: a = b = c = d = e = 0 Can this be abused? Sure! But when it's used correctly, it is far MORE readable than laying everything out vertically: a = 0 b = 0 c = 0 d = 0 e = 0 Code is attempting to express abstract ideas. If your idea of "readable code" is "code that makes it easy to see the concrete actions being done", you're missing out on a lot of the power of Python.
We've got a whitespace delimited language. That is a feature. Lets keep it that way rather than adding a form of (non-curly) braces.
I don't fully understand you here. Python has always used symbols as delimiters, and I doubt anyone would want to do things any differently.
Practical examples from existing code that become clearly easier to understand afterwards instead of made the examples with one letter names may help.
Fair enough. I'll try to dig some up. The trouble is that practical examples are seldom as clear and simple as the shorter examples are. ChrisA