On 28 April 2017 at 23:04, Erik <python@lucidity.plus.com> wrote:
See what I mean? Things get out of hand *very* fast.
I don't see how that's getting "out of hand". The proposal is nothing more complicated than a slightly-different spelling of assignment. It could be done today with a text-based preprocessor which converts the proposed form to an existing valid syntax. Therefore, if it's "out of hand" then so is the existing assignment syntax ;)
Well with your clarification, it's now clear to me that your proposal is for <obj> import <var1>, <var2> ... to be equivalent to _tmp = <obj> _tmp.var1 = var1 _tmp.var2 = var2 ... del _tmp Please correct me if I'm wrong here - but that's what I get from your comments. Note that the way I've described the proposal allows for an *expression* on the left of import - that's simply because I see no reason not to allow that (the whole "arbitrary restrictions" thing again). So based on the above, you're proposing reusing the import keyword for a series of attribute assignments, on the basis that the current meaning of import is to assign values to a number of attributes of the current namespace. However, that misses the fact that the main point of the current import statement is to do the *import* - the RHS is a list of module names. The assignment is just how we get access to the modules that have been imported. So by "reusing" the import keyword purely by analogy with the assignment part of the current semantics, you're ignoring the fundamental point of an import, which is to load a module. So based on your clarification, I'm now solidly against reusing the "import" keyword, on the basis that your proposed syntax doesn't import any modules. On the other hand, the construct you describe above of repeated attribute assignments is only really common in __init__ functions. It's similar to the sort of "implied target" proposals that have been raised before (based on the Pascal "with" statement and similar constructs): SOME_KEYWORD <obj>: .var1 = var1 .var2 = var2 Your construct is more limited in that it doesn't allow the RHS of the assignments to be anything other than a variable with the same name as the attribute (unless you extend it with "expr as var", which I can't recall if you included in your proposal), nor does it allow for statements other than assignments in the block. And the implied target proposal doesn't really avoid the verbosity that prompted your proposal. So while it's similar in principle, it may not actually help much in your case. So the reason I was saying things got "out of hand" was because the final version I got to had absolutely nothing to do with an import (in my view) - but on reflection, you're right it's no different than the self version. It's just that the self version also has nothing to do with an import! However, in the original context, it's easier to see "name injection into a namespace" as a common factor, and miss "importing a module" as the key point (at least it was easier for me to miss that - you may have seen that and been happy that your proposal was unrelated to modules even though it used the import keyword). I agree with Nick - the place we should be looking for improvements here is in trying to find abstractions for common patterns of class creation. Instead of looking at how to make the low-level mechanisms like __init__ easier to write, we should be concentrating on making it rare for people to *need* to use the low-level forms (while still leaving them present for specialised cases). Paul