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.
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.
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 <dom.grigo...@gmail.com>
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 <
> tiagoigira...@gmail.com> 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 <dom.grigo...@gmail.com>
> escreveu:
>
>>
>>
>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull <
>> turnbull.stephen...@u.tsukuba.ac.jp> 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 = 1print(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 -- 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/NPHKHDMMQAI5U5CSFFJ5U3U6SOIQB7UG/
Code of Conduct: http://python.org/psf/codeofconduct/
