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:
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
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.
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
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 (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() of the _expression_ to be provided, unless there is a format specified. When a format is specified it defaults to the 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. The semantics of name binding are described here. 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 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
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
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 —
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
|
