[Python-ideas] User-defined literals

[Andrew Barnert]

On Jun 4, 2015, at 14:05, Guido van Rossum <guido at python.org> wrote:
> 
> OK, you can attribute that to lousy docs. The intention is that builtin types are immutable.

I can go file bugs against those other implementations, but first, what's the rationale?

The ABC PEP, the numbers PEP discussion, and the type/class unification tutorial all use the same reason: In CPython, different interpreters in the same memory space (as with mod_python) share the same built-in types. From the numbers discussion, it sounds like this was the only reason to reject the idea of just patching float.__bases__.

But most other Python implementations don't have process-wide globals like that to worry about; patching int in one interpreter can't possibly affect any other interpreter.

"Because CPython can't do it, nobody else should do it, to keep code portable" might be a good enough rationale for something this fundamental, but if that's not the one you're thinking of, I don't want to put those words in your mouth.

>> On Thu, Jun 4, 2015 at 1:18 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> On Jun 4, 2015, at 12:49, Guido van Rossum <guido at python.org> wrote:
>>> 
>>>> On Thu, Jun 4, 2015 at 12:14 PM, Andrew Barnert via Python-ideas <python-ideas at python.org> wrote:
>>>> But this isn't actually true. That BINARY_ADD opcode looks up the addition method at runtime and calls it. And that means that if you monkeypatch complex.__radd__, your method will get called.
>>> 
>>> Wrong. You can't moneypatch complex.__radd__. That's a feature of the language.
>> 
>> I may well have missed it, but I went looking through the Built-in Types library documentation, the Data Model and other chapters of the language reference documentation, and every relevant PEP I could think of, and I can't find anything that says this is true. 
>> 
>> The best I can find is the rationale section for PEP 3119 saying "there are good reasons to keep the built-in types immutable", which is why PEP 3141 was changed to not require mutating the built-in types. But "there are good reasons to allow implementations to forbid it" isn't the same thing as "all implementations must forbid it".
>> 
>> And at least some implementations do allow it, like Brython and one of the two embedded pythons. (And the rationale in PEP 3119 doesn't apply to them--Brython doesn't share built-in types between different Python interpreters in different browser windows, even if they're in the same address space.)
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150604/2a22d165/attachment-0001.html>