On Wed, Jun 23, 2021 at 6:49 PM Brendan Barnwell <brenb...@brenbarn.net> wrote: > There aren't many things in Python that work this way. Future imports > are the main one, but those are rare (and rightly so). The import > machinery itself provides some possibility for this (as used by stuff > like macropy) but is mostly not used for such things (and again rightly so).
Future imports are generally about syntax. They only very seldom affect execution, and when they do, there has to be a mechanic like a flag on the code object (as generator_stop does). In order to maintain compatibility between modules with and without the directive, the execution has to be independent of that. (For example, Py2's "from __future__ import division" changes the bytecode created from the division operator, and barry_as_FLUFL generates the same code for "<>" that normal mode generates for "!=".) There's no fundamental problem with having things defined per-module. You can override the print function for the current module, and other modules aren't affected. I think that per-module operator overloading would be extremely confusing, but mainly because type-free operator overloading is an inherently confusing thing to do. Python allows an object to override operators, and C++ allows you to write a function called "operator+" that takes two arguments, but the types of those arguments is what makes everything make sense. That usually removes the problem of recursion because the implementation of operator+(my_obj, my_obj) is usually going to require addition of simpler types like integers. 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/VYKWJHEO5MCKUU6ISORO6IHXFL4TZ6ZZ/ Code of Conduct: http://python.org/psf/codeofconduct/
