[Python-ideas] Re: Extract variable name from itself
Can you please stop manufacturing consent? Em dom., 24 de set. de 2023 às 21:06, Dom Grigonis escreveu: > What is your position on this? > > Do you think that such thing is worth having? > > If yes, do any of the 3 final options seem sensible to you? > > > On 25 Sep 2023, at 02:39, Chris Angelico wrote: > > > > On Mon, 25 Sept 2023 at 07:05, Dom Grigonis > wrote: > >> What I meant is that functions in __builtins__ are low level, with > functionality which is hidden from the user. > >> > > > > What does that even mean? > > > > ChrisA > > ___ > > 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/ERAO66OAI73EO4YYCG3ODI3TPFSKYUEG/ > > 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/6ILMQ4PB5W6MAJZZALK47QDFOYYM4M4X/ > 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/XKAS5SGIKYYQ6HDXVHTT5KHL7DWJDO7C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
Appling my specific advice elsewhere is at most cute, in this case it was
offensive, and I doubt it was only to me.
The `'f{name!id}'` syntax is what *I* prefer, but *I* think that
subclassing typing.LiteralString is less disruptive.
'Esoteric' means something hidden, it is the exact opposite of 'we all know
about'
Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis
escreveu:
>
>
> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi <
> tiagoigira...@gmail.com> 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
> 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
[Python-ideas] Re: Extract variable name from itself
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
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
> 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 i
[Python-ideas] Re: Extract variable name from itself
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
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/ANC5KTEQND7SLUO2NASDEIYFV3ERJZJE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
The problem is that `f'{exp,format}'` is the current 'status
quo'/'zeitgeist'
You are trying to invert it. It looks wrong. (That's taste, not technical,
if you don't think it is a problem, it isn't a problem for *you*)
The technical: `f'{=name}'` doesn't tell what you're trying to do if you
don't already know what it would do.
And to be clear, the "nameof" part of the proposal I strongly support, I'm
just debating the easiest (an prettiest, how *I* see it) way to get it
Em dom., 24 de set. de 2023 às 10:01, Dom Grigonis
escreveu:
>
> > But it's far from concise
> What could be more concise?
>
> > and
> > violates DRY -- it doesn't solve the problem of the first draft typo.
> And how is “postfix =“ different?
>
> > I don't see it as elegant the way "postfix =" is.
> Agreed.
>
> 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/UR2J6SEAGKLAM2AIXO3746MGMZUH5ZRK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
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).
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.
The other use cases you mention are easily dealt with, assuming editor and
typing.LiteralString (subclassed) support.
Em sáb., 23 de set. de 2023 às 09:51, Dom Grigonis
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/A4EFCK6I5Y7IAZF5DHAFVUTJBD6R72RA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
This is the only use case I can think of. It could be supported by the typing module by subtyping LiteralString and let the editor tools do the rest. ___ 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/TXIAFDSEG5SMNSHH5NH7QXPDY4AISDO4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Have del return a value
You would be deleting the name, not the value. `unbind` would be a better keyword. ___ 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/EJBLQBZYZ2WL6SZJBWBMQF2NCNWRK7RD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: exception instance call should raise exception
Your original proposal appears to want this behavior:
class BaseException:
def __call__(self):
raise self
That could be expanded to something like:
class BaseException:
def __call__(self, *args):
if not args:
raise self
if len(args) > 1:
TypeError(f"{self} expects at most one argument")() # this adds
yet another call level
raise self from args[0]
@staticmethod
def reraise():
raise
Why, though? One would usually want to raise the exception at the same call
level of the invalid operation, not an extra one. Also, the raise statement
makes it clear that something went wrong, and is easily recognized by static
code analysers.
___
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/P3AHT7LKQ5QATZN5KUJVMPUEVSYWF4OH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Towards better type annotations enabled by PEP-0563, was: Re: Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
IMHO, if `->` becomes an operator with semantics, then `[t1, ..., tn] -> tr` should mean `typing.Callable[[t1, ..., tn], tr]`. ___ 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/ACRRCSNMMQ54IUHRYC3NH4XUL54VDUAQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Wouldn't it be better implemented on an editor as a display option instead of changing python? Because, as I understand, it's an issue of appearing nice on screen, rather than storing (and parsing) `'\u2192'` as an alias to `'->'` on type hints. It *would* look nice, though ___ 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/HEWJOAZIXZY2ESGPC2OCGSD25KKFVLSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
A programmer making the least effort wouldn't update themselves on the grammar: the patch would be useless. ___ 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/IACJB4BZFVFQR36O5WLE6CA2XM3IJTZM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
Is `?=` an operator? One could define `a ?= b` as `if a is None: a = b` (which is similar to make's operator, for example). Compare: def func(arg, option=None): option ?= expr #impl instead of: def func(arg, option=None): if option is None: option = expr #impl def func(arg, option=None): if option is None: option = expr #impl def func(arg, option=None): option = expr if option is None else option #impl def func(arg, option=None): option = option if option is not None else expr #impl or the proposed: def func(arg, option?=expr): #impl One could argue that the OP proposal is cleaner, but it adds *another* special notation on function definition. On performance, this would have tobe evaluated most likely upon entering the call. With the `if` guards or a hypothetical `?=` assignment, the programmer can better control execution (other arguments and/or options may render the test irrelevant). The great disadvantage of the `if` guard is a line of screen and an identation level, (which reminds me of PEP 572 rationale). I don't really like this `?=` assignment aesthetically, but I have written code that would look cleaner with it (though beauty is the eye of the beholder). Implementing only this operator would be at least simpler than both OP proposal and full PEP 505 (see also Neil Girdhar post above). ___ 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/ZJIEQAS3MG7OZG3VN5OTU27GCEGGLAO7/ Code of Conduct: http://python.org/psf/codeofconduct/
