Ben North schrieb: > Apologies: I overlooked a couple of replies in my summary earlier. Tim > Delaney and Terry Reedy both responded in positive terms to the > one-argument form and its syntax, and in negative terms to the > two-argument form. > > Also, I missed the fact that Neil Toronto had made the same point as me > when he said: >> I'm not sure the "looks like a syntax error" argument holds much weight, >> because any new syntax is likely to be a syntax error until the syntax >> is changed. :)
IMO there's a difference between e.g. "with" and this new syntax. Looking at code that uses the "with" statement, one cannot think other than "ah, a new keyword, let's look what it means". Here, when someone comes across "obj.(name)" the situation is different. You also have to take into account that not all programmers know the language to the fullest extent, so it won't only be newbies who'll be confused and probably say "hey, that doesn't look right to me". > he also suggested: >> obj.*str_expression > > but I'm a bit uneasy about this, although the similarity with C's > dereferencing is in its favour. Also, '*' in python is already used for > "and the rest" arguments in function calls. Additionally, if you want to use a more complicated expression, you'll still have to put parentheses there. > Anthony Baxter cooled off a bit on the idea too: >> after thinking about it a bit, I'm still not convinced this is >> something that needs shorthand syntax > > Maybe not, but for the cases where you do want to do dynamic attribute > access, I think there is a win in readability from nested getattr and/or > setattr calls. As said in the "grit" argument, not necessarily. It's more easily overlooked that "getattr". > Georg Brandl: >> -1 here too. I fear that this gets too indistinguishable from normal >> calling syntax, > > I think, from the context, that this is "-1" on the syntax rather than > the idea as a whole, but I could have misread Georg's message. Possibly > a "-0" on the idea? A +0 on the idea, but as I wrote in that post, I doubt an ideal and Pythonic syntax can be found here. > Tim Delaney asked in particular: >> Have you checked if [the existing uses of getattr, where "getattr" in >> that scope is a function argument with default value the built-in >> "getattr"] are intended to bring the "getattr" name into local scope >> for fast lookup, or to force a binding to the builtin "gettattr" at >> compile time (two common (ab)uses of default arguments)? If they are, >> they would be better served by the new syntax. > > They're all in Lib/codecs.py, and are of the form: > > class StreamRecoder: > def __getattr__(self, name, > getattr=getattr): > > """ Inherit all other methods from the underlying stream. > """ > return getattr(self.stream, name) > > Without digging deeper into that code I'm afraid I can't say precisely > what is going on. Since that is a special method and ought to have the signature __getattr__(self, name), I think it's safe to assume that that's meant as an optimization. Georg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
