>
> It forces the user to enclose any instantiation on a try except
Actually, it doesn't, the try except block was just for demonstration
purposes. The demo will still work without it.
class A(object):
def __init__(self):
raise ValueError('Something bad happened!')
def __del__(self):
print "Delete Called"
def main():
a = A()
if __name__ == '__main__':
main()
would produce
Traceback (most recent call last):
File "/Users/alok/Desktop/python.py", line 13, in <module>
main()
File "/Users/alok/Desktop/python.py", line 10, in main
A()
File "/Users/alok/Desktop/python.py", line 3, in __init__
raise ValueError('Something bad happened!')ValueError: Something
bad happened!
Delete Called
Point being __del__() is called always and it is a fail-safe mechanism.
I guess my point is that validation is usually done in the constructor and
> not initialisation
I most humbly would like to disagree. Actually, most of the time, not
always, validation is a part of data initialization and should be done in
__init__(),
Here's <https://hg.python.org/cpython/file/2.7/Lib/argparse.py#l819> some
code from Python Standard Library that does that (there might be numerous
other examples in the standard library, this is just one of them).
Also here's
<https://mail.python.org/pipermail/python-list/2014-January/664709.html>
some interesting insight into the matter. Do note that the author here says
-
Validating in __new__ will allow you to catch problems sooner, and give you
the option of returning some sort of sentinel instead of just raising an
exception,* though that is probably not generally good practice.*
The whole idea of `constructor` as it comes from other languages does not
apply to python. __new__ is used for object creation, __init__ is used for
object initialization. That's it.
Here
<http://python-history.blogspot.hk/2010/06/inside-story-on-new-style-classes.html>
is a post from Guido van Russom himself on why __new__ was introduced in
python.
On Sat, Oct 29, 2016 at 2:20 PM, Cesar Saez <[email protected]> wrote:
> Sure you can (although it forces the user to enclose any instantiation on
> a try except, but it works). I guess my point is that validation is usually
> done in the constructor and not initialisation, creating an instance just
> to destroy it later on without doing any work (contributing to solve the
> problem the programmer is trying to solve) is a bit wasteful and I would
> not recommend it as good practice to someone trying to learn.
>
> On 29 Oct 2016 1:21 PM, "Alok Gandhi" <[email protected]> wrote:
>
>> There's a fundamental problem with this in my view, the dounder init
>>> method of a class gets executed _after_ the instance (aka self) get
>>> created, doing checks there means you basically create an object that can
>>> potentially be invalid by passing the wrong thing and that's a problem.
>>
>> I don't see this as a problem. The __init__() method is for
>> initialization of the instance. If something goes wrong during the
>> initialization, you can always raise from within __init__(). I mean,
>> whatever sanity checks you want to put in for 'filling in' the variables
>> should happen in __init__() because that is the primary role of this
>> method. If anything bad happens and the object becomes 'invalid' python
>> will call __del__() to clean it after itself. So it is perfectly safe to
>> raise from __init__().
>>
>> Here's a snippet exhibiting the call to __del__() by python's memory
>> management when __init__() fail:
>>
>> class A(object):
>> def __init__(self):
>> raise ValueError('Something bad happened!')
>>
>> def __del__(self):
>> print "Delete Called"
>>
>> def main():
>> try:
>> a = A()
>> except ValueError, e:
>> print e
>> if __name__ == '__main__':
>> main()
>>
>>
>> Would result in:
>> >>>Something bad happened!
>> >>>Delete Called
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/python_inside_maya/CAPaTLMS434aqjf8AMrLVZTvE%3DCJxXXN7-
>> ChHN%3DMd%2B8wG-6v1%2Bg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMS434aqjf8AMrLVZTvE%3DCJxXXN7-ChHN%3DMd%2B8wG-6v1%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAPamJi-KnYYb3f1OOWEcMJMmjHeKmy1jzUSvp
> 0hHmZuc%3DsmT9g%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPamJi-KnYYb3f1OOWEcMJMmjHeKmy1jzUSvp0hHmZuc%3DsmT9g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMQ1BTMhmveb79Mjpr1E1SGmXqC3BVqYA5Qi32K%2BgftAUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
