subject:"\[Python\-ideas\] Re\: is a"

On Sun, 22 Oct 2023 at 11:29, MRAB  wrote:
> I think what the OP wants is to have re.match either return a match or
> raise an exception.

Yes, and my point is that simply attempting to access an attribute
will do exactly that. It's not a silent failure.

Why create a new argument, then mandate that you use it everywhere,
just to achieve what's already happening?

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/PUXKLC2K7SSNMIKUCEGGRJCF2NBT5URM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread MRAB

On 2023-10-21 21:15, Chris Angelico wrote:

On Sun, 22 Oct 2023 at 06:37, Ram Rachum  wrote:

On Sat, Oct 21, 2023 at 10:30 PM Chris Angelico  wrote:

> I love that, but it mostly makes sense for "if there's a match do this, otherwise do that" where 
most cases fall into "I'm absolutely sure there's a match here and here's what we should do with that 
match", and when that "absolutely sure" fails, the proper way to deal with that is by raising an 
exception.
>

Oh, you mean like AttributeError?

What I propose is like AttributeError in that they are both exceptions, but 
unlike AttributeError in that it'll communicate the problem effectively in a 
way that's easy to understand, especially by people who aren't Python experts.

When you and I see this:

AttributeError: 'NoneType' object has no attribute 'strip'

Which is strong evidence of a bug in your code. You're trying to tell
me that you want a way to enforce that, if the regex doesn't match,
it's a bug in your code. This seems to do that perfectly well.

If it's NOT a bug when the regex doesn't match, you have the standard
conditional form available. I'm not seeing a problem here.

I think what the OP wants is to have re.match either return a match or 
raise an exception.

___
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/SCPAXBHEYNBRMMTBAX7A4DIO7UAVXBZN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

On Sun, 22 Oct 2023 at 06:37, Ram Rachum  wrote:
>
> On Sat, Oct 21, 2023 at 10:30 PM Chris Angelico  wrote:
>>
>>
>> > I love that, but it mostly makes sense for "if there's a match do this, 
>> > otherwise do that" where most cases fall into "I'm absolutely sure there's 
>> > a match here and here's what we should do with that match", and when that 
>> > "absolutely sure" fails, the proper way to deal with that is by raising an 
>> > exception.
>> >
>>
>> Oh, you mean like AttributeError?
>>
>
> What I propose is like AttributeError in that they are both exceptions, but 
> unlike AttributeError in that it'll communicate the problem effectively in a 
> way that's easy to understand, especially by people who aren't Python experts.
>
> When you and I see this:
>
> AttributeError: 'NoneType' object has no attribute 'strip'
>

Which is strong evidence of a bug in your code. You're trying to tell
me that you want a way to enforce that, if the regex doesn't match,
it's a bug in your code. This seems to do that perfectly well.

If it's NOT a bug when the regex doesn't match, you have the standard
conditional form available. I'm not seeing a problem here.

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/OCGJC5PUPLW4NFEW2JOACALTNO6MEXJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread Ram Rachum

On Sat, Oct 21, 2023 at 10:30 PM Chris Angelico  wrote:

>
> > I love that, but it mostly makes sense for "if there's a match do this,
> otherwise do that" where most cases fall into "I'm absolutely sure there's
> a match here and here's what we should do with that match", and when that
> "absolutely sure" fails, the proper way to deal with that is by raising an
> exception.
> >
>
> Oh, you mean like AttributeError?
>
>
What I propose is like AttributeError in that they are both exceptions, but
unlike AttributeError in that it'll communicate the problem effectively in
a way that's easy to understand, especially by people who aren't Python
experts.

When you and I see this:

AttributeError: 'NoneType' object has no attribute 'strip'

Our brain that has been subjected to over a decade of Python work
automatically processes it, completely dismissing the 'strip' as a red
herring and concluding that a few lines above that line there was a regex
match that was expected to succeed but failed. Then we have to roll up our
sleeves and rerun this code with some instrumentation to find out what the
offending string was.

I propose to skip that entire exercise and go straight to:

re.NoMatchError: 'foobar' does not match pattern '^[0-9]+'

That would be so much nicer both for beginners and experienced developers.

What do you think about that?

Thanks,
Ram.
___
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/4KHHPCY4QTFK6HDTRQTYQCFE4FOLEA42/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

On Sun, 22 Oct 2023 at 06:11, Ram Rachum  wrote:
>
> On Sat, Oct 21, 2023 at 10:01 PM Chris Angelico  wrote:
>>
>> On Sat, 21 Oct 2023 at 21:57, Ram Rachum  wrote:
>>
>> What about an if with the match inside it?
>>
>> if m := re.match(...):
>> ...
>>
>> That's one of the motivating examples behind the walrus after all.
>
>
> I love that, but it mostly makes sense for "if there's a match do this, 
> otherwise do that" where most cases fall into "I'm absolutely sure there's a 
> match here and here's what we should do with that match", and when that 
> "absolutely sure" fails, the proper way to deal with that is by raising an 
> exception.
>

Oh, you mean like AttributeError?

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/CAG7AI2MKNSB6RTGHBYLQSD6MAOQO3AN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread Ram Rachum

On Sat, Oct 21, 2023 at 10:01 PM Chris Angelico  wrote:

> On Sat, 21 Oct 2023 at 21:57, Ram Rachum  wrote:
>
> What about an if with the match inside it?
>
> if m := re.match(...):
> ...
>
> That's one of the motivating examples behind the walrus after all.
>

I love that, but it mostly makes sense for "if there's a match do this,
otherwise do that" where most cases fall into "I'm absolutely sure there's
a match here and here's what we should do with that match", and when that
"absolutely sure" fails, the proper way to deal with that is by raising an
exception.
___
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/UXRGYESPWW2BTCSHRP64HFM2UJS27J6M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

On Sat, 21 Oct 2023 at 21:57, Ram Rachum  wrote:
>
> It's a little similar to the reasoning behind PEP 618 (adding the `strict` 
> argument to `zip`).

Not quite, since without strict, zip will truncate - it doesn't have a
different return value.

> A keyword argument is easier to add, and makes the code less ugly, then an 
> `if` clause. When I don't have that `if` clause you mentioned in my code, 
> it's not because I forgot, it's because I don't want an extra clause for 
> something I don't think is going to happen. Also, a keyword argument enables 
> code linters to enforce a rule that the `require` argument must always be 
> specified. (Example.)
>

What about an if with the match inside it?

if m := re.match(...):
...

That's one of the motivating examples behind the walrus after all.

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/EDPVFGDI53HULMSYZUDFZSXTHRD4GAG4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread Ram Rachum

It's a little similar to the reasoning behind PEP 618 (adding the `strict`
argument to `zip`).

A keyword argument is easier to add, and makes the code less ugly, then an
`if` clause. When I don't have that `if` clause you mentioned in my code,
it's not because I forgot, it's because I don't want an extra clause for
something I don't think is going to happen. Also, a keyword argument
enables code linters to enforce a rule that the `require` argument must
always be specified. (Example
.)


On Sat, Oct 21, 2023 at 1:45 PM Paul Moore  wrote:

> I don't see how it's more likely that people would remember to add a
> `require=True` flag than to add `if m: raise RuntimeError("No match")`. The
> problem here is people forgetting that a match can fail, not lack of a
> means to handle that problem.
>
> Paul
>
> On Sat, 21 Oct 2023 at 11:38, Ram Rachum  wrote:
>
>> Hey,
>>
>> I bet this has been discussed before but I couldn't find it. I'd
>> appreciate it if anyone could point me to that thread.
>>
>> I'm sick of seeing "AttributeError: 'NoneType' object has no attribute
>> 'foo'" whenever there's a `re.match` operation that fails while the code
>> expects it to succeed. What do you think about a flag `require` such that
>> `re.match(pattern, string, require=True)` would either return a match or
>> raise an exception with an actually useful message?
>>
>>
>> Thanks,
>> Ram.
>> ___
>> 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/PLF46RTMGJUIXRPXPLHZUPLTLGE47TQA/
>> 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/3MPSWTKM6TS6NC3OWQUSCU237IZLXLYE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread David Mertz, Ph.D.

I feel like this is all example of "not every one line function needs to be
in the standard library."

You can easily write your own 'match_or_raise()'... I guess it would take
two lines, actually.

On Sat, Oct 21, 2023, 2:42 PM Ram Rachum  wrote:

> Hey,
>
> I bet this has been discussed before but I couldn't find it. I'd
> appreciate it if anyone could point me to that thread.
>
> I'm sick of seeing "AttributeError: 'NoneType' object has no attribute
> 'foo'" whenever there's a `re.match` operation that fails while the code
> expects it to succeed. What do you think about a flag `require` such that
> `re.match(pattern, string, require=True)` would either return a match or
> raise an exception with an actually useful message?
>
>
> Thanks,
> Ram.
> ___
> 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/PLF46RTMGJUIXRPXPLHZUPLTLGE47TQA/
> 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/IIHOR3ZV7KSDHIZQDRAHX5HO6COJCOQN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread Paul Moore

I don't see how it's more likely that people would remember to add a
`require=True` flag than to add `if m: raise RuntimeError("No match")`. The
problem here is people forgetting that a match can fail, not lack of a
means to handle that problem.

Paul

On Sat, 21 Oct 2023 at 11:38, Ram Rachum  wrote:

> Hey,
>
> I bet this has been discussed before but I couldn't find it. I'd
> appreciate it if anyone could point me to that thread.
>
> I'm sick of seeing "AttributeError: 'NoneType' object has no attribute
> 'foo'" whenever there's a `re.match` operation that fails while the code
> expects it to succeed. What do you think about a flag `require` such that
> `re.match(pattern, string, require=True)` would either return a match or
> raise an exception with an actually useful message?
>
>
> Thanks,
> Ram.
> ___
> 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/PLF46RTMGJUIXRPXPLHZUPLTLGE47TQA/
> 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/BJ5R5MFLEDZFGKGHPLYBTPQJCCQTF5WZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread dn via Python-ideas


