[Tutor] is it possible to call a setter property during classinstantiation?

[Serdar Tumgoren]

>
>
>
>  I have a class with an init method that is getting bloated with
>> error-checking guard clauses.
>>
>
> Thats very strange. We don't usually have to check types in Python,
> it is a dynamic language and we can use duck-typing and exceptions
> so we don't usually care too much about types. Are you sure you
> really need all that type checking code?


Hmm...for my scenario I thought I needed to bend that rule, but if I explain
the use case perhaps you can offer alternatives. Much of my error-checking
aims to ensure that a class is "fed" the correct type of data.  For
instance, I included a type check for a string to make sure that a future
programmer (or myself) wouldn't try to pass in a list of lines after a text
has been split. Other code internal to the Question class depends on the
fact that the incoming data arrives in the form of a single string. If the
wrong data type is fed, then I have a custom exception that gets raised to
specify the problem. I guess the program would just crash with a TypeError
if a list of lines was fed rather than a string, so even without the guard
clause the processing would not take place.

Is it better in such cases to just let the program die a natural death,
without cluttering things up with such anticipatory guard clauses? I have to
admit, it certainly does clutter up the code and seems to be leading to a
lot of additional unit testing overhead. Is there a better way to approach
these issues?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20100813/35f007cd/attachment-0001.html>