71

Why I have problem creating a class inheriting from str (or also from int)

class C(str):
   def __init__(self, a, b):
     str.__init__(self,a)
     self.b = b

C("a", "B")

TypeError: str() takes at most 1 argument (2 given)

the same happens if I try to use int instead of str, but it works with custom classes. I need to use __new__ instead of __init__? why?

Ruggero Turra
  • 16,929
  • 16
  • 85
  • 141

6 Answers6

111
>>> class C(str):
...     def __new__(cls, *args, **kw):
...         return str.__new__(cls, *args, **kw)
... 
>>> c = C("hello world")
>>> type(c)
<class '__main__.C'>

>>> c.__class__.__mro__
(<class '__main__.C'>, <type 'str'>, <type 'basestring'>, <type 'object'>)

Since __init__ is called after the object is constructed, it is too late to modify the value for immutable types. Note that __new__ is a classmethod, so I have called the first parameter cls

See here for more information

>>> class C(str):
...     def __new__(cls, value, meta):
...         obj = str.__new__(cls, value)
...         obj.meta = meta
...         return obj
... 
>>> c = C("hello world", "meta")
>>> c
'hello world'
>>> c.meta
'meta'
John La Rooy
  • 295,403
  • 53
  • 369
  • 502
14

When you instantiate a class, the arguments that you pass in, are passed to both the __new__ (constructor) and then to the __init__ (initializer) methods of the class. So if you inherit from a class that has restrictions on number of arguments that may be supplied during instantiation, you must guarantee that neither its __new__, nor its __init__ would get more arguments than they expect to get. So that is the problem that you have. You instantiate your class with C("a", "B"). The interpreter looks for __new__ method in C. C doesn't have it, so python peeps into its base class str. And as it has one, that one is used and supplied with the both arguments. But str.__new__ expects to get only one argument (besides its class object as the first argument). So TypeError is raised. That is why you must extend it in your child class similarly to what you do with __init__. But bear in mind that it must return class instance and that it is a static method (irrespective of whether it is defined with @staticmethod decorator or not) that counts if you use super function.

