The support for the including the feature at all is still not unanimous. Perhaps the way forward is to try to reach consensus on the favourite (or least-unfavourite) syntax, and I'll revise the PEP and sample implementation.
I think the "obj.[attr_name]" syntax has the most support. To stop this going round in circles for ages, then, I will take this as the winner. I'll mention the other contenders in the PEP, including the new "visually distinctive" suggestions [EMAIL PROTECTED] obj.[[foo]] and the "wrapper class" idea of Nick Coghlan: attrview(obj)[foo] (I personally think the "attrview" idea results in slightly cluttered-looking code, and prefer the visual simplicity of "obj.[foo]".) One of the new opinions against the feature at all was Steve Holden's: > This seems to me to take Python further away from the "Computer > Programming for Everyone" arena and closer to the "Systems Programming > for Clever Individuals" camp. I don't agree. People who find it clearer to write x = getattr(obj, attr_name) can continue to do so. Now, of course, a person with such a preference has no control over what other people write, so everybody will have to understand what the new syntax means, but I think it's quite mnemonic. It's a combination of the "." attribute look-up and the "[]" dictionary look-up. Steve, further down his message, continues: > It threatens to reduce Python's readability substantially I find obj.[attr_name] = other_obj.[attr_name] a much clearer expression of the "assignment" intent of this statement than setattr(obj, attr_name, getattr(other_obj, attr_name)) in the same way that I find my_dict[new_key] = new_value clearer than a hypothetical setvalue(my_dict, new_key, new_value) would be. Opinion is divided on whether it's a readability win, but I think it *is* a win. (Well, I would, I suppose). My experience in Matlab was that code became much more readable when they introduced "dynamic fields", especially in code which sets "fields" in one variable from "fields" in others. I don't know whether others on this list have worked in Matlab and have any opinions from their experience. Turning now to the performance question, Steve also writes: > > Is 1% "too much" for this feature? > > Yes. I believe it would decrease the sum total of Python's efficiency > for a very marginal return in performance on a very marginal feature. The performance question is important, certainly. Initial reaction on python-ideas was that a 1% cost would not count as substantial, but of course quicker would be better, and there were a couple of suggestions as to how the implementation could be improved. I agree that "readability is more important than efficiency", and I think a 1% efficiency loss would be "small" compared to what I think is a readability win, especially in cases like the example above. Thanks very much for all the interest in this idea. I think I've got enough of a sense of the list's reaction to update the PEP, and will do so over the next couple of days. I'll then re-post it so that everyone can check I haven't misrepresented their opinion, and take it from there. Ben. _______________________________________________ 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
