tags:

views:

89

answers:

2

In general, is it reasonable to return None from a __new__ method if the user of the class knows that sometimes the constructor will evaluate to None?

The documentation doesn't imply it's illegal, and I don't see any immediate problems (since __init__ is not going to be called, None not being an instance of the custom class in question!). But I'm worried about

  1. whether it might have other unforeseen issues
  2. whether it's a good programming practice to have constructors return None

Specific example:

class MyNumber(int):
    def __new__(cls, value): # value is a string (usually) parsed from a file
        if value == 'N.A.':
            return None
        return int.__new__(cls, value)
+4  A: 

It's not illegal. If nothing weird is done with the result, it will work.

Alex Martelli
or rather, it _will_ work. Attempting to do almost anything interesting with the result _will not_. But that's probably part of the point.
aaronasterling
+3  A: 

You should avoid this. The documentation doesn't exhaustively list the things you shouldn't do, but it says what __new__ should do: return an instance of the class.

If you don't want to return a new object in some cases, raise an exception.

Glenn Maynard
But documentation also says that if an instance of the class is not returned, __init__ is not called. I read it as implicitly allowing returning non-instance of the class. As for exceptions, it's a bit more work for the user; instead of just checking that the object is not None, they need to try and catch exceptions.
max
+1 for ValueError in this case.
Daenyth
Or it's a bit less work for the user, if the user is expecting to handle errors for a block of code with a single exception handler (which is the whole point of exceptions). Two things to remember: error handling in Python is usually (not *always*, but most of the time) done via exceptions; and having a constructor *not* construct an object is the very definition of *exceptional behavior*.
Glenn Maynard
In this case, it's not an exceptional situation. The user of the class populates his own data structure with values of MyNumber class, and he's perfectly fine having some None values in there. If he treats this as an exception, he'll just have to populate the with None manually every time it happens. Does this change your view?
max
It seems like a strange design, and having a class ctor return None would be very surprising to me. I'd probably sooner use a factory function; having a factory return None seems much less surprising than a ctor doing so. Maybe that's just my C++ roots--personally I'd be inclined to avoid it, but it's up to you. It's unusual, but yes, it's legal.
Glenn Maynard
(Talk about utterly meaningless comment votes.)
Glenn Maynard
My take is that there really isn't _much_ (if any) difference between a class and a factory. A class is a callable so why would it be surprising to have a class return None?
aaronasterling
@AaronMcSmooth: A class is a callable with specific expected behavior: to return an instance of that class. Having a class ctor return the PID or the amount of free disk space would also be surprising. (Well--may as well preempt this--unless the class is a subclass of `int`.)
Glenn Maynard
@Glenn Maynard But by the same token a factory is a callable with a specific expected behavior: to return an instance of that class. So why is it any different for the class callable? It seems like another situation of people don't do it so it shouldn't be done. sort of like attributes on functions. It strikes me as a weak reason but meh.
aaronasterling