data validation when creating an object

[Robert Kern]

On 2014-01-16 04:05, Roy Smith wrote:
> Rita <rmorgan466 at 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-list at python.org>,
>   Ben Finney <ben+python at 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