1

I got the hint that it's possible to overwrite Python built-in functions to be used only for a small code segment.

Example:

import contextlib

@contextlib.contextmanager
def tuple_builtins_handler():
    original_eq = tuple.__eq__
    try:
        tuple.__eq__ = my_eq  # defined elsewhere
        yield
    finally:
        tuple.__eq__ = original_eq

I get a

TypeError: cannot set '__eq__' attribute of immutable type 'tuple'.

Is there any alternative?

I could define a class but that seems not to be the right way.

  1. I want to restrict 'my' tuples to two elements of type integer, so in the strict oo-sense this is not what is meant bei inheritance or subclassing.
  2. I want to use this in some sections of my code, so not for public usage, and therefore there's no need for using a new class which sems to be a kind of overkill.
  3. I still think that overwriting (and restoring) the built-in functions is the least expensive way.
TomS
  • 216
  • 1
  • 7
  • I explained why I don't want to use subclassing, but the question is closed with a hint towards a disputable answer proposing subclassing ... – TomS Mar 13 '23 at 15:07
  • 1
    The context manager only addresses the scope of the change, not the ability to make the change itself. Rather than trying to patch the `tuple` type, why not just define your own type to use? – chepner Mar 13 '23 at 15:16
  • From the very first sentence of the accepted answer on the linked dupe: "You can't directly add the method to the original type". You can't do that, end of story. Find another way. If you don't like it that's cool, but don't blame us: we didn't design it that way. – Jared Smith Mar 13 '23 at 15:16
  • Just because you think it is overkill does not mean it is. The whole *point* of a class is to define behavior. If the `tuple` class doesn't define the behavior you want, then it's the wrong type to represent your data. – chepner Mar 13 '23 at 15:19
  • (Besides, create a new class is precisely what `contextlib.contextmanager` *does*, though it provides `__enter__` and `__exit__` methods rather than wrap your data.) – chepner Mar 13 '23 at 15:22
  • There are two questions: 1) What is the __cheapest__ way to replace some of the tuple-functions? 2) What is - from a conceptional perspective - a __clean__ way to do that? Forget about (1); if it's not possible in the way I thought it is, then I'll go for subclassing of tuples. (2) is interesting b/c I am still convinced that the cheapest way would be to __reuse__ the tuple implementation but __not__ call it inheritance therefore __not__ using subclassing . But (2) would be another question; so just close this one; it's ok. – TomS Mar 13 '23 at 17:02
  • @TomS To the point 3. in your question: No, it's not. Modifying builtins is an error-prone, expensive operation that is technically possible, but *will* cause problems. For point 1. in your question: There is no real precedent for python classes strictly following OO ideals. Just subclass tuple and restrict what it can do. – MegaIng Mar 21 '23 at 03:15
  • Thanks, that‘s what I‘ve done. Works fine for me but is something I wouldn’t publish. There are restrictions in the __new__(), I have to overwrite the __mul__() which is forbidden … – TomS Mar 22 '23 at 05:29

0 Answers0