Gred, thanks for your comments.
On Nov 26, 7:49 pm, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote:
>
> [...] Also, many of the uses of getattr in the std lib appear
> to be of the 3-argument form, which your suggested syntax
> doesn't cover. [...]
Good point. After excluding those, only ~435 uses would work for my
proposed syntax. Still seems fairly significant to me, though.
Also, please keep in mind that I never suggested that the get*r
functions should be removed from the language precisely because they
DO work in ways that my proposed syntax does not, and that removing
them would make a lot of existing code fail. For the purpose of the 3-
argument form, I would still prefer using getattr or even a
defaultdict depending on the task. (For the record, I disagree with
the 2-argument form of Ben's proposed syntax; that's confusing and
hard to read.)
As for your code, I haven't seen it, so it would be hard for me to say
exactly how the new syntax would come into play. What I can tell you,
however, is that the parts of your code that would use it would
probably be easier to read and change to anyone with a firm grasp of
the proposed syntax.
Quantity of code is definitely important, but I don't want to
underwrite the importance of quality, either. Even if only 30 lines of
code--rounding down--out of 40,000 would use it, those 40 lines would
probably be easier to read and understand. (Off-handedly, you might
also find that the availability of the new syntax makes new solutions
to some task obvious which previously were not, so the number could
rise.)
The discussion of PEP 363 presented some good examples of what I'm
talking about. Consider this code, which is a paraphrase of code that
appeared in the discussion:
setattr(obj, ("my_%s" % foo), getattr(obj, ("my_%s" % foo)) + 3)
That could be written much more readably as:
obj.$("my_%s" % foo) += 3
Or, if you don't like that exact syntax for it, why not any of these:
obj.?("my_%s" % foo) += 3
obj.${"my_%s" % foo} += 3
obj.?{"my_%s" % foo} += 3
obj.<"my_%s" % foo> += 3
(and so on)
Even if this sort of thing only needed to happen a few times in an
entire project, the project as a whole could only benefit from it. My
projects rely on a lot of metaclassing for the automatic generation of
properties and methods, which saves tremendous amounts of coding.
However, the code for the metaclasses is confusing because it relies
heavily on the getattr and setattr functions for accessing not only
the classes being created but also the instances of those classes. The
code for the metaclasses themselves only constitute a small percentage
of the overall code for the projects, but that doesn't mean the code
doesn't need to be easy to read and understand. Dynamic attribute
access via a syntactical construct would be very beneficial for me.
Back to PEP 3003, I understand the odds of getting the feature in
right now are slim. I get it. But that doesn't mean the idea of the
feature is a bad one. There are other things that can be done in the
mean time until the moratorium is lifted, like perfecting the syntax
and implementation details, or whatever.
--Brad Harms
--
http://mail.python.org/mailman/listinfo/python-list
