On 2014-01-16 04:05, Roy Smith wrote:
Rita <rmorgan...@gmail.com> writes:
I know its frowned upon to do work in the __init__() method and only
declarations should be there.
In article <mailman.5555.1389834993.18130.python-l...@python.org>,
Ben Finney <ben+pyt...@benfinney.id.au> wrote:
Who says it's frowned on to do work in the initialiser? Where are they
saying it? That seems over-broad, I'd like to read the context of that
advice.
Weird, I was just having this conversation at work earlier this week.
There are some people who advocate that C++ constructors should not do a
lot of work and/or should be incapable of throwing exceptions. The pros
and cons of that argument are largely C++ specific. Here's a Stack
Overflow thread which covers most of the usual arguments on both sides:
http://stackoverflow.com/questions/293967/how-much-work-should-be-done-in
-a-constructor
But, Python is not C++. I suspect the people who argue for __init__()
not doing much are extrapolating a C++ pattern to other languages
without fully understanding the reason why.
I'm one of those people who tends to argue this, but my limited experience with
C++ does not inform my opinion one way or the other.
I prefer to keep my __init__() methods as dumb as possible to retain the
flexibility to construct my objects in different ways. Sure, it's convenient to,
say, pass a filename and have the __init__() open() it for me. But then I'm
stuck with only being able to create this object with a true, named file on
disk. I can't create it with a StringIO for testing, or by opening a file and
seeking to a specific spot where the relevant data starts, etc. I can keep the
flexibility and convenience by keeping __init__() dumb and relegating various
smarter and more convenient ways to instantiate the object to classmethods.
Which isn't to say that "smart" or "heavy" __init__()s don't have their place
for some kinds of objects. I just think that dumb __init__()s should be the default.
That said, what the OP asks about, validating data in the __init__() is
perfectly fine, IMO. My beef isn't so much with the raw *amount* of stuff done
but how much you can code yourself into a corner by making limiting assumptions.
So from one of the "do nothing in your __init__()" crowd, I say "well, I didn't
really mean *nothing*...."
That being said, I've been on a tear lately, trying to get our unit test
suite to run faster. I came across one slow test which had an
interesting twist. The class being tested had an __init__() method
which read over 900,000 records from a database and took something like
5-10 seconds to run. Man, talk about heavy-weight constructors :-)
Indeed.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
https://mail.python.org/mailman/listinfo/python-list
