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/
