On Mon, Sep 28, 2020 at 12:03 PM Brett Cannon wrote:
> And the code that makes this happen is (I think)
> https://github.com/python/cpython/blob/6f8c8320e9eac9bc7a7f653b43506e75916ce8e8/Objects/abstract.c#L797-L798
> .
>
Ah, that's much clearer than all the English words written so far here. :-)
On Mon, Sep 28, 2020 at 7:23 AM Marco Sulla
wrote:
> On Mon, 28 Sep 2020 at 13:56, Nick Coghlan wrote:
> > For usage, whether something is a macro or not should either be
> irrelevant (when they're used as a more powerful function call or
> > decorator), or else entirely obvious from the way you
On Sun, Sep 27, 2020 at 9:56 PM Guido van Rossum wrote:
> On Sun, Sep 27, 2020 at 5:58 PM Brett Cannon wrote:
>
>>
>>
>> On Sun, Sep 27, 2020 at 2:58 PM Guido van Rossum
>> wrote:
>>
>>> Hm... IIRC the reason why we did this for `__r*__` is because the more
>>> derived class might want to retur
Since I don't see it linked anywhere here: this was discussed a few years ago
at https://bugs.python.org/issue30140.
Eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.pytho
On Mon, 28 Sep 2020 at 13:56, Nick Coghlan wrote:
> For usage, whether something is a macro or not should either be irrelevant
> (when they're used as a more powerful function call or
> decorator), or else entirely obvious from the way you use it (when they're
> defining a new pseudo-statement),
On Mon., 28 Sep. 2020, 1:22 am Marco Sulla,
wrote:
> I like this, but IMHO adding a character at the end of the macro name
> (the exclamation mark), lowers readability.
> I'd prefer a character at the start of the macro, a character that is
> not used as an unary operator.
>
For usage, whether s
