> On 23 Sep 2023, at 16:24, Tiago Illipronti Girardi <tiagoigira...@gmail.com>
> wrote:
>
> but:
> 1. There are costs doing it in python. And easy implementation doing it in
> editor (with the typing support it's almost already done).
What are those costs?
> 2. The f-string functionality is not there right now, but f'{name!id}' would
> leverage what is there and, with editor support, give the exact `nameof``
> support even without further interpret support.
What do you mean by f’{name!id}’ ? I don’t understand your point here.
Are you proposing f’{name!id}’ syntax for it? My whole point is to do this in
f-strings.
Namely my proposal is f’{=expr}’.
`nameof` function is out of the question - it has no benefits over f-string
implementation.
> The other use cases you mention are easily dealt with, assuming editor and
> typing.LiteralString (subclassed) support.
Can you elaborate? I have only basic user knowledge about typing library and
use it sparsely.
But from what I know, tying this to typing does not seem like a good idea. It
is very basic functionality and from my POV stands at lower level, while typing
is optional feature and not everyone uses it or even needs to know it.
DG
—Evaluation of deferred evaluation can be deferred, but not indefinitely —
> Em sáb., 23 de set. de 2023 às 09:51, Dom Grigonis <dom.grigo...@gmail.com
> <mailto:dom.grigo...@gmail.com>> escreveu:
>> This is the only use case I can think of.
> Yes, probably most common one, but I have mentioned couple more.
>
> 1. Keeping dictionary keys in sync with variable name.
> 2. eval / exec statements. Although eval / exec are not recommended in high
> standard production code, python is widely used in plugins for various apps.
> E.g. Alfred / Sublime text, where exec/eval can be very useful. Why not have
> a method to do it a bit more robustly?
>
> Given python being flexible multipurpose interpreted language, I am sure more
> use cases would surface.
>
>> Couldn’t we just subclass typing.LiteralString to typing.Id or something for
>> this “functionality” and let editing tools deal with it.
>
> “Could”, but:
> 1. There are benefits doing it in python. And undesired costs of implementing
> this in editor (see my later e-mails)
> 2. The f-string functionality for it is already there:
> f'{a=}'.rstrip(f'{a}')
> # or a bit better
> f'{a=}'.split('=')[0]
> # = exactly what I am proposing (Except the unneeded evaluation part)
> So if it is already there, why not have it done well given there is little to
> none overall cost to it? I think cost implementing such things in Editor is
> much greater.
>
> Regards,
> DG
_______________________________________________
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/TKB3EVGGSXRBZQ5EXKRX5GCW5NPRVB4B/
Code of Conduct: http://python.org/psf/codeofconduct/
