If it is done at a tool level, it is not a robust solution. The fact that it can be done in a tool doesn’t mean that it is the optimal solution. Having it done at python level could be a simpler solution and provide benefits to all of the tools, without needing for editor logic to deviate from python logic. Also, it eliminates inconsistencies and coding styles which would arise if each editor was to implement its own method.
Besides, editor tool implementation doesn’t offer all of the benefits, which on top of the refactoring benefits offer: a) validity check in both f-strings and nameof(). b) nameof(‘a.b’) = ‘b’, which is not a straight forward equality. Regarding f-strings. I think the fact that it is already being done in python justifies its validity: a = 1 print(f'{a=}') and everybody is happy using it instead of: print(f'a={a}') If the argument that this sort of thing should be done in editor is deemed to be a valid one, then the `f’{expr=}’` expression was a mistake. However, the way I see it, it is very useful addition and I do use it a fair bit. What I am proposing is nothing new, but rather a small part of what is already there, arguably bringing it closer to modular completeness: print(f'{a}') print(f'{a=}') print(f'{=a}') It’s the same as “I can draw square, square and circle, but I cant draw a circle without a square”. It seems like a non-invasive addition, not causing any problems, not cluttering namespaces and how I see it, has just the right place for it and its syntax space is very unlikely to be used for anything else. I do not see a big cost in either implementation or maintenance. The question is whether benefits justify that cost. DG > On 16 Sep 2023, at 18:37, Bruce Leban <br...@leban.us> wrote: > > If the goal is to create a syntax that allows tools to recognize names in > strings, there is a simple solution which requires tool changes only, for > example: > > raise Exception('The field ' + ((('size'))) + ' must be a positive integer in > ' + ((('Sample.widget')))) > > Python already treats triple parenthesized strings properly and all you need > to do is modify tools to recognize that syntax. It's even backwards > compatible, visually striking, and doesn't prevent compile-time string > folding. > > --- Bruce > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/OXEOPXY7BCFB4P7XKEAM3UN5XU6RIHJP/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TRRMMUCYRJVAORM4RFDJFXGKP53ZVQ47/ Code of Conduct: http://python.org/psf/codeofconduct/