> the output will have the expression text
This is exactly what I want. If there was an extra check for validity at parser 
level, it is a plus.

> You want to produce a name, that is an identifier 
> <https://docs.python.org/3/reference/lexical_analysis.html#identifiers>. 
Not necessarily, I want the first part of f’{expr=}’.
There are outputs:
a) `expr=repr(expr)`
b) `repr(expr)`

why is it a bad idea to have:
c) `expr` without `repr(expr)`?

This does cover `identifier only` case as well, but is not limited to it.

Is it difficult to achieve? Apologies if I am missing something, but if you 
know the workings of python, could you point me to where f’{expr=}' is parsed 
and compiled?

Obviously I might be wrong, but it is difficult to believe that it is done in 
such way, that I can have B, A&B, but not A without B. Would appreciate if you 
convinced me with some support for your rather strong statements.

Regards,
DG

> On 23 Sep 2023, at 23:18, Tiago Illipronti Girardi <tiagoigira...@gmail.com> 
> wrote:
> 
> I think I did something wrong and we are responding to one another instead of 
> the list, please correct this if you can.
> 
> Let's start with `f'{name=}'`. This is from the docs 
> <https://docs.python.org/3/reference/lexical_analysis.html#f-strings> (the 
> link has the docs for f-strings, so read it):
> 
> When the equal sign '=' is provided, the output will have the expression 
> text, the '=' and the evaluated value. Spaces after the opening brace '{', 
> within the expression and after the '=' are all retained in the output. By 
> default, the '=' causes the repr() 
> <https://docs.python.org/3/library/functions.html#repr> of the expression to 
> be provided, unless there is a format specified. When a format is specified 
> it defaults to the str() 
> <https://docs.python.org/3/library/stdtypes.html#str> of the expression 
> unless a conversion '!r' is declared.
> 
> That's not what you want. You want to produce a name, that is an identifier 
> <https://docs.python.org/3/reference/lexical_analysis.html#identifiers>. The 
> semantics of name binding are described here 
> <https://docs.python.org/3/reference/executionmodel.html#naming-and-binding>. 
> Which means that you cannot infer the name from the value.
> Python only deals with values, not names. The names are how you refer to the 
> values. That is the semantics. There's no inverse transformation embedded in 
> the language. That's what everyone is trying to communicate to you.
> If you pay close attention to the execution model 
> <https://docs.python.org/3/reference/executionmodel.html#naming-and-binding> 
> there is a link from the name to the object but not the other way around, so 
> you can't get it from the object. That's it. You need to change the whole 
> execution model (that is the interpreter) to get what you  want
> 
> Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis <dom.grigo...@gmail.com 
> <mailto:dom.grigo...@gmail.com>> escreveu:
> 
> 
>> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi <tiagoigira...@gmail.com 
>> <mailto:tiagoigira...@gmail.com>> wrote:
>> 
>> The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, 
>> with `str` if it is `s`, or with `ascii` if its `a`.
>> With a new format `id` or `i` it would do nothing, but it could signal to an 
>> editor that it is an identifier (editors, I believe, already parse the 
>> contents of the curly brackets on f-strings).
> I know the formatting syntax, I wasn’t clear what your point was. I see now 
> that you are referring to new syntax which does nothing apart from signalling 
> the editor.
> 
> Your suggestion is leaning towards python adapting to the editor, while I 
> would argue that things are simpler and more robust if editors treat code 
> expression as code expression and strings as strings. Making a mess here does 
> seem like too big of a cost for not so profound benefits of what I am 
> proposing.
> 
>> Identifiers are syntactical constructs in python, they only have semantics 
>> given a context, and more than one identifier can have the same semantic 
>> meaning in a given context, which makes your proposal a no-go from start.
> Can you elaborate on this?
> 
> Given f’{expr=}’ syntax already exists, how is this an issue for my proposal?
> 
>> Except if we were to change the whole execution model of the language.
> Although I am open to be proven wrong. Could you give an explanation why 
> stripping `repr(expr)` part from f’{expr=}’ and leaving expr literal is 
> problematic, given substituting expr literal is already being done?
> 
> 
>> However, for the "change this identifier from this to that" case (which is 
>> an editor problem), subclassing `typing.LiteralString` would basically solve 
>> the problem:
>> 
>> ```
>> x = 6
>> print(typing.Id('x') = f'{x}')
>> ```
>> 
>> Or import Id from typing to save some keystrokes.
>> 
>> With an interpreter change to the f-string we could do something like:
>> 
>> ```
>> print(f'In this context {x!id} means the horizontal coordinate')
>> ```
>> 
>> or without one and just changing the typing module:
>> 
>> ```
>> print('In this context', typing.Id('x'), 'means the horizontal coordinate')
>> ```
> I get all of the above, it just doesn’t seem elegant solution to a much more 
> simpler approach that I am proposing. From my individual POV, the extra 
> complication cost of your approach pretty much outweighs the subtle benefits 
> of my proposal.
> 
>> And with editor support, changing `x` to `y` would cleanly change the 
>> references to the variables/identifiers.
>> But this use case is essentially impossible for the interpreter alone to 
>> solve: it needs editor support.
> (above)
> 
>> The other cases that you cite are kinda nonsensical (as I already wrote 
>> above).
> No, you have just stated this (at least in this manner) for the first time. 
> Care to explain how keeping dictionary keys in sync with identifiers or 
> having extra syntactic via f-string construction check is “nonsensical”? I 
> agree that these might not be the top practices, but given python is often 
> used as a plugin / prototyping language, I would argue that some things are 
> just plainly useful in certain cases. Python already allows many practices 
> that are discouraged. This one would definitely be on a lower end of such 
> risks.
> 
>> Hope I was clear, and best regards
>> 
>> Tiago I Girardi
>> 
>> 
>> Em sáb., 23 de set. de 2023 às 10:53, Dom Grigonis <dom.grigo...@gmail.com 
>> <mailto:dom.grigo...@gmail.com>> escreveu:
>> 
>>> On 23 Sep 2023, at 16:24, Tiago Illipronti Girardi <tiagoigira...@gmail.com 
>>> <mailto: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/CWEHXEBO64I6OBQOOJXMG4DH7CTMPOR6/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to