Isaac Morland added the comment: First, another note I would like to point out: this is much nicer to write within namedtuple than as a wrapper function because it is trivial to use the existing rename logic when needed, as seen in the diff I provided. I suppose I could write a wrapper which calls namedtuple and then changes the class name after creation but that just feels icky. The only other alternatives would be to duplicate the rename logic or have the wrapper not work with rename.
By way of response to R. David Murray: Every use case, of everything, is specialized. Another way of thinking of what I'm suggesting is that I would like to make providing a typename optional, and have the library do its best based on the other information provided in the call to namedtuple. This pretty well has to mean mashing the fieldnames together in some way because no other information about the contents of the namedtuple is provided. So I think this is a very natural feature: what else could it possibly mean to pass None for the typename? If for a particular application some other more meaningful auto-generated name is needed, that could still be provided to namedtuple(). For example, an ORM that uses the underlying table name. In response to other suggestions, I don't see how one can prefer "_" all over the place in debugging output to a string that identifies the fieldnames involved. Or really, just the option of having a string that identifies the fieldnames: I'm not forcing anyone to stop passing '_'. To INADA Naoki: thanks for pointing that out. I agree that in the subclass case it no longer matters what typename is used for the namedtuple itself. But isn't that a good reason to allow skipping the parameter, or (since you can't just skip positional parameters) passing an explicit None? On 1 August 2017 at 11:02, R. David Murray <rep...@bugs.python.org> wrote: > > R. David Murray added the comment: > > I think the "vaguely" pretty much says it, and you are the at least the > first person who has *requested* it :) > > This is one of those cost-versus-benefit calculations. It is a > specialized use case, and in other specialized use cases the "automatically > generated" name that makes the most sense is likely to be something > different than an amalgamation of the field names. > > So I vote -0.5. I don't think even the small complication of the existing > code is worth it, but I'm not strongly opposed. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue31085> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31085> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
