> 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/
