[Python-Dev] Re: PEP 638: Syntactic macros

2020-09-29 Thread Mark Shannon 

Hi,

On 29/09/2020 1:43 am, Emily Bowman wrote:
On Mon, Sep 28, 2020 at 7:23 AM Marco Sulla 
mailto:[email protected]>> wrote:


On Mon, 28 Sep 2020 at 13:56, Nick Coghlan mailto:[email protected]>> 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), so it doesn't make
sense to
 > emphasize the syntactic marker too much.

IMHO `import!` can be easily confused with `import`, even with a
monospace font. An alternative is that macro must have a name
different from keywords (so you will have macro_import!, for example),
even if I'd prefer my first proposal (maybe something like %import).


I think the whole point is that import! won't be obvious unless you're 
looking for it, and those macros won't be obvious unless you're looking 
for them. They're meant to blend in rather than stand out.



My assumption is that almost everyone uses an editor that has syntax 
highlighting. Macros will stand out just as much as the users of those 
editors think they should.


Personally, I think they should be fairly prominent.
But don't let me stop configuring your editor as you choose :)

Cheers,
Mark.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/HRRT34FXZ52I3YUNBLL3FA4NOTO3Q2YB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why do binary arithmetic operators care about differing method implementations but rich comparisons don't?

2020-09-29 Thread Brett Cannon 
Thanks for the explanation! And I will look at updating my blog post.

On Mon, Sep 28, 2020 at 9:14 PM Guido van Rossum  wrote:

> 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.
> :-) Let me go over this function (binary_op1()) for subtraction, the
> example from your blog.
>
> One piece of magic is that there are no separate `__sub__` and `__rsub__`
> implementations at this level -- the `tp_as_number` struct just has a slot
> named `nb_subtract` that takes two objects and either subtracts them or
> returns NotImplemented.
>
> This means that (**at this level**) there really is no point in calling
> `__rsub__` if the lhs and rhs have the same type, because it would
> literally just call the same `nb_subtract` function with the same arguments
> a second time.
>
> And if the types are different but the functions in `nb_subtract` are
> still the same, again we'd be calling the same function with the same
> arguments twice.
>
> The `nb_subtract` slot for Python classes dispatches to either `__sub__`
> or `__rsub__` in a complicated way. The code is SLOT1BINFULL in
> typeobject.c, which echoes binary_op1():
> https://github.com/python/cpython/blob/b0dfc7581697f20385813582de7e92ba6ba0105f/Objects/typeobject.c#L6340-L6383
>
> That's some macro!
>
> Now, interestingly, this macro may call *both* `left.__sub__(right)` and
> `right.__rsub__(left)`. That is surprising, since there's also logic to
> call left's nb_subtract and right's nb_subtract in binary_op1(). What's up
> with that? Could we come up with an example where `a-b` makes more than two
> calls? For that to happen we'd have to trick binary_op1() into calling
> both. But I think that's impossible, because all Python classes have the
> same identical function in nb_subtract (the function is synthesized using
> SLOT1BIN -> SLOT1BINFULL), and in that case binary_op1() skips the second
> call (the two lines that Brett highlighted!). So we're good here.
>
> But maybe here we have another explanation for why binary_op1() is careful
> to skip the second call. (The slot function duplicates this logic so it
> will only call `__sub__` in this case.)
>
> Since rich comparison doesn't have this safeguard, can we trick *that*
> into making more than two calls? No, because the "reverse" logic
> (`self.__lt__(other)` -> `other.__gt__(self)` etc.) is only implemented
> once, in do_richcompare() in abstract.c. The slot function in typeobject.c
> (slot_tp_richcompare()) is totally tame.
>
> So the difference goes back to the design at the C level -- the number
> slots don't have separate `__sub__` and `__rsub__` implementations (the C
> function in nb_subtract has no direct way of knowing if it was called on
> behalf of its first or second argument), and the complications derive from
> that. The rich comparison slot has a clear `op` flag that always tells it
> which operation was requested, and the implementation is much saner because
> of it.
>
> So yes, in a sense the difference is because rich comparison is much newer
> than binary operators in Python -- binary operators are still constrained
> by the original design, which predates operator overloading in user code
> (i.e. `__sub__` and `rsub__`). But it was not a matter of forgetting
> anything -- it was a matter of better design.
>
> (Brett, maybe this warrants an update to your blog post?)
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LXQNM6H36TEGNW3CBUPTYL7EYFXGEAUC/
Code of Conduct: http://python.org/psf/codeofconduct/