It seems that my guess was correct. There was a commit, when only the first 
part was working:

https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381a
 
<https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381a>

So it does seem that it can be done manageably, while all editors with f-string 
support would benefit instantaneously without extra effort or unnecessary 
complications such as `typing` library.

Regards,
DG

> On 23 Sep 2023, at 23:55, Dom Grigonis <dom.grigo...@gmail.com> wrote:
> 
>> 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 
>> <mailto: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/M4V4XKEQ3Z4TLGQ3DQTS465YZ3PQOW6H/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to