On 19/10/2023 20.43, Dom Grigonis wrote:

On 19 Oct 2023, at 10:27, dn via Python-ideas  wrote:
On 19/10/2023 19.50, Dom Grigonis wrote:

Thank you,
Good information, thank you. Was not aware of __set_name__.


IIRC that was one of the updates/improvements. Thanks to whomsoever...!

The:

instance.__dict__[self.name] = value

may require a bit of thought before it feels comfortable, but it is 
significantly easier to understand than what we had to do 'before'.

I am using `setattr(instance, self.name, value)`. But I see that 
instance.__dict__ is more appropriate in this case.


IIRC that's the way we used to have to do things, ie 'turn ourselves in 
knots'!


Because coding a Custom Descriptor is still something of a mind-bender, 
I coded a 'library' ABC/Super-class ("something I put in the oven 
earlier"*) which is slightly more sophisticated that the code-example 
(see earlier) PLUS a call to, and outline-code for an @abstractmethod 
called validate(). Care to guess its purpose!?


This means that when a Custom Descriptor is useful, it is a matter of 
(trust and) sub-classing, eg NonNegativeInteger( SuperClassName ), which 
provides an appropriate, concrete, validate() method.


"Re-use" = no fuss, no muss!
- more to the point, my future-self doesn't have to remember the 
intricacies of the 'new' (v3.6+) internal mechanisms...


(the ABC is about 40-lines of code. I'll post it upon demand, or perhaps 
better off-list...)



* this is a saying originating in (British) television cooking-shows, to 
explain the temporal distortion of how the cook went from a mix of 
uncooked ingredients to the finished article, without the waiting-time 
for it to cook - as we would in real-life.




Another surprise, and I've assumed you're asking in the context of [Custom] 
Descriptors, is in how many places/functions Python makes use of a 
descriptor/descriptor protocol. Yet few of us seem to make use of them in our 
application code...
(YMMV!)

I use them more and more.


+1
I use them to abstract-away almost all data-item data-validation.



However, I was more interested, why doesn't __set__ have an `owner` argument, 
while `__get__` does. I am aware that this is not an issue at all as one can 
simply do `inst.__class__`, but I am just curious about the reason for 
inconsistency.


@Antoine has given a technical explanation.


The next contribution to your thinking is probably to mention/remind 
that the "owner" argument (in the 'getter') is optional - can provide it 
in __set_name__() and record it there. Thus, the effective-signatures 
become:


def __get__( self, instance, )
...
def __set__( self, instance, value, )
...

Is this a more familiar pattern?


Perhaps the 'mistake' is not in an apparent lack of consistency, but in 
our expectation of a 'tidy' pattern? There's always going to be a 
difference in the two signatures, because the 'setter' must be provided 
with a value, whereas the 'getter' returns (cf accepts) a data-value.



Still have questions?
Let's take a step (or two) backwards:-

Most of us start (down this road) by being introduced to @property. A 
favorite (realistic) example is "age". Despite (sub-standard) text-books 
featuring personnel records that use such a field, no professional ever 
does! We record the person's date-of-birth, and thereafter compute the 
difference from today() to arrive at (today's) age. The neat 'discovery' 
is that when using object.age as a property, although the mechanism has 
been coded as a method, its use is indistinguishable from a 'normal' 
data-attribute. Smooth!


The next step in one's education is to add a 'setter'. The 
tutorial-example here might be a physical quantity, eg how many 
bars/tablets/blocks of chocolate you are buying (to give to me, of 
course). This must be a positive number (there's a (in)famous Amazon bug 
where they went 'live' allowing negative-quantities!!!). In the case of 
chocolate, it might be an integer. In the case of other products it 
might be a decimal/float, eg 1.5KG/lbs of flour. (yes, that would be to 
mix-up a chocolate cake!).


This extension to the first @property use-case, is likely the 
performance of some-sort of 'validation routine' to make sure that the 
data is fit-for-purpose ("data-cleaning", "data-validation", etc). The 
original @property mechanism swings into action when we ask for the 
value. In this case, the mechanism applies when we set the data-value. 
Thus, 5 is an acceptable quantity, but "five" is not - and the code is 
designed to test for such.


You know all this, and that an @property is 'syntactic sugar' for a 
Descriptor as the underlying mechanism.


So, now extend that final step, so that instead of an @property with 
'getter' and 'setter', code the data-item (actually, its type) as a 
Descriptor.


Now, remember that a data-item which is a Descriptor is just like any 
other. To set its value, the code is:


instance.quantity = 1.5  # ie 1.5KG of flour

An

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread Dom Grigonis

Thank you, makes sense. This one has been bugging me every time I worked with 
descriptors.

I even had __set__ method in my Descriptor Base for class attributes, but never 
needed it so didn’t realise.

> On 19 Oct 2023, at 12:09, Antoine Rozo  wrote:
> 
> Hi,
> 
> The __get__ method of descriptors can be called at the class level (that's 
> how methods work) and in that case instance would be None, but owner will 
> always reference the current class.
> 
> __set__ can only be called for instances on that class (`Cls.attr = ...` 
> would redefine the class-attribute and not call the descriptor), so instance 
> can never be None and owner is type(instance).
> 
> Le jeu. 19 oct. 2023 à 09:45, Dom Grigonis  > a écrit :
> 
> > On 19 Oct 2023, at 10:27, dn via Python-ideas  > > wrote:
> > 
> > On 19/10/2023 19.50, Dom Grigonis wrote:
> >> Thank you,
> >> Good information, thank you. Was not aware of __set_name__.
> > 
> > IIRC that was one of the updates/improvements. Thanks to whomsoever...!
> > 
> > The:
> > 
> >instance.__dict__[self.name ] = value
> > 
> > may require a bit of thought before it feels comfortable, but it is 
> > significantly easier to understand than what we had to do 'before'.
> I am using `setattr(instance, self.name , value)`. But I 
> see that instance.__dict__ is more appropriate in this case.
> 
> 
> > Another surprise, and I've assumed you're asking in the context of [Custom] 
> > Descriptors, is in how many places/functions Python makes use of a 
> > descriptor/descriptor protocol. Yet few of us seem to make use of them in 
> > our application code...
> > (YMMV!)
> I use them more and more.
> 
> 
> However, I was more interested, why doesn't __set__ have an `owner` argument, 
> while `__get__` does. I am aware that this is not an issue at all as one can 
> simply do `inst.__class__`, but I am just curious about the reason for 
> inconsistency.
> 
> Although, answers that I got were very useful.
> 
> 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/64MSMP4FFIT4FHPJQ66RW3OWXSP7RUFC/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> 
> 
> -- 
> Antoine Rozo

___
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/JYWMEHUBWSCKS7KAJP3DW46OKJ7BV3IS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread Antoine Rozo

Hi,

The __get__ method of descriptors can be called at the class level (that's
how methods work) and in that case instance would be None, but owner will
always reference the current class.

__set__ can only be called for instances on that class (`Cls.attr = ...`
would redefine the class-attribute and not call the descriptor), so
instance can never be None and owner is type(instance).

Le jeu. 19 oct. 2023 à 09:45, Dom Grigonis  a
écrit :

>
> > On 19 Oct 2023, at 10:27, dn via Python-ideas 
> wrote:
> >
> > On 19/10/2023 19.50, Dom Grigonis wrote:
> >> Thank you,
> >> Good information, thank you. Was not aware of __set_name__.
> >
> > IIRC that was one of the updates/improvements. Thanks to whomsoever...!
> >
> > The:
> >
> >instance.__dict__[self.name] = value
> >
> > may require a bit of thought before it feels comfortable, but it is
> significantly easier to understand than what we had to do 'before'.
> I am using `setattr(instance, self.name, value)`. But I see that
> instance.__dict__ is more appropriate in this case.
>
>
> > Another surprise, and I've assumed you're asking in the context of
> [Custom] Descriptors, is in how many places/functions Python makes use of a
> descriptor/descriptor protocol. Yet few of us seem to make use of them in
> our application code...
> > (YMMV!)
> I use them more and more.
>
>
> However, I was more interested, why doesn't __set__ have an `owner`
> argument, while `__get__` does. I am aware that this is not an issue at all
> as one can simply do `inst.__class__`, but I am just curious about the
> reason for inconsistency.
>
> Although, answers that I got were very useful.
>
> 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/64MSMP4FFIT4FHPJQ66RW3OWXSP7RUFC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Antoine Rozo
___
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/VPNJEO2A36LKQVSK764TJPXXSBE2QKLI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread Dom Grigonis



> On 19 Oct 2023, at 10:27, dn via Python-ideas  wrote:
> 
> On 19/10/2023 19.50, Dom Grigonis wrote:
>> Thank you,
>> Good information, thank you. Was not aware of __set_name__.
> 
> IIRC that was one of the updates/improvements. Thanks to whomsoever...!
> 
> The:
> 
>instance.__dict__[self.name] = value
> 
> may require a bit of thought before it feels comfortable, but it is 
> significantly easier to understand than what we had to do 'before'.
I am using `setattr(instance, self.name, value)`. But I see that 
instance.__dict__ is more appropriate in this case.


> Another surprise, and I've assumed you're asking in the context of [Custom] 
> Descriptors, is in how many places/functions Python makes use of a 
> descriptor/descriptor protocol. Yet few of us seem to make use of them in our 
> application code...
> (YMMV!)
I use them more and more.


However, I was more interested, why doesn't __set__ have an `owner` argument, 
while `__get__` does. I am aware that this is not an issue at all as one can 
simply do `inst.__class__`, but I am just curious about the reason for 
inconsistency.

Although, answers that I got were very useful.

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/64MSMP4FFIT4FHPJQ66RW3OWXSP7RUFC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread dn via Python-ideas


On 19/10/2023 19.50, Dom Grigonis wrote:

Thank you,

Good information, thank you. Was not aware of __set_name__.


IIRC that was one of the updates/improvements. Thanks to whomsoever...!

The:

instance.__dict__[self.name] = value

may require a bit of thought before it feels comfortable, but it is 
significantly easier to understand than what we had to do 'before'.


Another surprise, and I've assumed you're asking in the context of 
[Custom] Descriptors, is in how many places/functions Python makes use 
of a descriptor/descriptor protocol. Yet few of us seem to make use of 
them in our application code...

(YMMV!)

--
Regards,
=dn

___
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/KWIJS6L4DRI7333U2I2YYSXOJBKFCJQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread Dom Grigonis

Thank you,

Good information, thank you. Was not aware of __set_name__.

DG

> On 19 Oct 2023, at 09:28, dn via Python-ideas  wrote:
> 
> On 19/10/2023 18.29, Dom Grigonis wrote:
>> def  __get__(self, instance, owner):
>> def  __set__(self, instance, value):
>> Is there a reason why `__set__` does not have owner in it’s arguments while 
>> `__get__` does?
> 
> Is this a Python Idea?
> 
> You may have only given us a couple of lines, when the scope of the question 
> is much wider...
> 
> Be careful because these mechanisms were updated relatively-recently - and 
> thus there are differences between Python versions!
> 
> 
> From my notes (please see code-example which appears to answer your question):
> 
> The __set_name__() method is a special method in Python that is used in the 
> context of descriptors. It was introduced in Python 3.6 as a part of the 
> Descriptor Protocol.
> 
> The purpose of the __set_name__() method is to allow descriptors to 
> automatically determine and store the name of the attribute they are assigned 
> to within the class. This method is called once during the creation of the 
> descriptor instance, and it receives two arguments: the owner class and the 
> name of the attribute.
> 
> By implementing the __set_name__() method in a descriptor, you can access and 
> store the name of the attribute to which the descriptor is assigned. This can 
> be useful when you want to associate the descriptor with the attribute name 
> or perform any additional setup based on the attribute name.
> 
> Here's an example to illustrate the usage of __set_name__():
> 
> ```python
> class Descriptor:
>def __set_name__(self, owner, name):
>self.name = name
> 
>def __get__(self, instance, owner):
>if instance is None:
>return self
>return instance.__dict__.get(self.name)
> 
>def __set__(self, instance, value):
>instance.__dict__[self.name] = value
> 
> class MyClass:
>attribute = Descriptor()
> 
> obj = MyClass()
> obj.attribute = 42
> print(obj.attribute)  # Output: 42
> ```
> 
> In the above code, the Descriptor class defines the __set_name__() method. 
> When the attribute descriptor is assigned to the attribute attribute of the 
> MyClass class, the __set_name__() method is automatically called with the 
> owner class (MyClass) and the attribute name (attribute). Inside this method, 
> we store the attribute name in the descriptor instance.
> 
> Later, when we set obj.attribute = 42, the descriptor's __set__() method is 
> called, and the value is stored in the instance's __dict__ attribute using 
> the previously stored attribute name.
> 
> By using __set_name__(), descriptors can dynamically associate themselves 
> with the attribute names they are assigned to, providing more flexibility and 
> customization.
> 
> 
> Web.Refs:
> https://docs.python.org/3/howto/descriptor.html
> https://docs.python.org/3/reference/datamodel.html#descriptors
> 
> -- 
> Regards,
> =dn
> ___
> 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/L7WZA7GEW3TPYUA4NF6POHDL2FSF5TIY/
> 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/GXXHZ4KPC5OJDKGMMOWSE6SH44EAHJYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Descriptor get and set argument discrepancy

2023-10-19 Thread dn via Python-ideas


On 19/10/2023 18.29, Dom Grigonis wrote:

def  __get__(self, instance, owner):
def  __set__(self, instance, value):

Is there a reason why `__set__` does not have owner in it’s arguments 
while `__get__` does?


Is this a Python Idea?

You may have only given us a couple of lines, when the scope of the 
question is much wider...


Be careful because these mechanisms were updated relatively-recently - 
and thus there are differences between Python versions!



From my notes (please see code-example which appears to answer your 
question):


The __set_name__() method is a special method in Python that is used in 
the context of descriptors. It was introduced in Python 3.6 as a part of 
the Descriptor Protocol.


The purpose of the __set_name__() method is to allow descriptors to 
automatically determine and store the name of the attribute they are 
assigned to within the class. This method is called once during the 
creation of the descriptor instance, and it receives two arguments: the 
owner class and the name of the attribute.


By implementing the __set_name__() method in a descriptor, you can 
access and store the name of the attribute to which the descriptor is 
assigned. This can be useful when you want to associate the descriptor 
with the attribute name or perform any additional setup based on the 
attribute name.


Here's an example to illustrate the usage of __set_name__():

```python
class Descriptor:
def __set_name__(self, owner, name):
self.name = name

def __get__(self, instance, owner):
if instance is None:
return self
return instance.__dict__.get(self.name)

def __set__(self, instance, value):
instance.__dict__[self.name] = value

class MyClass:
attribute = Descriptor()

obj = MyClass()
obj.attribute = 42
print(obj.attribute)  # Output: 42
```

In the above code, the Descriptor class defines the __set_name__() 
method. When the attribute descriptor is assigned to the attribute 
attribute of the MyClass class, the __set_name__() method is 
automatically called with the owner class (MyClass) and the attribute 
name (attribute). Inside this method, we store the attribute name in the 
descriptor instance.


Later, when we set obj.attribute = 42, the descriptor's __set__() method 
is called, and the value is stored in the instance's __dict__ attribute 
using the previously stored attribute name.


By using __set_name__(), descriptors can dynamically associate 
themselves with the attribute names they are assigned to, providing more 
flexibility and customization.



Web.Refs:
https://docs.python.org/3/howto/descriptor.html
https://docs.python.org/3/reference/datamodel.html#descriptors

--
Regards,
=dn
___
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/L7WZA7GEW3TPYUA4NF6POHDL2FSF5TIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-10 Thread Rob Cliffe via Python-ideas

The fact that it is not allowed is nothing to do with the 'return'. You 
*can* write

    return (x := x+1)
What you can't (at present) do is use the walrus operator with an attribute:
    x = (self.a := self.a + 1) # SyntaxError
I too have found times when this would be convenient.
As Stephen says, Python often adds new features conservatively, then 
extends them later if/when it seems desirable.  This happened with the 
'@' decorater: originally it came with all manner of restrictions, but 
eventually they were removed.  IMO this was a good thing because it made 
the language more uniform, meaning you didn't have to remember what was 
allowed and what wasn't; so I hope the same will happen with the walrus 
operator.

Best wishes
Rob Cliffe

On 09/10/2023 02:17, Dom Grigonis wrote:

Is there a reason why this is not allowed?
return  (self.mode :=  self.mode_valid(mode))

___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/EULXNH2OQOY72LDAMQSRLA3JKU55UBG6/
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/TUZFTPSM3VSFGDCJLJKX2C5MSPMMCVV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-10 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > Why would this not be a good option? 1 extra line compared to
 > walrus, but no DRY issue.
 >   with open(“fn") as f:
 > while True:
 > line = f.readline()
 > if line and check(line):
 > process(line)
 > else:
 > break

Works for me.  I suspect you can construct situations where it would
be a lot uglier.  But I'm not a fan of the walrus in the first place,
so I'm not going to take this any further.

Steve
___
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/ATQJORWTV5PJ2Z43FIPP5E2Z4GZWQGAS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-09 Thread Dom Grigonis

I just want to note that this is just a gentle suggestion/observation, in case 
this wasn’t done yet.

I am not pushing this.

——

All good points, thank you.

——

Why would this not be a good option? 1 extra line compared to walrus, but no 
DRY issue.
with open(“fn") as f:
while True:
line = f.readline()
if line and check(line):
process(line)
else:
break
DG

> On 9 Oct 2023, at 15:52, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> Mistake, late night. I just meant to portray initialisation via
>> walrus inside statement, nothing more. It doesn’t work with while
>> loop.
> 
> It *does* work with a while loop, just not that one.  See below.  The
> problem is that you're writing new code full of trash you don't need
> to explain the concept.  Keep these examples as simple as possible.
> For example, my "pass" example is too simple if you want to show how
> the walrus can save typing because it doesn't save any lines of code;
> you need something a little more complicated to demonstrate that
> saving.
> 
> In the progress of any proposal to acceptance, at some point someone
> is going to say, "I see that it works and solves a theoretical
> problem, but who would ever use it?"  At that point you go into a
> large body of code such as the Python standard library or numpy to
> find realistic examples.  But that's old code, and only needed to
> demonstrate actual utility.
> 
>> Generally, this would be useful for all examples of
>> https://peps.python.org/pep-0572/ 
>> , where “initial” value is an attribute or dictionary item.
> 
> That's not the question though.  The question is are those examples
> themselves frequently useful.  And that's when you go find them in the
> stdlib.
> 
>> I see. Could you give an example of this? I vaguely remember this
>> sometimes being the case, but can not find anything now on this in
>> relation to walrus operator. Is there no way to bring that
>> execution within the body without walrus operator?
> 
> The problem is code like this:
> 
>with open("a_file") as f:
>while (line := f.readline())
>if check(line):
>process(line)
>else:
>break
> 
> There is no way to do that without an assignment, and without the
> walrus you need an assignment before the while, and the same
> assignment within the loop body.  Is that a big deal?  No.  In fact, I
> have never used the walrus operator in anger, nor wanted to.  I'm just
> as happy to write
> 
>with open("a_file") as f:
>line = f.readline()
>while (line)
>if check(line):
>process(line)
>else:
>break
>line = f.readline()
> 
> But some people find loop-and-a-half extremely ugly, and while I
> differ on "extremely", I can't deny that it's ugly.
> 
> You *could* do this for small files with
> 
>with open("a_file") as f:
>lines = f.readlines()
>for (line in lines):
>if check(line):
>process(line)
>else:
>break
> 
> but that's not possible with an infinite iterable, undesireable for
> most non-file streams, etc.
> 
> Re "simple examples", see why I used the "if check()" stuff?  If I
> wasn't going to talk about infinite iterables and pausing external
> streams, that would just be (potentially wrong!) complexity that
> doesn't help explain anything.
> 
> Steve
> 
> 

___
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/B2TLFMOOYMRRXCRJLLFV6F5URU4OPO3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-09 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > Mistake, late night. I just meant to portray initialisation via
 > walrus inside statement, nothing more. It doesn’t work with while
 > loop.

It *does* work with a while loop, just not that one.  See below.  The
problem is that you're writing new code full of trash you don't need
to explain the concept.  Keep these examples as simple as possible.
For example, my "pass" example is too simple if you want to show how
the walrus can save typing because it doesn't save any lines of code;
you need something a little more complicated to demonstrate that
saving.

In the progress of any proposal to acceptance, at some point someone
is going to say, "I see that it works and solves a theoretical
problem, but who would ever use it?"  At that point you go into a
large body of code such as the Python standard library or numpy to
find realistic examples.  But that's old code, and only needed to
demonstrate actual utility.

 > Generally, this would be useful for all examples of
 > https://peps.python.org/pep-0572/ 
 > , where “initial” value is an attribute or dictionary item.

That's not the question though.  The question is are those examples
themselves frequently useful.  And that's when you go find them in the
stdlib.

 > I see. Could you give an example of this? I vaguely remember this
 > sometimes being the case, but can not find anything now on this in
 > relation to walrus operator. Is there no way to bring that
 > execution within the body without walrus operator?

The problem is code like this:

with open("a_file") as f:
while (line := f.readline())
if check(line):
process(line)
else:
break

There is no way to do that without an assignment, and without the
walrus you need an assignment before the while, and the same
assignment within the loop body.  Is that a big deal?  No.  In fact, I
have never used the walrus operator in anger, nor wanted to.  I'm just
as happy to write

with open("a_file") as f:
line = f.readline()
while (line)
if check(line):
process(line)
else:
break
line = f.readline()

But some people find loop-and-a-half extremely ugly, and while I
differ on "extremely", I can't deny that it's ugly.

You *could* do this for small files with

with open("a_file") as f:
lines = f.readlines()
for (line in lines):
if check(line):
process(line)
else:
break

but that's not possible with an infinite iterable, undesireable for
most non-file streams, etc.

Re "simple examples", see why I used the "if check()" stuff?  If I
wasn't going to talk about infinite iterables and pausing external
streams, that would just be (potentially wrong!) complexity that
doesn't help explain anything.

Steve

___
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/3SSXFFCSGLMJ4HBDJXOP6KFJDCGEXZDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-09 Thread Dom Grigonis

On 9 Oct 2023, at 08:58, Stephen J. Turnbull 
 wrote:
> ...
> Not sure what you're getting at here, that's an infloop.  Did you mean
> something like this:
> 
>class A:
>def func(self):
>while (self.a := self.a += 1) < 5:
>pass
>return self.a
Mistake, late night. I just meant to portray initialisation via walrus inside 
statement, nothing more. It doesn’t work with while loop. The intention was 
this, which is also principal use-case from previous reply:
class A:
def func(self, string):
if self.a := re.match('.*', string):
print(self.a)
return self.a.group()
Generally, this would be useful for all examples of
https://peps.python.org/pep-0572/ 
, where “initial” value is an attribute or dictionary item.

>> Same argument as for “walrus” operator itself - convenient
>> feature. Or is there more to it?
> 
> There's more to it.  The loop and a half construct, where you execute
> the body of the loop once outside the loop for some reason is widely
> considered a really big wart (DRY failure).  The walrus allows us to
> eliminate most of those.
> 
> On the other hand, an assignment and a return statement are two
> different things; it's not a DRY viotion to have the same identifier
> in both.
I see. Could you give an example of this? I vaguely remember this sometimes 
being the case, but can not find anything now on this in relation to walrus 
operator. Is there no way to bring that execution within the body without 
walrus operator?

>> I was actually surprised that this didn’t work - I thought that
>> this operator is a literal composite of assignment and “retriever",
>> rather than having it’s own restrictive logic.
> 
> This is a common practice in Python development.  Try a little bit of
> a new idea, avoid engineering, and expand later if that seems useful
> too.
Fair.

>> If it doesn’t break anything, doesn’t have any undesirable side
>> effects and community likes it, then could be a good addition.
> 
> "Community likes it" is a null predicate, very hard to verify in edge
> cases.  When the support in the community is strong enough that
> "community likes it" is common knowledge, it's always the case that
> there are objective reasons why it's a good thing.
> 
> All additions have a 0 * infinity cost: a negligible cost of learning
> (for one user) times *all* the users.
Ok, thanks.

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/JXUUX7EDHM73RZQVGEUADS7X6AJSB3CB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-09 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > This nuance can also be encountered in “principal use-case”. E.g.:
 > class A:
 > def func(self):
 > while (self.a := 1) < 5:
 > self.a += 1
 > return self.a

Not sure what you're getting at here, that's an infloop.  Did you mean
something like this:

class A:
def func(self):
while (self.a := self.a += 1) < 5:
pass
return self.a

I'm pretty sure that exact idiom, modeled on the C "copy string" idiom

void strcpy(char *s, char *t) {
while (*t++ = *s++)

would generally be considered unpythonic, but I suppose some people
might like it if instead of pass you had a real suite there.  I think
it's a real "meh" use case, since in most cases it can be rewritten

class A:
def func(self):
while self.a < (5 - 1):  # expression to make the
 # transformation clear
self.a += 1
return self.a

and you save a couple characters and at most one line (none in the
case you present).

 > Same argument as for “walrus” operator itself - convenient
 > feature. Or is there more to it?

There's more to it.  The loop and a half construct, where you execute
the body of the loop once outside the loop for some reason is widely
considered a really big wart (DRY failure).  The walrus allows us to
eliminate most of those.

On the other hand, an assignment and a return statement are two
different things; it's not a DRY viotion to have the same identifier
in both.

 > I was actually surprised that this didn’t work - I thought that
 > this operator is a literal composite of assignment and “retriever",
 > rather than having it’s own restrictive logic.

This is a common practice in Python development.  Try a little bit of
a new idea, avoid engineering, and expand later if that seems useful
too.

 > If it doesn’t break anything, doesn’t have any undesirable side
 > effects and community likes it, then could be a good addition.

"Community likes it" is a null predicate, very hard to verify in edge
cases.  When the support in the community is strong enough that
"community likes it" is common knowledge, it's always the case that
there are objective reasons why it's a good thing.

All additions have a 0 * infinity cost: a negligible cost of learning
(for one user) times *all* the users.

Other projects feel differently about it, but Python tends to be quite
conservative about additions.

Steve
___
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/IFTS6XVVNAYXBMUBUB2FF6QX7BMFKXVQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-08 Thread Dom Grigonis


> Having:
> 
>self.mode = self.mode_valid(mode)
>return self.mode
> 
> isn't too bad.

No, not bad at all. But to me, being able to use walrus would be convenient.

———

This nuance can also be encountered in “principal use-case”. E.g.:
class A:
def func(self):
while (self.a := 1) < 5:
self.a += 1
return self.a

A().func()
Could be useful in iterator protocol implementations, where/or_where state is 
managed with property setters managing objects that implement  custom 
`__iadd__`, etc or just simply convenience as in my former example.

Same argument as for “walrus” operator itself - convenient feature. Or is there 
more to it?

———

I was actually surprised that this didn’t work - I thought that this operator 
is a literal composite of assignment and “retriever", rather than having it’s 
own restrictive logic.

Could be a reason for it, maybe to avoid some undesirable mis-usage. But I 
can’t see it. Any issues arising from such construct would be the same issues 
as for:
expr = 1
expr
This could be an actual assignment + retrieval of left-hand-side, then it would 
work generically for all constructs, such as:
a()[‘a'] := 1
a().attr := 1
If walrus currently has its own specific logic, this would integrate it nicely 
into assignment operator. Then it would benefit automatically from any language 
extension that makes use of it.

Or is it already it, just with added restrictions?

All in all, I think would be a generalisation of a convenience feature, which 
doesn’t invent anything new, but extends its convenience to more general 
application.

These are my thoughts, whether it’s worthwhile and sensible - I have no idea.

If it doesn’t break anything, doesn’t have any undesirable side effects and 
community likes it, then could be a good addition.

Regards,
DG

P.S. Deferred evaluation will be able to handle this one too___
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/VGMMI4PNTSW4AD22EESF62DWUOMJ3RHK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SyntaxError: cannot use assignment expressions with attribute

2023-10-08 Thread MRAB


On 2023-10-09 02:17, Dom Grigonis wrote:

Is there a reason why this is not allowed?


return  (self.mode :=  self.mode_valid(mode))


The principal use-case for the operator is in conditions, for example:
if m := re.match(pattern_1, string):
...
elif m := re.match(pattern_2, string):
...
else:
...

or:

while line := file.readline():
...

Do you have a convincing argument that it should be expanded from a 
simple name?


Having:

self.mode = self.mode_valid(mode)
return self.mode

isn't too bad.
___
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/OIZ3W7XOIAFU345FKXN63YOC2J7E4R5I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-28 Thread Dom Grigonis

Just want to clear things out that I did not respond to immediately due to 
obvious reasons.

> On 25 Sep 2023, at 07:44, Tiago Illipronti Girardi  
> wrote:
> Can you please stop manufacturing consent?
It is not what you stated it is. It was something different.

An example of manufacturing consent was:
> and I doubt it was only to me

In the context of:
> On 24 Sep 2023, at 22:32, Tiago Illipronti Girardi  
> wrote:
> Appling my specific advice elsewhere is at most cute, in this case it was 
> offensive, and I doubt it was only to me.


And what was being referred to was not offensive, only unless badly 
misinterpreted. An accusation as such on a public group is. It was also 
offensive to people who you implicitly involved in supposedly supporting your 
opinion without their consent.

Regards,
DG


> 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/DRUFRQ4SSXZ2GPJV3NTMKVRGQKFKDGG3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reconstructing datetime from microsecond timestamp

2023-09-25 Thread Samuel Freilich via Python-ideas

*puts on contributor hat*

Well all right then! Filed https://github.com/python/cpython/issues/109849,
recapping this and asking some questions about the specifics. I'll try to
put together a PR.

On Mon, Sep 25, 2023 at 3:49 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Samuel Freilich via Python-ideas writes:
>
>  > This might all be too much thought about edge cases that don't
>  > matter, but given the *_ns() functions in the time module (PEP
>  > 564), I'm curious why datetime doesn't have a constructor that
>  > takes an integer timestamp with the full precision that supports.
>
> This is such an obvious improvement that the only answer I can think
> of is "Because you haven't submitted a merge request yet?" ;-)
>
> TBH honest you're right about the edge case, mostly datetime is about
> talking to humans and that's almost by definition not worth the time
> of a core dev to shave nanoseconds off the operation.  But if someone
> is looking for a chance to put in a patch, this looks likely to be
> approved to me.
>
>
>
___
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/N3GSWPC3EXKBRZDRBGTJ35FFDUS7ICFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-25 Thread Chris Angelico

On Mon, 25 Sept 2023 at 22:04, Dom Grigonis  wrote:
>
> I think a lot has been said by this time and I have nothing to add.
>
> If this is something that is of value, I am sure it will be picked up when 
> the time is right.
>
> One last thing that I think could be of some use is a poll:
>
> https://take.supersurvey.com/QCVZKTDY0
>
> It will not take more than few seconds. Appreciate your time.

Polls are utterly useless.

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/N2KIKNPULOLSBXTJ4472ZWMTUAV623XH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-25 Thread Dom Grigonis

I think a lot has been said by this time and I have nothing to add.

If this is something that is of value, I am sure it will be picked up when the 
time is right.

One last thing that I think could be of some use is a poll:

https://take.supersurvey.com/QCVZKTDY0 

It will not take more than few seconds. Appreciate your time.

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/65OSC2LGO44SNQCKH5VP6I2UNZ5I64AD/
Code of Conduct: http://python.org/psf/codeofconduct/

[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

2023-09-24 Thread Chris Angelico

On Mon, 25 Sept 2023 at 10:05, Dom Grigonis  wrote:
>
> 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?
>

My position is that so far, you haven't shown it to be of much value.
Which might be because the idea has no value, but more likely, it's
because I just haven't understood from your posts why this should be
added to the language.

So far, you've shown that this should be an editor feature, but you
haven't convinced me that the language should take any notice of it.

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/NFCXP5SILAEJIV7HWS6RDY23WP7H4LVO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

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] Re: Extract variable name from itself

2023-09-24 Thread Chris Angelico

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] Re: Extract variable name from itself


> '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!}’ applies functions to 
v from builtin namespace: str/repr/ascii.

> Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis  > escreveu:
> 
> 
>> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi > > 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 >> > 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 
 >>> > 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

[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
>> *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

[Python-ideas] Re: Extract variable name from itself



> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi  
> 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 > > 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 
>>> >> > 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
>>>

[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 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

[Python-ideas] Re: Extract variable name from itself

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  
> 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 
>> > > 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 -- 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/SWJ5YHQWHLRW2YKGUDIRYIIXTA43QPMI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself



> On 24 Sep 2023, at 17:23, Chris Angelico  wrote:
> 
> On Mon, 25 Sept 2023 at 00:15, Dom Grigonis  wrote:
>> 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.
> 
> What do you mean by that? Are you suggesting that there's a massive
> cost in constructing a string literal and thus reusing it with
> .format() is more efficient than an f-string? Because that's, uhh,
> kinda not the point of str.format().
That was in response to it violating DRY. Just pointed out that it is intrinsic 
to the wider scope of how things work in different ways of formatting and for 
it to be completely satisfied, str.format can be used as opposed to f-strings. 
It was about DRY, not efficiency.

> And if that isn't what you mean, what is it? Your posts are often
> distinctly unclear. I get the impression that you think everyone else
> understands your idea.

Apologies. Noted.___
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/23DNNUYD2EYKSZPCHRSF3CTGZYR3XEEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[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

2023-09-24 Thread Chris Angelico

On Mon, 25 Sept 2023 at 00:15, Dom Grigonis  wrote:
> 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.

What do you mean by that? Are you suggesting that there's a massive
cost in constructing a string literal and thus reusing it with
.format() is more efficient than an f-string? Because that's, uhh,
kinda not the point of str.format().

And if that isn't what you mean, what is it? Your posts are often
distinctly unclear. I get the impression that you think everyone else
understands your idea.

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/GZPWQBKAGSIQEF5QAFMZ3XYYT34WIPAT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself



> On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
>  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 -- 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/VV7FFVBVTXCAOI6OQVHN3DZIIM5RVPLT/
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

2023-09-24 Thread Stephen J. Turnbull

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.'

 > > 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.
___
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/HNARI3L4PXNTJFGZD5AHTBG2RBLIC5OD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself


> 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/MJ6FVYOKOLGGHSHAEOGCVNCGSRY42M44/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-24 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > By “elegant", I wasn’t talking about the syntax.

Neither was I, except in the comment about "mnemonic".  I use "postfix
=" and "prefix =" because I don't know of better names that indicate
the semantics of the feature.

Semantically, "prefix =" is a reasonable solution to the problem --
assuming you consider it a problem.  But it's far from concise and
violates DRY -- it doesn't solve the problem of the first draft typo.
I don't see it as elegant the way "postfix =" is.
___
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/NB66RQQID7HKB5NOG6BRGQMZCPDHBQ7P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

I haven’t given much thought regarding the syntax. The prefix “=“ just popped 
into my mind and I went along with it to use in my examples. The point was that 
f-strings are potentially a good place to implement such thing.

By “elegant", I wasn’t talking about the syntax. It was more about the benefits 
of it being well integrated python construct, which is subject to a parser and 
is a python code by all standards and it fitting in that place sensibly given 
what it is.

Regards,
DG

> On 24 Sep 2023, at 05:15, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> Eric Smith wrote:
>>> 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.
> 
> Sure ... about an unclearly expressed early version of the proposal,
> that seemed to ask "given an object x, tell me the name of x".  In the
> end, I don't think there was any disagreement that doing that reliably
> is indeed impossible.  But if someone has written that the #nameof
> version of the proposal is impossible to implement, that is not
> representative of what most of us think or have said.
> 
>> What I think is that it would be an elegant feature if it was
>> implemented at python level.
> 
> The postfix '=' flag is elegant by anyone's standard, I think: it
> provides immediately useful, though limited, functionality, with no
> waste, and is automatically fit for purpose because it satisfies DRY.
> And it is mnemonic in the sense that you may have to look it up to
> write it, but once you've learned it, you will recognize it when you
> see it in unfamiliar code because it "looks like" what it produces.
> 
> The proposed prefix '=' flag is much less attractive to me on all
> counts above, except that it's quite mnemonic.
> 
> Steve

___
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/IQKEAWZQYHZECH74BTXBO2T4VF44ZKAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-23 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > Eric Smith wrote:
 >> 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.

Sure ... about an unclearly expressed early version of the proposal,
that seemed to ask "given an object x, tell me the name of x".  In the
end, I don't think there was any disagreement that doing that reliably
is indeed impossible.  But if someone has written that the #nameof
version of the proposal is impossible to implement, that is not
representative of what most of us think or have said.

 > What I think is that it would be an elegant feature if it was
 > implemented at python level.

The postfix '=' flag is elegant by anyone's standard, I think: it
provides immediately useful, though limited, functionality, with no
waste, and is automatically fit for purpose because it satisfies DRY.
And it is mnemonic in the sense that you may have to look it up to
write it, but once you've learned it, you will recognize it when you
see it in unfamiliar code because it "looks like" what it produces.

The proposed prefix '=' flag is much less attractive to me on all
counts above, except that it's quite mnemonic.

Steve
___
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/7MVQ27WLEDWEDKKTSWM4VBWMOENXSIOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-23 Thread Eric V. Smith via Python-ideas

On Sep 23, 2023, at 5:37 PM, Dom Grigonis  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/67977672360659f203664d23cfc52b5e07e4381aSince 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,DGOn 23 Sep 2023, at 23:55, Dom Grigonis  wrote:the output will have the _expression_ textThis 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, but not A without B. Would appreciate if you convinced me with some support for your rather strong statements.Regards,DGOn 23 Sep 2023, at 23:18, Tiago Illipronti Girardi  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 (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  wantEm sáb., 23 de set. de 2023 às 13:16, Dom Grigonis  escreveu:On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi  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 = 6print(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

[Python-ideas] Re: Extract variable name from itself

> 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  wrote:
> 
> 
> 
>> On Sep 23, 2023, at 5:37 PM, Dom Grigonis  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
>>  
>> 
> 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 >> > 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 
 . 
>>> 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, 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 
 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 
  (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

 Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis >>> > escreveu:

> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi 
> 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`.

[Python-ideas] Re: Extract variable name from itself

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
 


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  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 
>> . 
> 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, 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 > > 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 
>>  (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
>> 
>> Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis > > escreveu:
>> 
>> 
>>> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi >> > 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

[Python-ideas] Re: Extract variable name from itself

> 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, 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  
> 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 
>  (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
> 
> Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis  > escreveu:
> 
> 
>> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi > > 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

[Python-ideas] Re: Extract variable name from itself


> On 23 Sep 2023, at 16:24, Tiago Illipronti Girardi  
> 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  > 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/TKB3EVGGSXRBZQ5EXKRX5GCW5NPRVB4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-23 Thread Tiago Illipronti 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).
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.
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/7G5EXX7QBGJB7H3PDNOWXKW2JMPDIJ4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-23 Thread Tiago Illipronti Girardi

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: Extract variable name from itself

2023-09-23 Thread Pyrous

>It's really something that needs editor support, not compiler support. As far as the Python interpreter is concerned, this is just a string.>So why not just make it an editor feature?>def nameof(x): return x>print("This " + nameof("thing") + " is:", thing)>As far as I can tell, this isn't a Python feature at all. It's an editor refactoring feature.>ChrisAThis is the only use case I can think of. Couldn’t we just subclass typing.LiteralString to typing.Id or something for this “functionality” and let editing tools deal with it. Also I accidentaly made the windows11 client the app for responding these, can someone help to undo it, thanks. Send from Windows11 client (sorry IT SUCKS) 
___
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/HULYOIQBBQKPJWPTWGA666S3B62VMYOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself



> On 23 Sep 2023, at 08:54, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> Simply eval/exec string inputs. I sometimes use of these for ad-hoc
>> callbacks. Would be great if `v` was recognised as a code.
> 
> Looking at the example, do you mean '=' here?  That is, you want to
> add semantics for prefixed '=', meaning "just insert the expression
> string here"?
Correct, it’s the one that I though could make sense, so just keep using it in 
examples now.


>> Code is similar to this: class A:
>>def __init__(self):
>>self.d = {'a': 1, 'b': 2}
>> 
>>def apply(self, smtp):
>>for k, v in self.d.items():
>>if callable(smtp):
>>self.d[k] = smtp(v)
>>elif isinstance(smtp, str):
>>self.d[k] = eval(f'{=v}{smtp}')
> 
> Since f'{=v}' just results in 'v', why isn't
> 
>self.d[k] = eval(f'v{smtp}')
> 
> fine?  Sure, you get the compiler check/refactoring benefit, but as
> you admit, this is a very "ad hack" use case.  I don't think we should
> encourage it in production code.

Agree, this use case is not for production code.

Correct me if I am wrong, but I think `eval` in general should not be 
encouraged in production code.


___
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/N74S6AEKQEXG467DA5CWOW2DAO7KAWN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-22 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > Simply eval/exec string inputs. I sometimes use of these for ad-hoc
 > callbacks. Would be great if `v` was recognised as a code.

Looking at the example, do you mean '=' here?  That is, you want to
add semantics for prefixed '=', meaning "just insert the expression
string here"?

 > Code is similar to this: class A:
 > def __init__(self):
 > self.d = {'a': 1, 'b': 2}
 > 
 > def apply(self, smtp):
 > for k, v in self.d.items():
 > if callable(smtp):
 > self.d[k] = smtp(v)
 > elif isinstance(smtp, str):
 > self.d[k] = eval(f'{=v}{smtp}')

Since f'{=v}' just results in 'v', why isn't

self.d[k] = eval(f'v{smtp}')

fine?  Sure, you get the compiler check/refactoring benefit, but as
you admit, this is a very "ad hack" use case.  I don't think we should
encourage it in production code.
___
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/PEVTGJOPRWP5SLBLK4UZHISD3EGTRR7K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-22 Thread Dom Grigonis

Just want to add to this as I encountered a case, where I think f-string would 
be sensible to use. Third potential use case after logging & dictionary key 
synchronisation with variables names.

Simply eval/exec string inputs. I sometimes use of these for ad-hoc callbacks. 
Would be great if `v` was recognised as a code. Code is similar to this:
class A:
def __init__(self):
self.d = {'a': 1, 'b': 2}

def apply(self, smtp):
for k, v in self.d.items():
if callable(smtp):
self.d[k] = smtp(v)
elif isinstance(smtp, str):
self.d[k] = eval(f'{=v}{smtp}')

a = A()
print(a.d)# {'a': 1, 'b': 2}
a.apply(lambda x: x * 2)
print(a.d)# {'a': 2, 'b': 4}
a.apply('* 2')
print(a.d)# {'a': 4, 'b': 8}
Regards,
DG


> On 16 Sep 2023, at 20:43, Dom Grigonis  wrote:
> 
> Agree, all good points.
> f'{=expr}'.split('.')[-1]
> Does take care of all cases and `nameof` has no additional use over it.
> 
> It seems that `nameof` is out of question.
> 
> DG
> 
>> On 16 Sep 2023, at 19:50, Stephen J. Turnbull 
>> > > wrote:
>> 
>> Dom Grigonis writes:
>> 
>>> print(f'{=A.a}')# 'A.a'
>>> print(nameof(A.a))  # 'a'
>> 
>> I see that's the C# semantics, but it's not obvious to me why the
>> ambiguity introduced is worth emulating.  The important aspect of the
>> proposed 'nameof' operator is that its argument can be validated by
>> the compiler and unambiguously recognized by refactoring tools.  But
>> once it's a string, it loses those advantages.  Why not be unambiguous?
>> 
>> I don't think that the tricks recommended (ie, typeof) to retrieve a
>> fully-qualified name in C# would be unambiguous in Python.
>> 
>> Also, Python's f-string '=' operator handles a broad variety of
>> expressions, not just attribute references.  This has been useful to
>> me more often than bare names and attribute references.
>> 
>>> Both [member name and full reference] seem useful to me.
>> 
>> What am I missing?  When would you want the member name only but
>> "nameof().split('.')[-1]" would not do?
>> 
>> Also, are there use cases for the proposed nameof other than a more
>> flexible f-string '='?  Ie, where only the str is wanted, not the
>> str-ified object?  That clearly doesn't apply to the refactoring
>> application, though, unless you're communicating local names to
>> nonlocal computations or using eval, both of which seem like really
>> dubious practices to me.
>> 
>>> So the functionality is bound to an editor and anyone using another
>>> editor would just see a weird string?
>> 
>> No, they'd see an ordinary string.  Editors would use heuristics to
>> recognize strings like f"the value of expression is {expression}".  I
>> do stuff like this in Emacs all the time ad hoc, Chris is just
>> suggesting that some editors/IDEs would provide a more powerful and
>> accurate facility.  I see while I was composing this Bruce Leban came
>> up with a very plausible convention, too.
>> 
>>> Use cases are mostly bug-free refactoring,
>> 
>> But the refactoring is very "meta" in the sense that you're creating a
>> string that refers to the name of an object.  You either need an
>> external agent or computation which would be confused if the name were
>> incorrect, or to be using eval() for this to be an actual refactoring.
>> All of this seems very "code smelly" to me.  If you're refactoring
>> this automatically, you're doing it wrong. ;-)
>> 
>> I don't see any use case that f-string '=' doesn't satisfy well enough
>> to make a new builtin pseudo-function[1] justifiable.
>> 
>>> E.g. would it be faster than `Class.__name__`?
>> 
>> You're working with strings expressing code.  If it's about speed,
>> there's got to be a better way.
>> 
>> 
>> 
>> Footnotes: 
>> [1]  In C#, 'nameof' is first looked up as a function reference, and
>> if found that is called.  Otherwise the compiler macro is used.
>> 
> 

___
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/DSDPXKMPHAILIGWU5S45YXPPHH5KQRIH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revise using the colon ( : )

2023-09-20 Thread Dom Grigonis

My bad, you have pointed to ambiguity accurately.

Thanks for taking time to correct me.

Regards,
DG

> On 20 Sep 2023, at 16:09, Celelibi  wrote:
> 
> 2023-09-12 7:10 UTC+02:00, Dom Grigonis :
>> I don’t think your example depicts the ambiguity well.
>> 
>> 1. is the correct parsing of the Original1, 2. is the correct parsing of
>> Original2 and 3. is not correct for either of those.
>> 
>> Original1
>>> while a < b (x := c) - 42
>> Original2
>>> while a < b(x := c) - 42
> 
> They're the same. AFAIK `foo(...)` and `foo (...)` are parsed exactly
> the same way. A space in this place is irrelevant. And it's unlikely
> to change in the next few decades.
> 
>> 
>> 1. In this case, it’s obviously this one
>>> while a < b:
>>>   (x := c) - 42
> 
> Why tho? Why would this one be more obvious than the other
> alternatives? What would be the rules to decide? If I may quote the
> PEP 20:
>> In the face of ambiguity, refuse the temptation to guess.
> 
>> 2. In here your removed the space, which is not ambiguity, but rather
>> mistype
> Again, the space in this place doesn't matter. I removed it to show
> more explicitely how it could be parsed.
> 
>> 3. Same as in 2. But also, this is not an option, because if there was no
>> indent on the next line, then body exists. So this is incorrect.
>>> Or:
>>> while a < b(x := c) - 42:
>>>   # ???
> 
> I actually think this is the better parsing of the three: a SyntaxError.
> 
> 
> Celelibi
> ___
> 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/WSOJIXRMEYCNQGVNABPCJJ4S23PB6X4L/
> 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/RQBYA3FMKBL6OXZWJ55XAT26CKOPH7EU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revise using the colon ( : )

2023-09-20 Thread Celelibi

2023-09-12 7:10 UTC+02:00, Dom Grigonis :
> I don’t think your example depicts the ambiguity well.
>
> 1. is the correct parsing of the Original1, 2. is the correct parsing of
> Original2 and 3. is not correct for either of those.
>
> Original1
>> while a < b (x := c) - 42
> Original2
>> while a < b(x := c) - 42

They're the same. AFAIK `foo(...)` and `foo (...)` are parsed exactly
the same way. A space in this place is irrelevant. And it's unlikely
to change in the next few decades.

>
> 1. In this case, it’s obviously this one
>> while a < b:
>>(x := c) - 42

Why tho? Why would this one be more obvious than the other
alternatives? What would be the rules to decide? If I may quote the
PEP 20:
> In the face of ambiguity, refuse the temptation to guess.

> 2. In here your removed the space, which is not ambiguity, but rather
> mistype
Again, the space in this place doesn't matter. I removed it to show
more explicitely how it could be parsed.

> 3. Same as in 2. But also, this is not an option, because if there was no
> indent on the next line, then body exists. So this is incorrect.
>> Or:
>> while a < b(x := c) - 42:
>># ???

I actually think this is the better parsing of the three: a SyntaxError.


Celelibi
___
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/WSOJIXRMEYCNQGVNABPCJJ4S23PB6X4L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-18 Thread Dom Grigonis

Thank you Jonathan,

This is indeed helpful, I have completely forgotten about these.

However, in my case, defaults are not callable defaults, but rather default 
values preset at a higher level object and it has little to do with function 
defaults.

Although, I think it is possible to reshape the problem to use the mechanism 
you have provided. For example:

class Node:
def __init__(self, a=1):
self.a = a

class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_cls = Node
self.node_cls.__init__.__defaults__ = (a,)
# The issue, however is that it modifies the constructor from outside
# And it changes the Node class for the whole Runtime
# copy, deepcopy do not work here either
# Construct the node class programatically by inheritance leads to the 
same issue:
# self.node_cls = type('Node2', (Node,), {})
# self.node_cls.__init__.__defaults__ = (a,)
self.nodes = list()

def new_node(self, *args, **kwds):
node = self.node_cls(*args, **kwds)
self.nodes.append(node)
return node

c = Container(a=2)
print(c.new_node().a)   # 2
print(c.new_node(3).a)  # 3
print(Node().a) # 2
If you could provide an example, which solves the same issue that I have 
presented in a more elegant manner than simple dictionary storage, I would 
appreciate it.

Kind regards,
DG


> On 18 Sep 2023, at 17:24, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> In your original post you used your proposed addition to write code that 
> provides a way of handling defaults different from the standard mechanism, 
> and perhaps in your opinion better.
> 
> The following example tells us something about defaults mechanism already 
> provided by Python:
> 
> >>> def f(a, b=1, c=2): return a, b, c
> ... 
> >>> f(0)
> (0, 1, 2)
> >>> f.__defaults__
> (1, 2)
> >>> f.__defaults__ = (0, 1, 2)
> >>> f()
> (0, 1, 2)
> >>> f.__defaults__ = (2, 1, 0)
> >>> f()
> (2, 1, 0)
> 
> I am suspicious of your example in your original post because it does not 
> explicitly consider the possibilities already provided by Python for changing 
> default values on the fly.
> 
> I hope this helps.
> 
> Jonathan

___
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/MUGEZV47DCD7BO43JZ7AFFAGGKETWM5D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-18 Thread Jonathan Fine

Hi Dom

In your original post you used your proposed addition to write code that
provides a way of handling defaults different from the standard mechanism,
and perhaps in your opinion better.

The following example tells us something about defaults mechanism already
provided by Python:

>>> def f(a, b=1, c=2): return a, b, c
...
>>> f(0)
(0, 1, 2)
>>> f.__defaults__
(1, 2)
>>> f.__defaults__ = (0, 1, 2)
>>> f()
(0, 1, 2)
>>> f.__defaults__ = (2, 1, 0)
>>> f()
(2, 1, 0)

I am suspicious of your example in your original post because it does not
explicitly consider the possibilities already provided by Python for
changing default values on the fly.

I hope this helps.

Jonathan
___
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/VAFITY5GD2JF7TCDDH356226ZUMP4IJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-17 Thread Dom Grigonis

Thank you Jonathan,

Could you please elaborate on your suspicion, that my proposed addition will 
make bad code easier to write?

It would be nice if you provided example, where there is a pattern using my 
proposed addition, where similar badness of code cant be achieved using already 
existing python constructs.

Also, some explanation why would you deem it as bad code would be helpful.

Regards,
Dominykas

Now is better than never.
Although never is often better than *right* now.
While deferred evaluation is the happy midst of this temporal confusion.


> On 17 Sep 2023, at 11:47, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> To support your proposal you provided an example. Well done for providing 
> evidence to support your idea. Doing that makes the discussion more 
> productive.
> 
> I'm going to use the words 'good' and 'bad', but with two provisos. The first 
> is that they are judgemental, and often judgement is little more than 
> personal opinion presented in an objective language. The second is that 
> 'good' and 'bad' depend on context. The usual C-Python is not good at writing 
> code where high performance is critical (but is fairly good at linking to 
> external libraries that do provide high performance). However, often 
> high-performance is of no importance when writing a prototype. For prototypes 
> the forces are quite different than for production.
> 
> With these provisos, a major purpose of a programming language is to make 
> good code easier to write, and bad code harder to write. Hence the importance 
> of you providing a coding example to support your idea. And also my request 
> that you provide more information about the example code you kindly provided.
> 
> Based on your example, I suspect that your proposed addition will make bad 
> code easier to write. However, we don't need to discuss that now. I suggest 
> that for your proposal to gain support an example of how it makes good code 
> easier to write would be helpful. And also if you wish an example of how it 
> makes bad code harder to write.
> 
> Please note that my use of 'good' and 'bad' are subject to the provisos 
> mentioned earlier.
> 
> I hope this helps.
> 
> Jonathan
> 
> 
> 
> 
> 

___
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/A4EG7HT2SNUJ5UF2LZ3T2P2L6AUH6IV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-17 Thread Jonathan Fine

Hi Dom

To support your proposal you provided an example. Well done for providing
evidence to support your idea. Doing that makes the discussion more
productive.

I'm going to use the words 'good' and 'bad', but with two provisos. The
first is that they are judgemental, and often judgement is little more than
personal opinion presented in an objective language. The second is that
'good' and 'bad' depend on context. The usual C-Python is not good at
writing code where high performance is critical (but is fairly good at
linking to external libraries that do provide high performance). However,
often high-performance is of no importance when writing a prototype. For
prototypes the forces are quite different than for production.

With these provisos, a major purpose of a programming language is to make
good code easier to write, and bad code harder to write. Hence the
importance of you providing a coding example to support your idea. And also
my request that you provide more information about the example code you
kindly provided.

Based on your example, I suspect that your proposed addition will make bad
code easier to write. However, we don't need to discuss that now. I suggest
that for your proposal to gain support an example of how it makes good code
easier to write would be helpful. And also if you wish an example of how it
makes bad code harder to write.

Please note that my use of 'good' and 'bad' are subject to the provisos
mentioned earlier.

I hope this helps.

Jonathan
___
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/UOXPJVTGSF2FAUBALMHKCWYWNGT73QV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

Hi Jonathan,

I wasn’t writing anything specialised on handling of defaults. My initial 
example pretty much covers it.

What defaults handler of python are you talking about?

This proposal is more about convenient refactoring and keeping things nicely 
synchronised where variable name and string value are preferred to be kept in 
sync. The default handling is just one such case. It can also be useful in 
logging.

I can make my initial example a bit more clear and closer to what actually 
happened:

class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_defaults[f'{=a}'] = a
self.nodes = list()

def new_node(self, a=None):
if a is None:
a = self.node_defaults.get(f'{=a}')
node = Node(a)
self.nodes.append(a)
return node

class Node:
def __init__(self, a):
self.a = a
Currently, I just store keys as close to the object that finally uses the value 
as possible. So to achieve similar overall effect. And I am not saying that the 
above is better than below. IMO, it all depends on individual case. My point is 
that it might be nice to have. And I think the reasoning for such thing goes 
more along the lines of convenience, rather than if similar result can be 
achieved in different ways.
class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_defaults[Node.K_A] = a
self.nodes = list()

def new_node(self, a=None):
if a is None:
a = self.node_defaults.get(Node.K_A)
node = Node(a)
self.nodes.append(a)
return node

class Node:
K_A = 'a'

def __init__(self, a):
self.a = a

Regards,
DG

—What can not be solved by force, can be solved by deferred evaluation —

> On 16 Sep 2023, at 21:27, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> In your original post you said you're writing some code to improve handling 
> of defaults (perhaps only in some situations). You also said that the feature 
> you're suggesting would make your improved default handler easier to write.
> 
> Python already handles default values at least fairly well in many 
> situations. Please would you provide at least one example of how your 
> proposed default handler would be better than that already provided by Python.
> 
> Please don't worry about the implementation. Please focus on the syntax and 
> semantics and comparison with what Python does.
> 
> I will value your response to my request more highly if it shows that you 
> have a clear understanding of Python's present behaviour. I'd also welcome 
> any example you provide of weaknesses in Python's present behaviour.
> 
> I hope this helps.
> 
> Jonathan

___
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/JNDAOK6EPYAUJZA5DDG6R2S3AAKOY62J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-16 Thread Jonathan Fine

Hi Dom

In your original post you said you're writing some code to improve handling
of defaults (perhaps only in some situations). You also said that the
feature you're suggesting would make your improved default handler easier
to write.

Python already handles default values at least fairly well in many
situations. Please would you provide at least one example of how your
proposed default handler would be better than that already provided by
Python.

Please don't worry about the implementation. Please focus on the syntax and
semantics and comparison with what Python does.

I will value your response to my request more highly if it shows that you
have a clear understanding of Python's present behaviour. I'd also welcome
any example you provide of weaknesses in Python's present behaviour.

I hope this helps.

Jonathan
___
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/DVRIWWCTLMMZI74LQAXMPJLO2S3FZJC3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

Agree, all good points.
f'{=expr}'.split('.')[-1]
Does take care of all cases and `nameof` has no additional use over it.

It seems that `nameof` is out of question.

DG

> On 16 Sep 2023, at 19:50, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> print(f'{=A.a}')# 'A.a'
>> print(nameof(A.a))  # 'a'
> 
> I see that's the C# semantics, but it's not obvious to me why the
> ambiguity introduced is worth emulating.  The important aspect of the
> proposed 'nameof' operator is that its argument can be validated by
> the compiler and unambiguously recognized by refactoring tools.  But
> once it's a string, it loses those advantages.  Why not be unambiguous?
> 
> I don't think that the tricks recommended (ie, typeof) to retrieve a
> fully-qualified name in C# would be unambiguous in Python.
> 
> Also, Python's f-string '=' operator handles a broad variety of
> expressions, not just attribute references.  This has been useful to
> me more often than bare names and attribute references.
> 
>> Both [member name and full reference] seem useful to me.
> 
> What am I missing?  When would you want the member name only but
> "nameof().split('.')[-1]" would not do?
> 
> Also, are there use cases for the proposed nameof other than a more
> flexible f-string '='?  Ie, where only the str is wanted, not the
> str-ified object?  That clearly doesn't apply to the refactoring
> application, though, unless you're communicating local names to
> nonlocal computations or using eval, both of which seem like really
> dubious practices to me.
> 
>> So the functionality is bound to an editor and anyone using another
>> editor would just see a weird string?
> 
> No, they'd see an ordinary string.  Editors would use heuristics to
> recognize strings like f"the value of expression is {expression}".  I
> do stuff like this in Emacs all the time ad hoc, Chris is just
> suggesting that some editors/IDEs would provide a more powerful and
> accurate facility.  I see while I was composing this Bruce Leban came
> up with a very plausible convention, too.
> 
>> Use cases are mostly bug-free refactoring,
> 
> But the refactoring is very "meta" in the sense that you're creating a
> string that refers to the name of an object.  You either need an
> external agent or computation which would be confused if the name were
> incorrect, or to be using eval() for this to be an actual refactoring.
> All of this seems very "code smelly" to me.  If you're refactoring
> this automatically, you're doing it wrong. ;-)
> 
> I don't see any use case that f-string '=' doesn't satisfy well enough
> to make a new builtin pseudo-function[1] justifiable.
> 
>> E.g. would it be faster than `Class.__name__`?
> 
> You're working with strings expressing code.  If it's about speed,
> there's got to be a better way.
> 
> 
> 
> Footnotes: 
> [1]  In C#, 'nameof' is first looked up as a function reference, and
> if found that is called.  Otherwise the compiler macro is used.
> 

___
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/K4QOZTA7B6VK324UHSSRXNF262VTOLLN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-16 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > print(f'{=A.a}')# 'A.a'
 > print(nameof(A.a))  # 'a'

I see that's the C# semantics, but it's not obvious to me why the
ambiguity introduced is worth emulating.  The important aspect of the
proposed 'nameof' operator is that its argument can be validated by
the compiler and unambiguously recognized by refactoring tools.  But
once it's a string, it loses those advantages.  Why not be unambiguous?

I don't think that the tricks recommended (ie, typeof) to retrieve a
fully-qualified name in C# would be unambiguous in Python.

Also, Python's f-string '=' operator handles a broad variety of
expressions, not just attribute references.  This has been useful to
me more often than bare names and attribute references.

 > Both [member name and full reference] seem useful to me.

What am I missing?  When would you want the member name only but
"nameof().split('.')[-1]" would not do?

Also, are there use cases for the proposed nameof other than a more
flexible f-string '='?  Ie, where only the str is wanted, not the
str-ified object?  That clearly doesn't apply to the refactoring
application, though, unless you're communicating local names to
nonlocal computations or using eval, both of which seem like really
dubious practices to me.

 > So the functionality is bound to an editor and anyone using another
 > editor would just see a weird string?

No, they'd see an ordinary string.  Editors would use heuristics to
recognize strings like f"the value of expression is {expression}".  I
do stuff like this in Emacs all the time ad hoc, Chris is just
suggesting that some editors/IDEs would provide a more powerful and
accurate facility.  I see while I was composing this Bruce Leban came
up with a very plausible convention, too.

 > Use cases are mostly bug-free refactoring,

But the refactoring is very "meta" in the sense that you're creating a
string that refers to the name of an object.  You either need an
external agent or computation which would be confused if the name were
incorrect, or to be using eval() for this to be an actual refactoring.
All of this seems very "code smelly" to me.  If you're refactoring
this automatically, you're doing it wrong. ;-)

I don't see any use case that f-string '=' doesn't satisfy well enough
to make a new builtin pseudo-function[1] justifiable.

 > E.g. would it be faster than `Class.__name__`?

You're working with strings expressing code.  If it's about speed,
there's got to be a better way.

Footnotes: 
[1]  In C#, 'nameof' is first looked up as a function reference, and
if found that is called.  Otherwise the compiler macro is used.

___
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/XC7QRRJN7DSF2AKDCMZWANQVOPJM65QI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

If it is done at a tool level, it is not a robust solution. The fact that it 
can be done in a tool doesn’t mean that it is the optimal solution. Having it 
done at python level could be a simpler solution and provide benefits to all of 
the tools, without needing for editor logic to deviate from python logic. Also, 
it eliminates inconsistencies and coding styles which would arise if each 
editor was to implement its own method.

Besides, editor tool implementation doesn’t offer all of the benefits, which on 
top of the refactoring benefits offer:
a) validity check in both f-strings and nameof().
b) nameof(‘a.b’) = ‘b’, which is not a straight forward equality.

Regarding f-strings.
I think the fact that it is already being done in python justifies its validity:
a = 1
print(f'{a=}')
and everybody is happy using it instead of:
print(f'a={a}')
If the argument that this sort of thing should be done in editor is deemed to 
be a valid one, then the `f’{expr=}’` expression was a mistake. However, the 
way I see it, it is very useful addition and I do use it a fair bit.

What I am proposing is nothing new, but rather a small part of what is already 
there, arguably bringing it closer to modular completeness:
print(f'{a}')
print(f'{a=}')
print(f'{=a}')
It’s the same as “I can draw square, square and circle, but I cant draw a 
circle without a square”.

It seems like a non-invasive addition, not causing any problems, not cluttering 
namespaces and how I see it, has just the right place for it and its syntax 
space is very unlikely to be used for anything else.

I do not see a big cost in either implementation or maintenance. The question 
is whether benefits justify that cost.

DG

> On 16 Sep 2023, at 18:37, Bruce Leban  wrote:
> 
> If the goal is to create a syntax that allows tools to recognize names in 
> strings, there is a simple solution which requires tool changes only, for 
> example:
> 
> raise Exception('The field ' + ((('size'))) + ' must be a positive integer in 
> ' + ((('Sample.widget'
> 
> Python already treats triple parenthesized strings properly and all you need 
> to do is modify tools to recognize that syntax. It's even backwards 
> compatible, visually striking, and doesn't prevent compile-time string 
> folding.
> 
> --- Bruce
> 
> ___
> 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/OXEOPXY7BCFB4P7XKEAM3UN5XU6RIHJP/
> 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/TRRMMUCYRJVAORM4RFDJFXGKP53ZVQ47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-16 Thread Bruce Leban

If the goal is to create a syntax that allows tools to recognize names in
strings, there is a simple solution which requires tool changes only, for
example:

raise Exception('The field ' + ((('size'))) + ' must be a positive integer
in ' + ((('Sample.widget'

Python already treats triple parenthesized strings properly and all you
need to do is modify tools to recognize that syntax. It's even backwards
compatible, visually striking, and doesn't prevent compile-time string
folding.

--- Bruce

>
>
___
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/OXEOPXY7BCFB4P7XKEAM3UN5XU6RIHJP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-16 Thread Chris Angelico

On Sat, 16 Sept 2023 at 19:48, Jeff Allen  wrote:
> It needs language (parser) support because it does what you identified early 
> on: "take whatever is given and put it in quotes", where "whatever is given" 
> is the text of the expression only available at run-time.
>

I didn't say "and put it in quotes". I said "return the text string unchanged".

This is, fundamentally, a problem of an editing tool. Teach the tool
that a string literal inside nameof() should be parsed for variables.
This is no harder than taking the program source and parsing it for
variables - in fact, it's the exact same thing, just done a second
time.

I have done exactly this sort of parsing, using the Python ast module.
It's not difficult.

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/IRT4UNFBKPEP6U2PENVGQEAQQQ3WSBW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

2023-09-16 Thread Jeff Allen


On 16/09/2023 11:33, Dom Grigonis wrote:


It works already with existing tools that will treat "nameof(a+b)" as 
a function call, which it is syntactically but not semantically, so 
renaming b to c will now produce the string "a+c". I think my IDE 
does offer to do this with variable names in strings and comments, 
but it produces so many false hits I don't enjoy using the feature.


So the functionality is bound to an editor and anyone using another 
editor would just see a weird string?

After several similar editor features things could get very confusing.

No, the opposite. By "works now", I meant to say that if a nameof() 
pseudo-function were added to the Python language, existing tools would 
not have to change, because they would treat it as a call. This does 
scratch an itch (in renaming) by removing the need to guess or ask the 
human whether a given string is a variable name.


I'm not convinced this feature is widely useful.


So what is the general procedure for determining it?


1. Compelling use cases here or (better) on the Dicourse counterpart
   .
2. Community and core dev acclamation as a Good Thing.
3. Willigness to implement and maintain.

--

Jeff Allen
___
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/LUDUIZB7VEYPUQWIT2YGYV3ECKMZ2V4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself