> Since I wrote that commit: no one is saying it’s impossible or overly > difficult,
To be honest it is exactly what was being said. > just that the benefit of having it doesn’t justify the cost of adding it. I can understand that. > I understand that you think it’s worth the cost. No, I don’t think that. I wrote here to find that out. What I think is that it would be an elegant feature if it was implemented at python level. Thanks for reply, DG > On 24 Sep 2023, at 02:24, Eric V. Smith <e...@trueblade.com> wrote: > > > >> On Sep 23, 2023, at 5:37 PM, Dom Grigonis <dom.grigo...@gmail.com> wrote: >> >> 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> > Since I wrote that commit: no one is saying it’s impossible or overly > difficult, just that the benefit of having it doesn’t justify the cost of > adding it. Costs include implementation, testing, teaching, cognitive load on > all readers, etc. > > I understand that you think it’s worth the cost. Others, including me, do not. > > Eric > >> >> 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 >>> <mailto: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/
_______________________________________________ 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/L7RLIZQK2YR2JJBZM5MRNVNCMBYJFW7A/ Code of Conduct: http://python.org/psf/codeofconduct/
