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/
