> 'Esoteric' means something hidden, it is the exact opposite of 'we all know
> about'
What I meant is that functions in __builtins__ are low level, with
functionality which is hidden from the user. So my point is that it seems like
an appropriate place for nameof(). After all, f’{v!<fmt>}’ applies functions to
v from builtin namespace: str/repr/ascii.
> Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis <[email protected]
> <mailto:[email protected]>> escreveu:
>
>
>> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> There definitely is a miscommunication:
>>
>> The 2 first options was me spitballing an alternative against the third.
>>
>> The not reinventing the wheel remark was me saying that the particular
>> example that you gave *on that particular message* can already be done.
> I know, I just applied your advice in a different place. :)
>
>> Also the case 2 f'{name!i}', I suggested as an extension of the current
>> formatting paradigm, but is also the same as `f{name=}` except that you
>> don't format the *value*,
>> so I *imagine* (that word pulling more weight than I do at the gym, mind
>> you) would be trivial to implement. It *needs* editor support regardless.
> So just to double check. You think f’{name!i}’ would be better than simply
> nameof() builtin?
>
> I have no problems with either b) or c), but I like c) better. As you said:
> print('In this context, variable', 'name', 'means an esoteric thing that we
> all know about’)
>
> Maybe it would be sensible not to couple ‘esoteric` thing with non-esoteric
> ones and find its place among other unique functionality providing things,
> such as id, type, exec, etc.
>
>
>> While I would be very glad if my opinion is adopted by the community, do not
>> substitute my opinion for the community's.
>>
>> Em dom., 24 de set. de 2023 às 12:29, Dom Grigonis <[email protected]
>> <mailto:[email protected]>> escreveu:
>> I think the separation is needed between the 2:
>>
>> a) identifier name
>> b) expression text
>>
>> I think there is a mix-up between these 2 which causes some confusion (at
>> least to me). Wanting both made me cling to f-strings as they currently do
>> b) in ‘postfix=' and a) can be extracted from it.
>>
>> —————
>>
>> I think having b) will be convenient to extract given/when/if/please
>> deferred evaluation is implemented:
>> a = `expr`
>> print(a.__expr_text__) # ‘expr'
>> —————
>>
>> So I think the focus here is a). I think this is what you are having in
>> mind, while I think about both - thus slight miscommunication.
>>
>> And for it I currently see 3 options:
>> 1. typing.ID['name']
>> I think this one is too verbose for what it is. Also requiring an import
>> 2. ‘{name!i}’
>> This one is sensible (and I think is better than my prefix=)
>> 3. nameof(name)
>> But I am leaning towards this one.
>> Pros:
>> * it is not coupled with either string formatting or typing.
>> * C# guys most likely gave some thought into it so the
>> resulting output can potentially be modelled after it. That is: to either
>> return identifier name, or the name of the attribute.
>> * Also, this would be in line with your suggestion of not
>> reinventing the wheel.
>> * Finally, there would be no extra editor work.
>> Cons:
>> * Extra name in global namespace
>> * Any thoughts why this isn’t a good option?
>>
>> Regards,
>> DG
>>
>>> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> or
>>>
>>> print('{a=} and b={a}')
>>>
>>> This already exists. Kindly stop reinventing the wheel.
>>>
>>> the thing that does not exist now is:
>>>
>>> print('In this context, variable', 'name', 'means an esoteric thing that we
>>> all know about')
>>>
>>> where `'name'` can be substituted easily (the 'nameof' case) but it could
>>> be, as an example:
>>>
>>> print('In this context, variable {name!i} means an esoteric thing that we
>>> all know about')
>>>
>>> (my favorite, but interpreter maintenance costs trumps my preferences)
>>> or could be done as:
>>>
>>> print('In this context, variable', typing.ID['name'], 'means an esoteric
>>> thing that we all know about')
>>>
>>> which wouldn't change the interpreter at all, (but would change the stdlib).
>>>
>>> Either way, the 'nameof'-support needs editor support, because it is an
>>> *editing* use case, the interpreter just doesn't care.
>>> (It could, but it *can't* do anything without the *editor* responding to it)
>>>
>>> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis <[email protected]
>>> <mailto:[email protected]>> escreveu:
>>>
>>>
>>>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull
>>>> <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Dom Grigonis writes:
>>>>
>>>>>> But it's far from concise
>>>>> What could be more concise?
>>>>
>>>> A notation where you don't have to repeat a possibly long expression.
>>>> For example, numerical positions like regular expressions. Consider
>>>> this possible notation:
>>>>
>>>> f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>>>>
>>>> Otherwise it isn't great, but it's definitely concise. In the
>>>> simplest case you could omit the position:
>>>>
>>>> f'{=} is {count} at this point in the program.'
>>> Hmmm...
>>>
>>>>>> and violates DRY -- it doesn't solve the problem of the first
>>>>>> draft typo.
>>>>
>>>>> And how is “postfix =“ different?
>>>>
>>>> You *can't* use different identifiers for the name and value in
>>>> "postfix =": the same text is used twice, once as a string and one as
>>>> an identifier.
>>> I see what you mean, but this property is arguably intrinsic to what it is.
>>> And is part of f-strings vs explicit formatting property too:
>>> variable = 1
>>> print(f'{variable=} and b={variable}')
>>> # VS
>>> msg = 'variable={v} and b={v}'
>>> print(msg.format(v=variable))
>>> Especially, where msg can be pre-stored and reused. Then maybe not making
>>> it f-string only is a better idea. So that one can do:
>>> msg = '{a!i}={a} and b={a}'
>>> print(msg.format(a=variable))
>>>
>>>
>>>
>>>
>>
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/YCWLP64XEEYBVFR742AMQJAOVSGFCWBA/
Code of Conduct: http://python.org/psf/codeofconduct/
