> class Comment:
>
> def __init__(self, content=''):
> self.content = content
>
> def __call__(self, content=''):
> o = self.__class__(content)
> return str(o)
>
> def __str__(self):
> return '<!-- %s -->' % self.content
>
> def __repr__(self):
> return repr(self.__str__())
>
> When I look at this, I see certain decisions I've made and I'm wondering if
> I've made the best decisions. I'm wondering how to balance performance
> against clarity and proper coding conventions.
>
> 1. In the __call__ I save a reference to the object. Instead, I could
> simply:
>
> return str(self.__class__(content))
>
> Is there much of a performance impact by explicitly naming intermediate
> references? (I need some of Tim Peter's performance testing scripts.)
Since o is a "fast local" (all locals are fast locals except when a
function uses exec or import *), it is very fast. The load and store
of fast locals are about the fastest opcodes around.
I am more worried about the inefficiency of instantiating
self.__class__ and then throwing it away after calling str() on it.
You could factor out the body of __str__ into a separate method so
that you can invoke it from __call__ without creating an instance.
> 2. I chose the slightly indirect str(o) instead of o.__str__(). Is this
> slower? Is one style preferred over the other and why?
str(o) is preferred. I would say that you should never call __foo__
methods directly except when you're overriding a base class's __foo__
method.
> 3. I used a format string, '<!-- %s -->' % self.content, where I could just
> as easily have concatenated '<!-- ' + self.content + ' -->'
> instead. Is one faster than the other?
You could time it. My personal belief is that for more than one +
operator, %s is faster.
> 4. Is there any documentation that covers these kinds of issues
> where there is more than one way to do something? I'd like to have
> some foundation for making these decisions. As you can probably
> guess, I usually hate having more than one way to do anything. ;-)
I'm not aware of documentation, and I think you should give yourself
some credit for having a personal opinion. Study the standard library
and you'll get an idea of what's "done" and what's "not done".
BTW I have another gripe about your example.
> def __str__(self):
> return '<!-- %s -->' % self.content
>
> def __repr__(self):
> return repr(self.__str__())
This definition of __repr__ makes no sense to me -- all it does is add
string quotes around the contents of the string (and escape
non-printing characters and quotes if there are any). That is
confusing, because it will appear to the reader as if the object is a
string. You probably should write
__repr__ = __str__
instead.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4