user2683246
  • 3,399
  • 29
  • 31
  • To verify, try this at the prompt: `>>> str.__init__('abc', 'def')`. This does nothing. However, `>>> str.__new__(str, 'abc', 'def')` throws the exception: `TypeError: str() takes at most 1 argument (2 given)`. This is a bit confusing, because we called `str.__new__(..)` with 3 arguments, not 2. Does this mean that `str.__new__(..)` accepts any number of arguments, but then calls `str(..)`? Probably not, because `str(..)` is going to call `str.__new__(..)` in turn... – Evgeni Sergeev Jul 29 '15 at 12:02
  • @Evgeni: `str` class object doesn't implement `__init__` method at all. Nor does `basestring` (`str`'s base class). `__init__` is inherited directly from `object` and that one accepts any number of arguments. On the contrary `__new__` method is really implemented in `str` and it accepts at most 1 argument beside the first one that must be `str` or its subclass. Try expressions like `>>> '__init__' in str.__dict__` and so on for `__new__`, `basestring` and `object`. – user2683246 Jul 31 '15 at 14:47
  • That's a good way to check which methods are implemented. I'm still a bit confused why I write `str.__new__(str, 'abc', 'def')` and it says I supplied 2 arguments. I count three there. For the example `class C(object):\n @staticmethod \n def m(a): pass`, if I call it like `C.m(1, 2)`, it will say `TypeError: m() takes exactly 1 argument (2 given)` as expected. I guess `__new__` produces a confusing message because `__new__` is special (e.g. you don't need to add the `@staticmethod` when implementing it). – Evgeni Sergeev Aug 15 '15 at 07:51
13

Inheriting built-in types is very seldom worth while. You have to deal with several issues and you don't really get much benefit.

It is almost always better to use composition. Instead of inheriting str, you would keep a str object as an attribute.

class EnhancedString(object):
     def __init__(self, *args, **kwargs):
         self.s = str(*args, **kwargs)

you can defer any methods you want to work on the underlying str self.s manually or automatically using __getattr__.

That being said, needing your own string type is something that should give you pause. There are many classes that should store a string as their main data, but you generally want to use str or unicode (the latter if you're representing text) for general representation of strings. (One common exception is if you have need to use a UI toolkit's string type.) If you want to add functionality to your strings, try if you can to use functions that operate on strings rather than new objects to serve as strings, which keeps your code simpler and more compatible with everyone else's programs.

Mike Graham
  • 73,987
  • 14
  • 101
  • 130
  • yes, this was my first solution, but the problem is that I have some functions that want a string argument (they are C++ functions from a library I can't modify), so with my implementation these functions work using my class as arguments. Can you better explain how to obtain this result using `__getattr__`? – Ruggero Turra Apr 20 '10 at 20:36
  • @wiso, accepting a string as an argument is an underdefined thing. I don't know what your C++ library is like and how it's wrapped, but a wrapper should make it compatible with the right types for the job. Making a new class yourself that no one has ever seen before rather than using *its* string class or *Python's* string class (and it working with that) seems like a strange way to make things work. – Mike Graham Apr 20 '10 at 20:54
  • 2
    @wise, To use `__getattr__` to defer otherwise undefined attributes to a specific attribute in composition is accomplished by code like `def __getattr__(self, name): return getattr(self.s, name)`. Note that this code isn't necessarily recommended, but can work well in some cases; it's often better to manually define the things you want in composition. – Mike Graham Apr 20 '10 at 20:55
  • I have `c_function(char*)`, I can use it in python as `c_function(s)` where `s` is a `str` instance. s represent something, and I want that it has a `name`, a `beautiful_name` and so on. So I have derived a class `C` from `str`, so I can pass an object c of class `C` to `python_function` that for example do `print c.name` and call `c_function(c)` – Ruggero Turra Apr 20 '10 at 21:20
  • 3
    > "Inheriting built-in types is very seldom worth while." That might be true, but not always. Sometimes it's useful to create a "tagged string" type, such as to produce distinct types of string-like tokens from a parser. The problem with it, however, is that (I think) you lose the short-string performance optimization. – blais Jun 08 '14 at 00:46
  • @blais, in that case, composition is still much less error-prone. Inheriting from `str` is a potential source of error, but doesn't actually help you. – Mike Graham Jun 15 '14 at 14:11
  • 3
    I'm not convinced. Can you point out why you think inheriting from str is a potential source of error? Because it's not idiomatic? – blais Jun 21 '14 at 04:09
  • 3
    https://docs.python.org/3/library/collections.html#collections.UserString "The class, UserString acts as a wrapper around string objects. The need for this class has been partially supplanted by the ability to subclass directly from str;" It's not that unidiomatic. – blais Jun 21 '14 at 04:31
  • 2
    @blais, Suppose you do `your_subclass[:5]` or `your_subclass.replace(x, y)`--what does it return? An instance of `str` or an instance of your subclass? This isn't even defined, but in practice it will return `str`. There is no guarantee any which way, and this sort of undefined behavior is a bad thing. – Mike Graham Jun 21 '14 at 14:57
  • 1
    @blais, you should always write code that is as plain as possible and as easy to understand what it does as possible. Subclassing builtins is simply hard to think about, maintain, and use. – Mike Graham Jun 21 '14 at 14:59
7

After carefully reading this, here is another attempt at subclassing str. The change from other answers is creating the instance in the correct class using super(TitleText, cls).__new__ . This one seems to behave like a str whenever it's used, but has allowed me to override a method:

class TitleText(str):
    title_text=""
    def __new__(cls,content,title_text):
        o=super(TitleText, cls).__new__(cls,content)
        o.title_text = title_text
        return o

    def title(self):
        return self.title_text

>>> a=TitleText('name','A nice name')
>>> a
'name'
>>> a[0]
'n'
>>> a[0:2]
'na'
>>> a.title()
'A nice name'

This lets you do slicing and subscripting correctly. What's this for? For renaming the Django application in the admin index page.

  • 1
    Yuck! The fact that your `repr` is deceptive leads to it being unclear that while `a` is a `TitleText`, `a[0]` and `a[0:2]` are str (today, in current versions, as an implementation detail). If you'd written a class without inheriting `str` you could make a much more useful and much less confusing and deceptive thing. – Mike Graham Jun 15 '14 at 14:14
6

Use __new__ in case of immutable types:

class C(str):
    def __new__(cls, content, b):
        return str.__new__(cls, content)

    def __str__(self):
        return str.__str__(self)

a=C("hello", "world")
print a

print returns hello.

Python strings are immutable types. The function __new__ is called to create a new instance of object C. The python __new__ function is basically exists to allow inheritance from immutable types.

zoli2k
  • 3,388
  • 4
  • 26
  • 36
  • `type(C("a", "B"))` -> `NoneType` – Ruggero Turra Apr 20 '10 at 09:04
  • do you try your answer? Now it return '' – Ruggero Turra Apr 20 '10 at 09:19
  • 1
    And have you checked the updates of the post? It was updated according your request. You down-voted after the changes were made. Moreover, in your comment you expected functionality from my code which was not requested in your question (to get __str__() function work for the inherited class)! – zoli2k Apr 20 '10 at 12:32
  • After the first implementation the code returned `NoneType`, after the second it gave `""`. Which not requested functionality? I didn't ask a `__str__` function and it is not necessary, because the class inherited from `str`, see gnibbler answer. Now I can't modify the downvote, I need that you edit your answer. – Ruggero Turra Apr 20 '10 at 14:57
0

The question was already answered above, this is just a tangential observation that may be useful to somebody.

I hit this question when trying to figure out a way to remove a temporary file after the dictionary it was being referred to goes deleted.

The context is a Flask session: the user can upload some files but give up before effectively commit the whole workflow it has to go through to get his/her data into the final destination. Until then, I keep the files in a temporary directory. Let's say the user give up and closes the browser window, I don't want those files lingering around.

Since I keep the temporary path in a Flask session -- which is just a dictionary that eventually goes deleted (e.g, timeout), I can customize a str class to hold the temporary directory address/path, and have its __del__ method handling the temporary directory deletion.

Here it goes:

class Tempdir(str):
    def __new__(cls, *args, **kwargs):
        from tempfile import mkdtemp
        _dir = mkdtemp()
        return super().__new__(cls, _dir)
    def __del__(self):
        from shutil import rmtree
        rmtree(str(self))

Instantiate it in your python interpreter/app:

> d = Tempfile()
> d
'/var/folders/b1/frq3gywj3ljfqrf1yc7zk06r0000gn/T/tmptwa_g5fw'
> 
> import os
> os.path.exists(d)
True

When you exit the interpreter:

$ ls /var/folders/b1/frq3gywj3ljfqrf1yc7zk06r0000gn/T/tmptwa_g5fw
ls: /var/folders/b1/frq3gywj3ljfqrf1yc7zk06r0000gn/T/tmptwa_g5fw: No such file or directory

There you go.

Brandt
  • 5,058
  • 3
  • 28
  • 46