Bruno Desthuilliers wrote:
> abcd a écrit :
>
>>Well my example function was simply taking a string and printing, but
>>most of my cases would be expecting a list, dictionary or some other
>>custom object. Still propose not to validate the type of data being
>>passed in?
>
>
> Yes - unless you
Matthew Woodcraft a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>> Matthew Woodcraft a écrit :
>
>>> Adding the validation code can make your code more readable, in that
>>> it can be clearer to the readers what kind of values are being
>>> handled.
>
>> This is better expressed in
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Matthew Woodcraft a écrit :
>> Adding the validation code can make your code more readable, in that
>> it can be clearer to the readers what kind of values are being
>> handled.
> This is better expressed in the docstring. And if it's in the
> doc
abcd a écrit :
> Well my example function was simply taking a string and printing, but
> most of my cases would be expecting a list, dictionary or some other
> custom object. Still propose not to validate the type of data being
> passed in?
Yes - unless you have a *very* compelling reason to do o
Matthew Woodcraft a écrit :
> abcd <[EMAIL PROTECTED]> wrote:
>
>>Well my example function was simply taking a string and printing, but
>>most of my cases would be expecting a list, dictionary or some other
>>custom object. Still propose not to validate the type of data being
>>passed in?
>
>
>
abcd <[EMAIL PROTECTED]> wrote:
> Well my example function was simply taking a string and printing, but
> most of my cases would be expecting a list, dictionary or some other
> custom object. Still propose not to validate the type of data being
> passed in?
There are many people here who will in
Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> In
> the example above, you can validate that fileobject has a write
> attribute: getattr(fileobject, "write"). But I'd only do that if I
> have a good reason (perhaps if the file is used after some lengthy
> calculation,and I want to be sure that
At Wednesday 24/1/2007 14:21, abcd wrote:
>Yes because usually you don't expect a list or dictionary but some object
> that *acts* like a list or dictionary. Or you even expect just some
> aspects of the type's behavior. For example that it is something you can
> iterate over.
>
> Ciao,
>
abcd wrote:
> good point. is there place that documents what methods/attrs I should
> check for on an object? for example, if its a list that I expect I
> should verify the object that is passed in has a ??? function? etc.
Don't check, try. Catch a possible exception, and continue with another
>Yes because usually you don't expect a list or dictionary but some object
> that *acts* like a list or dictionary. Or you even expect just some
> aspects of the type's behavior. For example that it is something you can
> iterate over.
>
> Ciao,
> Marc 'BlackJack' Rintsch
good point. is
Well my example function was simply taking a string and printing, but
most of my cases would be expecting a list, dictionary or some other
custom object. Still propose not to validate the type of data being
passed in?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
In <[EMAIL PROTECTED]>, abcd wrote:
> Well my example function was simply taking a string and printing, but
> most of my cases would be expecting a list, dictionary or some other
> custom object. Still propose not to validate the type of data being
> passed in?
Yes because usually you don't expe
Well my example function was simply taking a string and printing, but
most of my cases would be expecting a list, dictionary or some other
custom object. Still propose not to validate the type of data being
passed in?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
abcd wrote:
>> The "Python way" is to validate by performing the operations you need to
>> perform and catching any exceptions that result. In the case of your
>> example, you seem to be saying that you'd rather raise your own
>> exception (which, by the way, should really be a subclass of Exceptio
abcd a écrit :
> In my code I am debating whether or not to validate the types of data
> being passed to my functions. For example
>
> def sayHello(self, name):
> if not name:
> rasie "name can't be null"
> if not isinstance(name, str):
> raise "name must be a string"
>
On 2007-01-24, abcd <[EMAIL PROTECTED]> wrote:
> In my code I am debating whether or not to validate the types of data
> being passed to my functions. For example
>
> def sayHello(self, name):
> if not name:
> rasie "name can't be null"
> if not isinstance(name, str):
> rai
> The "Python way" is to validate by performing the operations you need to
> perform and catching any exceptions that result. In the case of your
> example, you seem to be saying that you'd rather raise your own
> exception (which, by the way, should really be a subclass of Exception,
> but we will
"abcd" <[EMAIL PROTECTED]> wrote:
> In my code I am debating whether or not to validate the types of data
> being passed to my functions. For example
>
> def sayHello(self, name):
> if not name:
> rasie "name can't be null"
> if not isinstance(name, str):
> raise "name mu
abcd wrote:
> In my code I am debating whether or not to validate the types of data
> being passed to my functions. For example
>
> def sayHello(self, name):
> if not name:
> rasie "name can't be null"
> if not isinstance(name, str):
> raise "name must be a string"
> p
On Jan 24, 3:38 pm, "abcd" <[EMAIL PROTECTED]> wrote:
> In my code I am debating whether or not to validate the types of data
> being passed to my functions. For example
>
> def sayHello(self, name):
> if not name:
> rasie "name can't be null"
> if not isinstance(name, str):
>
In my code I am debating whether or not to validate the types of data
being passed to my functions. For example
def sayHello(self, name):
if not name:
rasie "name can't be null"
if not isinstance(name, str):
raise "name must be a string"
print "Hello " + name
Is the u
21 matches
Mail list logo
