What is the difference between __str__ and __repr__ in Python?
Alex summarized well but, surprisingly, was too succinct.
First, let me reiterate the main points in Alex’s post:
The default implementation is useless (it’s hard to think of one which wouldn’t be, but yeah)
__repr__ goal is to be unambiguous
__str__ goal is to be readable
Container’s __str__ uses contained objects’ __repr__
Default implementation is useless
This is mostly a surprise because Python’s defaults tend to be fairly useful. However, in this case, having a default for __repr__ which would act like:
return "%s(%r)" % (self.__class__, self.__dict__)
would have been too dangerous (for example, too easy to get into infinite recursion if objects reference each other). So Python cops out. Note that there is one default which is true: if __repr__ is defined, and __str__ is not, the object will behave as though __str__=__repr__.
This means, in simple terms: almost every object you implement should have a functional __repr__ that’s usable for understanding the object. Implementing __str__ is optional: do that if you need a “pretty print” functionality (for example, used by a report generator).
The goal of __repr__ is to be unambiguous
Let me come right out and say it — I do not believe in debuggers. I don’t really know how to use any debugger, and have never used one seriously. Furthermore, I believe that the big fault in debuggers is their basic nature — most failures I debug happened a long long time ago, in a galaxy far far away. This means that I do believe, with religious fervor, in logging. Logging is the lifeblood of any decent fire-and-forget server system. Python makes it easy to log: with maybe some project specific wrappers, all you need is a
log(INFO, "I am in the weird function and a is", a, "and b is", b, "but I got a null C — using default", default_c)
But you have to do the last step — make sure every object you implement has a useful repr, so code like that can just work. This is why the “eval” thing comes up: if you have enough information so eval(repr(c))==c, that means you know everything there is to know about c. If that’s easy enough, at least in a fuzzy way, do it. If not, make sure you have enough information about c anyway. I usually use an eval-like format: "MyClass(this=%r,that=%r)" % (self.this,self.that). It does not mean that you can actually construct MyClass, or that those are the right constructor arguments — but it is a useful form to express “this is everything you need to know about this instance”.
Note: I used %r above, not %s. You always want to use repr() [or %r formatting character, equivalently] inside __repr__ implementation, or you’re defeating the goal of repr. You want to be able to differentiate MyClass(3) and MyClass("3").
The goal of __str__ is to be readable
Specifically, it is not intended to be unambiguous — notice that str(3)==str("3"). Likewise, if you implement an IP abstraction, having the str of it look like 192.168.1.1 is just fine. When implementing a date/time abstraction, the str can be "2010/4/12 15:35:22", etc. The goal is to represent it in a way that a user, not a programmer, would want to read it. Chop off useless digits, pretend to be some other class — as long is it supports readability, it is an improvement.
Container’s __str__ uses contained objects’ __repr__
This seems surprising, doesn’t it? It is a little, but how readable would it be if it used their __str__?
[moshe is, 3, hello
world, this is a list, oh I don't know, containing just 4 elements]
Not very. Specifically, the strings in a container would find it way too easy to disturb its string representation. In the face of ambiguity, remember, Python resists the temptation to guess. If you want the above behavior when you’re printing a list, just
print("[" + ", ".join(l) + "]")
(you can probably also figure out what to do about dictionaries.
Summary
Implement __repr__ for any class you implement. This should be second nature. Implement __str__ if you think it would be useful to have a string version which errs on the side of readability.
My rule of thumb: __repr__ is for developers, __str__ is for customers.
Unless you specifically act to ensure otherwise, most classes don't have helpful results for either:
>>> class Sic(object): pass
...
>>> print(str(Sic()))
<__main__.Sic object at 0x8b7d0>
>>> print(repr(Sic()))
<__main__.Sic object at 0x8b7d0>
>>>
As you see -- no difference, and no info beyond the class and object's id. If you only override one of the two...:
>>> class Sic(object):
... def __repr__(self): return 'foo'
...
>>> print(str(Sic()))
foo
>>> print(repr(Sic()))
foo
>>> class Sic(object):
... def __str__(self): return 'foo'
...
>>> print(str(Sic()))
foo
>>> print(repr(Sic()))
<__main__.Sic object at 0x2617f0>
>>>
as you see, if you override __repr__, that's ALSO used for __str__, but not vice versa.
Other crucial tidbits to know: __str__ on a built-on container uses the __repr__, NOT the __str__, for the items it contains. And, despite the words on the subject found in typical docs, hardly anybody bothers making the __repr__ of objects be a string that eval may use to build an equal object (it's just too hard, AND not knowing how the relevant module was actually imported makes it actually flat out impossible).
So, my advice: focus on making __str__ reasonably human-readable, and __repr__ as unambiguous as you possibly can, even if that interferes with the fuzzy unattainable goal of making __repr__'s returned value acceptable as input to __eval__!
__repr__: representation of python object usually eval will convert it back to that object
__str__: is whatever you think is that object in text form
e.g.
>>> s="""w'o"w"""
>>> repr(s)
'\'w\\\'o"w\''
>>> str(s)
'w\'o"w'
>>> eval(str(s))==s
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1
w'o"w
^
SyntaxError: EOL while scanning single-quoted string
>>> eval(repr(s))==s
True
In short, the goal of __repr__ is to be unambiguous and __str__ is to be
readable.
Here is a good example:
>>> import datetime
>>> today = datetime.datetime.now()
>>> str(today)
'2012-03-14 09:21:58.130922'
>>> repr(today)
'datetime.datetime(2012, 3, 14, 9, 21, 58, 130922)'
Read this documentation for repr:
repr(object)
Return a string containing a printable representation of an object. This is the same value yielded by conversions (reverse
quotes). It is sometimes useful to be able to access this operation as
an ordinary function. For many types, this function makes an attempt
to return a string that would yield an object with the same value when
passed to eval(), otherwise the representation is a string enclosed in
angle brackets that contains the name of the type of the object
together with additional information often including the name and
address of the object. A class can control what this function returns
for its instances by defining a __repr__() method.
Here is the documentation for str:
str(object='')
Return a string containing a nicely printable
representation of an object. For strings, this returns the string
itself. The difference with repr(object) is that str(object) does not
always attempt to return a string that is acceptable to eval(); its
goal is to return a printable string. If no argument is given, returns
the empty string, ''.
What is the difference between __str__ and __repr__ in Python?
__str__ (read as "dunder (double-underscore) string") and __repr__ (read as "dunder-repper" (for "representation")) are both special methods that return strings based on the state of the object.
__repr__ provides backup behavior if __str__ is missing.
So one should first write a __repr__ that allows you to reinstantiate an equivalent object from the string it returns e.g. using eval or by typing it in character-for-character in a Python shell.
At any time later, one can write a __str__ for a user-readable string representation of the instance, when one believes it to be necessary.
__str__
If you print an object, or pass it to format, str.format, or str, then if a __str__ method is defined, that method will be called, otherwise, __repr__ will be used.
__repr__
The __repr__ method is called by the builtin function repr and is what is echoed on your python shell when it evaluates an expression that returns an object.
Since it provides a backup for __str__, if you can only write one, start with __repr__
Here's the builtin help on repr:
repr(...)
repr(object) -> string
Return the canonical string representation of the object.
For most object types, eval(repr(object)) == object.
That is, for most objects, if you type in what is printed by repr, you should be able to create an equivalent object. But this is not the default implementation.
Default Implementation of __repr__
The default object __repr__ is (C Python source) something like:
def __repr__(self):
return '<{0}.{1} object at {2}>'.format(
type(self).__module__, type(self).__qualname__, hex(id(self)))
That means by default you'll print the module the object is from, the class name, and the hexadecimal representation of its location in memory - for example:
<__main__.Foo object at 0x7f80665abdd0>
This information isn't very useful, but there's no way to derive how one might accurately create a canonical representation of any given instance, and it's better than nothing, at least telling us how we might uniquely identify it in memory.
How can __repr__ be useful?
Let's look at how useful it can be, using the Python shell and datetime objects. First we need to import the datetime module:
import datetime
If we call datetime.now in the shell, we'll see everything we need to recreate an equivalent datetime object. This is created by the datetime __repr__:
>>> datetime.datetime.now()
datetime.datetime(2015, 1, 24, 20, 5, 36, 491180)
If we print a datetime object, we see a nice human readable (in fact, ISO) format. This is implemented by datetime's __str__:
>>> print(datetime.datetime.now())
2015-01-24 20:05:44.977951
It is a simple matter to recreate the object we lost because we didn't assign it to a variable by copying and pasting from the __repr__ output, and then printing it, and we get it in the same human readable output as the other object:
>>> the_past = datetime.datetime(2015, 1, 24, 20, 5, 36, 491180)
>>> print(the_past)
2015-01-24 20:05:36.491180
#How do I implement them?
As you're developing, you'll want to be able to reproduce objects in the same state, if possible. This, for example, is how the datetime object defines __repr__ (Python source). It is fairly complex, because of all of the attributes needed to reproduce such an object:
def __repr__(self):
"""Convert to formal string, for repr()."""
L = [self._year, self._month, self._day, # These are never zero
self._hour, self._minute, self._second, self._microsecond]
if L[-1] == 0:
del L[-1]
if L[-1] == 0:
del L[-1]
s = "%s.%s(%s)" % (self.__class__.__module__,
self.__class__.__qualname__,
", ".join(map(str, L)))
if self._tzinfo is not None:
assert s[-1:] == ")"
s = s[:-1] + ", tzinfo=%r" % self._tzinfo + ")"
if self._fold:
assert s[-1:] == ")"
s = s[:-1] + ", fold=1)"
return s
If you want your object to have a more human readable representation, you can implement __str__ next. Here's how the datetime object (Python source) implements __str__, which it easily does because it already has a function to display it in ISO format:
def __str__(self):
"Convert to string, for str()."
return self.isoformat(sep=' ')
Set __repr__ = __str__?
This is a critique of another answer here that suggests setting __repr__ = __str__.
Setting __repr__ = __str__ is silly - __repr__ is a fallback for __str__ and a __repr__, written for developers usage in debugging, should be written before you write a __str__.
You need a __str__ only when you need a textual representation of the object.
Conclusion
Define __repr__ for objects you write so you and other developers have a reproducible example when using it as you develop. Define __str__ when you need a human readable string representation of it.
On page 358 of the book Python scripting for computational science by Hans Petter Langtangen, it clearly states that
The __repr__ aims at a complete string representation of the object;
The __str__ is to return a nice string for printing.
So, I prefer to understand them as
repr = reproduce
str = string (representation)
from the user's point of view
although this is a misunderstanding I made when learning python.
A small but good example is also given on the same page as follows:
Example
In [38]: str('s')
Out[38]: 's'
In [39]: repr('s')
Out[39]: "'s'"
In [40]: eval(str('s'))
Traceback (most recent call last):
File "<ipython-input-40-abd46c0c43e7>", line 1, in <module>
eval(str('s'))
File "<string>", line 1, in <module>
NameError: name 's' is not defined
In [41]: eval(repr('s'))
Out[41]: 's'
Apart from all the answers given, I would like to add few points :-
1) __repr__() is invoked when you simply write object's name on interactive python console and press enter.
2) __str__() is invoked when you use object with print statement.
3) In case, if __str__ is missing, then print and any function using str() invokes __repr__() of object.
4) __str__() of containers, when invoked will execute __repr__() method of its contained elements.
5) str() called within __str__() could potentially recurse without a base case, and error on maximum recursion depth.
6) __repr__() can call repr() which will attempt to avoid infinite recursion automatically, replacing an already represented object with ....
(2020 entry)
Q: What's the difference between __str__() and __repr__()?
TL;DR:
LONG
This question has been around a long time, and there are a variety of answers of which most are correct (not to mention from several Python community legends[!]). However when it comes down to the nitty-gritty, this question is analogous to asking the difference between the str() and repr() built-in functions. I'm going to describe the differences in my own words (which means I may be "borrowing" liberally from Core Python Programming so pls forgive me).
Both str() and repr() have the same basic job: their goal is to return a string representation of a Python object. What kind of string representation is what differentiates them.
str() & __str__() return a printable string representation of
an object... something human-readable/for human consumption
repr() & __repr__() return a string representation of an object that is a valid Python expression, an object you can pass to eval() or type into the Python shell without getting an error.
For example, let's assign a string to x and an int to y, and simply showing human-readable string versions of each:
>>> x, y = 'foo', 123
>>> str(x), str(y)
('foo', '123')
Can we take what is inside the quotes in both cases and enter them verbatim into the Python interpreter? Let's give it a try:
>>> 123
123
>>> foo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined
Clearly you can for an int but not necessarily for a str. Similarly, while I can pass '123' to eval(), that doesn't work for 'foo':
>>> eval('123')
123
>>> eval('foo')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1, in <module>
NameError: name 'foo' is not defined
So this tells you the Python shell just eval()s what you give it. Got it? Now, let's repr() both expressions and see what we get. More specifically, take its output and dump those out in the interpreter (there's a point to this which we'll address afterwards):
>>> repr(x), repr(y)
("'foo'", '123')
>>> 123
123
>>> 'foo'
'foo'
Wow, they both work? That's because 'foo', while a printable string representation of that string, it's not evaluatable, but "'foo'" is. 123 is a valid Python int called by either str() or repr(). What happens when we call eval() with these?
>>> eval('123')
123
>>> eval("'foo'")
'foo'
It works because 123 and 'foo' are valid Python objects. Another key takeaway is that while sometimes both return the same thing (the same string representation), that's not always the case. (And yes, yes, I can go create a variable foo where the eval() works, but that's not the point.)
More factoids about both pairs
Sometimes, str() and repr() are called implicitly, meaning they're called on behalf of users: when users execute print (Py1/Py2) or call print() (Py3+), even if users don't call str() explicitly, such a call is made on their behalf before the object is displayed.
In the Python shell (interactive interpreter), if you enter a variable at the >>> prompt and press RETURN, the interpreter displays the results of repr() implicitly called on that object.
To connect str() and repr() to __str__() and __repr__(), realize that calls to the built-in functions, i.e., str(x) or repr(y) result in calling their object's corresponding special methods: x.__str__() or y.__repr()__
By implementing __str__() and __repr__() for your Python classes, you overload the built-in functions (str() and repr()), allowing instances of your classes to be passed in to str() and repr(). When such calls are made, they turn around and call the class' __str__() and __repr__() (per #3).
To put it simply:
__str__ is used in to show a string representation of your object to be read easily by others.
__repr__ is used to show a string representation of the object.
Let's say I want to create a Fraction class where the string representation of a fraction is '(1/2)' and the object (Fraction class) is to be represented as 'Fraction (1,2)'
So we can create a simple Fraction class:
class Fraction:
def __init__(self, num, den):
self.__num = num
self.__den = den
def __str__(self):
return '(' + str(self.__num) + '/' + str(self.__den) + ')'
def __repr__(self):
return 'Fraction (' + str(self.__num) + ',' + str(self.__den) + ')'
f = Fraction(1,2)
print('I want to represent the Fraction STRING as ' + str(f)) # (1/2)
print('I want to represent the Fraction OBJECT as ', repr(f)) # Fraction (1,2)
From an (An Unofficial) Python Reference Wiki (archive copy) by effbot:
__str__ "computes the "informal" string representation of an object. This differs from __repr__ in that it does not have to be a valid Python expression: a more convenient or concise representation may be used instead."
In all honesty, eval(repr(obj)) is never used. If you find yourself using it, you should stop, because eval is dangerous, and strings are a very inefficient way to serialize your objects (use pickle instead).
Therefore, I would recommend setting __repr__ = __str__. The reason is that str(list) calls repr on the elements (I consider this to be one of the biggest design flaws of Python that was not addressed by Python 3). An actual repr will probably not be very helpful as the output of print([your, objects]).
To qualify this, in my experience, the most useful use case of the repr function is to put a string inside another string (using string formatting). This way, you don't have to worry about escaping quotes or anything. But note that there is no eval happening here.
str - Creates a new string object from the given object.
repr - Returns the canonical string representation of the object.
The differences:
str():
makes object readable
generates output for end-user
repr():
needs code that reproduces object
generates output for developer
One aspect that is missing in other answers. It's true that in general the pattern is:
Goal of __str__: human-readable
Goal of __repr__: unambiguous, possibly machine-readable via eval
Unfortunately, this differentiation is flawed, because the Python REPL and also IPython use __repr__ for printing objects in a REPL console (see related questions for Python and IPython). Thus, projects which are targeted for interactive console work (e.g., Numpy or Pandas) have started to ignore above rules and provide a human-readable __repr__ implementation instead.
From the book Fluent Python:
A basic requirement for a Python object is to provide usable
string representations of itself, one used for debugging and
logging, another for presentation to end users. That is why the
special methods __repr__ and __str__ exist in the data model.
__str__ can be invoked on an object by calling str(obj) and should return a human readable string.
__repr__ can be invoked on an object by calling repr(obj) and should return internal object (object fields/attributes)
This example may help:
class C1:pass
class C2:
def __str__(self):
return str(f"{self.__class__.__name__} class str ")
class C3:
def __repr__(self):
return str(f"{self.__class__.__name__} class repr")
class C4:
def __str__(self):
return str(f"{self.__class__.__name__} class str ")
def __repr__(self):
return str(f"{self.__class__.__name__} class repr")
ci1 = C1()
ci2 = C2()
ci3 = C3()
ci4 = C4()
print(ci1) #<__main__.C1 object at 0x0000024C44A80C18>
print(str(ci1)) #<__main__.C1 object at 0x0000024C44A80C18>
print(repr(ci1)) #<__main__.C1 object at 0x0000024C44A80C18>
print(ci2) #C2 class str
print(str(ci2)) #C2 class str
print(repr(ci2)) #<__main__.C2 object at 0x0000024C44AE12E8>
print(ci3) #C3 class repr
print(str(ci3)) #C3 class repr
print(repr(ci3)) #C3 class repr
print(ci4) #C4 class str
print(str(ci4)) #C4 class str
print(repr(ci4)) #C4 class repr
You can get some insight from this code:
class Foo():
def __repr__(self):
return("repr")
def __str__(self):
return("str")
foo = Foo()
foo #repr
print(foo) #str
Excellent answers already cover the difference between __str__ and __repr__, which for me boils down to the former being readable even by an end user, and the latter being as useful as possible to developers. Given that, I find that the default implementation of __repr__ often fails to achieve this goal because it omits information useful to developers.
For this reason, if I have a simple enough __str__, I generally just try to get the best of both worlds with something like:
def __repr__(self):
return '{0} ({1})'.format(object.__repr__(self), str(self))
>>> print(decimal.Decimal(23) / decimal.Decimal("1.05"))
21.90476190476190476190476190
>>> decimal.Decimal(23) / decimal.Decimal("1.05")
Decimal('21.90476190476190476190476190')
When print() is called on the result of decimal.Decimal(23) / decimal.Decimal("1.05") the raw number is printed; this output is in string form which can be achieved with __str__(). If we simply enter the expression we get a decimal.Decimal output — this output is in representational form which can be achieved with __repr__(). All Python objects have two output forms. String form is designed to be human-readable. The representational form is designed to produce output that if fed to a Python interpreter would (when possible) reproduce the represented object.
One important thing to keep in mind is that container's __str__ uses contained objects' __repr__.
>>> from datetime import datetime
>>> from decimal import Decimal
>>> print (Decimal('52'), datetime.now())
(Decimal('52'), datetime.datetime(2015, 11, 16, 10, 51, 26, 185000))
>>> str((Decimal('52'), datetime.now()))
"(Decimal('52'), datetime.datetime(2015, 11, 16, 10, 52, 22, 176000))"
Python favors unambiguity over readability, the __str__ call of a tuple calls the contained objects' __repr__, the "formal" representation of an object. Although the formal representation is harder to read than an informal one, it is unambiguous and more robust against bugs.
In a nutshell:
class Demo:
def __repr__(self):
return 'repr'
def __str__(self):
return 'str'
demo = Demo()
print(demo) # use __str__, output 'str' to stdout
s = str(demo) # __str__ is used, return 'str'
r = repr(demo) # __repr__ is used, return 'repr'
import logging
logger = logging.getLogger(logging.INFO)
logger.info(demo) # use __str__, output 'str' to stdout
from pprint import pprint, pformat
pprint(demo) # use __repr__, output 'repr' to stdout
result = pformat(demo) # use __repr__, result is string which value is 'str'
Understand __str__ and __repr__ intuitively and permanently distinguish them at all.
__str__ return the string disguised body of a given object for readable of eyes
__repr__ return the real flesh body of a given object (return itself) for unambiguity to identify.
See it in an example
In [30]: str(datetime.datetime.now())
Out[30]: '2017-12-07 15:41:14.002752'
Disguised in string form
As to __repr__
In [32]: datetime.datetime.now()
Out[32]: datetime.datetime(2017, 12, 7, 15, 43, 27, 297769)
Presence in real body which allows to be manipulated directly.
We can do arithmetic operation on __repr__ results conveniently.
In [33]: datetime.datetime.now()
Out[33]: datetime.datetime(2017, 12, 7, 15, 47, 9, 741521)
In [34]: datetime.datetime(2017, 12, 7, 15, 47, 9, 741521) - datetime.datetime(2
...: 017, 12, 7, 15, 43, 27, 297769)
Out[34]: datetime.timedelta(0, 222, 443752)
if apply the operation on __str__
In [35]: '2017-12-07 15:43:14.002752' - '2017-12-07 15:41:14.002752'
TypeError: unsupported operand type(s) for -: 'str' and 'str'
Returns nothing but error.
Another example.
In [36]: str('string_body')
Out[36]: 'string_body' # in string form
In [37]: repr('real_body')
Out[37]: "'real_body'" #its real body hide inside
Hope this help you build concrete grounds to explore more answers.
__str__ must return string object whereas __repr__ can return any python expression.
If __str__ implementation is missing then __repr__ function is used as fallback. There is no fallback if __repr__ function implementation is missing.
If __repr__ function is returning String representation of the object, we can skip implementation of __str__ function.
Source: https://www.journaldev.com/22460/python-str-repr-functions
__repr__ is used everywhere, except by print and str methods (when a __str__is defined !)
Every object inherits __repr__ from the base class that all objects created.
class Person:
pass
p=Person()
if you call repr(p) you will get this as default:
<__main__.Person object at 0x7fb2604f03a0>
But if you call str(p) you will get the same output. it is because when __str__ does not exist, Python calls __repr__
Let's implement our own __str__
class Person:
def __init__(self,name,age):
self.name=name
self.age=age
def __repr__(self):
print("__repr__ called")
return f"Person(name='{self.name}',age={self.age})"
p=Person("ali",20)
print(p) and str(p)will return
__repr__ called
Person(name='ali',age=20)
let's add __str__()
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
def __repr__(self):
print('__repr__ called')
return f"Person(name='{self.name}, age=self.age')"
def __str__(self):
print('__str__ called')
return self.name
p=Person("ali",20)
if we call print(p) and str(p), it will call __str__() so it will return
__str__ called
ali
repr(p) will return
repr called
"Person(name='ali, age=self.age')"
Let's omit __repr__ and just implement __str__.
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
def __str__(self):
print('__str__ called')
return self.name
p=Person('ali',20)
print(p) will look for the __str__ and will return:
__str__ called
ali
NOTE= if we had __repr__ and __str__ defined, f'name is {p}' would call __str__
Programmers with prior experience in languages with a toString method tend to implement __str__ and not __repr__.
If you only implement one of these special methods in Python, choose __repr__.
From Fluent Python book, by Ramalho, Luciano.
Basically __str__ or str() is used for creating output that is human-readable are must be for end-users.
On the other hand, repr() or __repr__ mainly returns canonical string representation of objects which serve the purpose of debugging and development helps the programmers.
repr() used when we debug or log.It is used for developers to understand code.
one the other hand str() user for non developer like(QA) or user.
class Customer:
def __init__(self,name):
self.name = name
def __repr__(self):
return "Customer('{}')".format(self.name)
def __str__(self):
return f"cunstomer name is {self.name}"
cus_1 = Customer("Thusi")
print(repr(cus_1)) #print(cus_1.__repr__())
print(str(cus_1)) #print(cus_1.__str__())
Related
How to create a metaclass in python? I tried to write as in tutorials:
class Meta(type):
def __new__(mcs, name, bases, attrs):
attrs2 = {'field2': 'Test'}
attrs2.update(attrs)
return super(Meta, mcs).__new__(mcs, name, bases, attrs2)
class Test(object):
__metaclass__ = Meta
field1 = 10
test = Test()
print(test.field1)
print(test.field2)
But this code fails with error:
10
Traceback (most recent call last):
File "main.py", line 18, in <module>
print(test.field2)
AttributeError: 'Test' object has no attribute 'field2'
How to declare a metaclass in python 3.7+ correctly?
UPDATED
I've changed my question with actual error.
The tutorials you are checking are covering Python 2.
In Python 3, one of the syntactic changes was exactly the way of declaring a metaclass for a class.
You don't need to change the metaclass code, just change your class declaration to:
class Test(metaclass=Meta):
field1 = 10
and it will work.
So, in short: for a metaclass in Python 3, you have to pass the equivalent of a "keyword argument" in the class declaration, with the name "metaclass". (Also, in Python 3, there is no need to inherit explicitly from object)
In Python 2, this was accomplished by the presence of the special variable __metaclass__ in the body of the class, as is in your example. (Also, when setting a metaclass, inheriting from 'object' would be optional, since the metaclass, derived from type, would do that for you).
One of the main advantages of the new syntax is that it allows the special method __prepare__ in the metaclass which can return a custom namespace object to be used when building the class body itself. It is seldom used, and a really "serious" use case would be hard to put up today. For toys and playing around, it is great, allowing for "magic autonamed enumerations" and other things - but when designing Python 3, this was way they thought to allow having an OrderedDict as the class namespace, so that the metaclass' __new__ and __init__ methods could know the order of the declaration of the attributes. Since Python 3.6, a class body namespace is ordered by default and there is no need for a __prepare__ method for this use alone.
When I read Python Cookbook recipe 9.14 discussion, it says that I have to convert the OrderedDict to a dict instance when making the final class object. Do I have to do that or using OrderedDict is ok?
I tried this, pass OrderedDict to type constructor, it doesn't raise any exception
class OrderedMeta(type):
def __new__(cls, clsname, bases, attr_dict):
order = []
for name, value in attr_dict.items():
if isinstance(value, Typed):
value._name = name
order.append(name)
attr_dict['_order'] = order
return type.__new__(cls, clsname, bases, attr_dict)
#classmethod
def __prepare__(cls, clsname, bases):
return OrderedDict()
code from book
class OrderedMeta(type):
def __new__(cls, clsname, bases, attr_dict):
d = dict(attr_dict)
order = []
for name, value in attr_dict.items():
if isinstance(value, Typed):
value._name = name
order.append(name)
d['_order'] = order
return type.__new__(cls, clsname, bases, d)
#classmethod
def __prepare__(cls, clsname, bases):
return OrderedDict()
enter image description here
No, it is not needed.
type.__new__ can take any mapping - maybe even with fewer methods than the full mapping procotocol - __iter__, __len__ and __getitem__ should suffice.
This is likely valid since Python 3.0 - the author of the recipe simply took a "safe road" as he was not sure what might ensue with a non-native dict being passed to type.__new__ and calling dict on the OrderedDict is a plain line of code anyway.
But it would not have made much sense to allow any custom mapping to be used in __prepare__ and then do not accept that same mapping on type.__new__ - That is, you don't even need a __new__ method on your metaclass if all you need is a custom mapping - just the __prepare__ method.
That said, this particular recipe is now obsolete anyway, as since Python 3.6 dictionaries used in class construction are ordered by default (and as of Python 3.7, all Python dictionaries are ordered by default).
You have to do that, for some reasons that David Beasley did not elaborate on further than saying that
"it may cause problems if you don't"
in his 2013 tutorial Python 3 Metaprogramming, at around 1 Hour and 30 minutes.
Since that tutorial, python 3.6 introduced dictionaries that retain their order, you can therefore, probably, safely ignore the use of an ordereddict for this recipe.
I have defined a class foo and a function foo.__str__(). If x is an instance of foo, x.__str__() returns a string representation of x. I have checked this on examples and it seems to work as I wish it to.
My question is, how to I now define foo.print(). Am I supposed to use __str__ or, annoyingly, repeat the code of __str__?
No, print just calls __str__, so you dont need to do anything else. You probably will also need to define __repr__, which returns the representation of the object
Code
class A:
def __str__(self):
return 'in __str__'
def __repr__(self):
return 'in __repr__'
a = A()
print(a) # __str__
print([a]) # __repr__
Output
Look at this post about __str__ vs __repr__
I am working on a command line utility with a few possible arguments. The argument parsing is done with argparse module. In the end, with some additional customization, I get a dictionary with one and only one element:
{'add_account': ['example.com', 'example']}
Where the key is an option that should translate to a method call and the value is the arguments list.
I have all the planned objects method implemented.
I wonder what would be the best, most pythonic way to create method calls based on received dictionary.
I could obviously go through a predefined mapping like:
if option == 'add_account':
object.add_account(
dictionary['add_account'][0],
dictionary['add_account'][1]
)
I feel that there's a much better way to do it, though.
You can use getattr to fetch a method object (argparse.py uses this approach several times).
You didn't give us a concrete example, but I'm guessing you have a class like this:
In [387]: class MyClass(object):
...: def add_account(self,*args):
...: print(args)
...:
In [388]: obj=MyClass()
In [389]: obj.add_account(*['one','two'])
('one', 'two')
To do the same thing, starting with a string, I can use getattr to fetch the method object:
In [390]: getattr(obj,'add_account')
Out[390]: <bound method MyClass.add_account of <__main__.MyClass object at 0x98ddaf2c>>
In [391]: getattr(obj,'add_account')('one')
('one',)
Now with your dictionary:
In [392]: dd={'add_account': ['example.com', 'example']}
In [393]: key='add_account'
In [394]: getattr(obj, key)(*dd[key])
('example.com', 'example')
OK So I have created 2 classes called Note and Notebook.
class Note:
""" A Note """
note_number = 1
def __init__(self, memo="", id=""):
""" initial attributes of the note"""
self.memo = memo
self.id = Note.note_number
Note.note_number += 1
def read_note(self):
print(self.memo)
class NoteBook:
"""The Notebook"""
def __init__(self):
self.note_book = []
def add_notes(self, *args):
for note in enumerate(args):
self.note_book.append(note)
def show_notes(self):
for note in self.note_book:
note.read_note()
n1 = Note("First note")
n2 = Note("Second note")
n3 = Note("Third note")
notebook1 = NoteBook()
notebook1.add_notes(n1, n2, n3)
notebook1.show_notes()
Traceback (most recent call last):
File "C:/Users/Alan/Python3/Random stuff/notebook revisions.py", line 47, in <module>
notebook1.show_notes()
File "C:/Users/Alan/Python3/Random stuff/notebook revisions.py", line 38, in show_notes
note.read_note()
AttributeError: 'tuple' object has no attribute 'read_note'
How come I get an attribute error? I want my show_notes() method to read all the notes in the notebook1 list.
Also if I print the following statement my result is the cryptic message:
print(notebook1.note_book[0])
(0, <__main__.Note object at 0x00863F30>)
How would I solve this problem to not produce the weird cryptic message and to print the strings "First note", "Second note" and "Third note".
Q1. Why the exception? As I suspected, the exception results from a bug in .add_notes. enumerate(args) turns notes into tuples containing a serial number and a note. This is wrong because notebooks should contain notes, not tuples, because notes already have a serial number, and because each call to add_note, and hence, enumerate, restarts at 0. Change add_note to
def add_notes(self, *args):
self.note_book.extend(args)
and notebook1.show_notes() produces what you seem to want.
First note
Second note
Third note
Q2. Better representation? For print(notebook1.note_book[0]) to print a tuple is wrong regardless of the content of the tuple. For testing, that line should have been part of the original script, just before the last line.
Printing a tuple prints the repr() of each element, so a custom __str__ will be ignored. With add_noted corrected, it now prints just the representation of the note.
<__main__.Note object at 0x00863F30>
To improve that, add back the __str__ method I asked you to delete, or a version thereof. I suggest you name it __repr__ instead, though.
def __repr__(self):
""" gives string of initial atrributes"""
return "Memo: {0}\nNote number: {1}\n ".format(self.memo, self.id)
# Note 1: First note
If you only define __str__, then __repr__ is still the mostly useless default (as above). If you define __repr__, then the custom function is used for both repr() and str(), the same as if you added the line __str__ = __repr__ after defining the latter.