I agree that cleaning up is not really needed.
I think the problem is that people feel bad about having to type things twice and immediately think "It's violating DRY". And some are quite adamant about not violating DRY.
Fact of the matter: on nearly all relevant scales, this "DRY violation" does not matter, in fact, I would not even want to call it a violation. DRY is about having 1 representative location for knowledge. The name of a variable (1) hardly counts as knowledge and (2) is also used at other locations (use-sites).
Is repeating the variable name that much of a deal? Granted, I mostly only use namedtuple of all the given examples. And I use that sparingly. Are `TypeVar` and `Symbol` used more often?
At least for namedtuple, we could do some meta-classy logic to allow for
class Point(namedtuple): _fields = ('x', 'y')
And for namedtuple it makes sense. For TypeVar it might too?
class T(TypeVar): pass
Symbol? Not so much, I think.
I'm not eager to see "improvements" in this area, as I do not see it as a problem, except for those with an overly strict view on DRY. Any new syntax/semantics for this would need to bring a real obvious improvement for the general case, and I doubt that will happen.
The one suggestion I have heard that remotely makes sense (and it was not even in this thread!) is the concept of decorators for variables
@Something x = 5
x = Something('x', 5)
And even that idea is bad: what if you want multiple arguments? Would you need a tuple? What if you don't need any arguments? (e.g. Symbol).
After seeing all the suggestions so far, I'm not convinced by any of them that they are an improvement. So unless there's a suggestion for syntax/semantics that is reasonable to become the only **obvious** way to do it, I'd say nay.
On 1 Jun 2016, at 02:52, Michael Selik email@example.com wrote:
On Mon, May 30, 2016 at 11:08 PM Steven D'Aprano firstname.lastname@example.org wrote: On Mon, May 30, 2016 at 06:16:26PM -0700, Guido van Rossum wrote:
T = TypeVar('T') x = Symbol('x')
I'm sure this is not a new idea, but so far I've always thought that this is pretty esoteric and the approach here is good enough.
This comes up a lot and it would be nice to clean it up.
T = type('T', bases, ns) Record = namedtuple('Record', fields)
I'm not enthusiastic about cleaning it up. It feels appropriately awkward. I don't want my colleagues having too easy a time dynamically creating types or functions.
You brought up decorators as an example, but I think that was more about how decorators tend to be used essentially as part of the function definition. They might dramatically alter the behavior of the function and yet appear as an afterthought without the decorator syntax. From the PEP 318, "This becomes less readable with longer [functions]". The motivation said nothing about avoiding typing the function name twice. _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Sjoerd Job Postmus wrote:
I would not even want to call it a violation. DRY is about having 1 representative location for knowledge. The name of a variable (1) hardly counts as knowledge and (2) is also used at other locations (use-sites).
I don't know whether it meets the strict definition of DRY or not, but the reason it's annoying is that it's a repitition that doesn't convey any information.
Using a variable name in multiple places tells you something: "this thing here refers to that thing defined over there". But having the variable name in two places in the *definition* tells you nothing.