>
> if you are totally closed to the idea of doing something different:
> well... there's no much benefit coming out of a discussion on the subject.
Hey Cesar, au contraire! I very much like the idea of exploration. In fact,
the only reason of carrying on like a broken record :) is to elicit some
new ideas from participants and learn from other's insights. It is such
brainstorming that let's us develop. For example, I see your perfectly
valid point in wasting the CPU cycles. I did not think of this in the light
of resource handling. I think enough is said on this topic. I will retire
as well.
Cheers!
On Sat, Oct 29, 2016 at 6:29 PM, Cesar Saez <cesa...@gmail.com> wrote:
> True, you don't need to enclose the instantiation in a try except if you
> don't need to keep executing the program after a bad input, it's fair
> enough if that's your goal (although I guess you can see my point when I
> mention it in the first place)
>
> Look, It's ok to disagree on styles and all that jazz, but I feel like the
> waste of cpu cycles is something very hard to simply omit.
>
> Of course performance is a trade off and everyone is free to do whatever,
> all I'm saying is try to not waste cpu cycles on stuff not helping to
> actually solve the problem you are trying to solve. If those cycles help
> you: go for it! if it doesn't and the way to skip that is simple maybe it
> worth a try, if the alternative introduce complexity maybe you decide to no
> go for it... or if you are totally closed to the idea of doing something
> different: well... there's no much benefit coming out of a discussion on
> the subject.
>
> BTW, if you read my first reply carefully I'm not advocating to use dunder
> new as the only way to go about constructors (actually it's a bad idea). if
> anything I usually implement different constructors as classmethods so you
> can validate the user input before commiting to create an instance while
> failing gracefully (just like pyqt/pyside does in many cases). I didn't
> wanted to go in detail because of the first question being asked by someone
> trying to learn and probably all this is already very confusing to him.
>
> Anyway, I feel lke this is going nowhere and I will politelly retire from
> this thread.
> Good luck!
>
> On Sat, Oct 29, 2016 at 9:03 PM, Alok Gandhi <alok.gandhi2...@gmail.com>
> wrote:
>
>> 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 <cesa...@gmail.com> 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" <alok.gandhi2...@gmail.com> 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 python_inside_maya+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/python_inside_maya/CAPaTLMS434aqjf8AMrLVZTvE%3DCJxXXN7-C
>>>> hHN%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 python_inside_maya+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/python_inside_maya/CAPamJi-KnYYb3f1OOWEcMJMmjHeKmy1jzUSv
>>> p0hHmZuc%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 python_inside_maya+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/python_inside_maya/CAPaTLMQ1BTMhmveb79Mjpr1E1SGmXqC3BVqY
>> A5Qi32K%2BgftAUw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMQ1BTMhmveb79Mjpr1E1SGmXqC3BVqYA5Qi32K%2BgftAUw%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 python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAPamJi-b_GUD92GkbmddmxDbeFHQMxAS573Nx_
> JZc%2BqbBQ1yLQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPamJi-b_GUD92GkbmddmxDbeFHQMxAS573Nx_JZc%2BqbBQ1yLQ%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 python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMRJP-DSEm0b2j_yp6jaKR8DLh-PrAKwtb0tu7S2MF4swA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
