7;t like it very much.
>>
>>
> So, the pythonic way to check for True/False should be:
>
>>>> 1 is True
> False
Why do you need to check for True/False?
But if you need to, yes, that is one way. Another would be:
isinstance(flag, bool)
But generally, you can use any object as a flag without caring if it is
actually True or False.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Rolando Espinoza La Fuente wrote:
Doesn't have side effects not knowing that False/True are ints?
It does, in fact I was wondering why my iterator didn't work until I
figured issubclass(bool, int) is true.
Regards,
mk
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Mar 5, 2010 at 2:32 PM, mk wrote:
> Arnaud Delobelle wrote:
>
> 1 == True
>>
>> True
>
> 0 == False
>>
>> True
>>
>> So what's your question?
>
> Well nothing I'm just kind of bewildered: I'd expect smth like that in Perl,
> but not in Python.. Although I can understand the rat
Steven D'Aprano wrote:
On Fri, 05 Mar 2010 18:14:16 +0100, mk wrote:
isinstance(False, int)
True
>>>
>>> isinstance(True, int)
True
Huh?
Yes. Do you have an actual question?
>>> issubclass(bool, int)
True
Huh?!
Exactly.
Arnaud Delobelle wrote:
1 == True
True
0 == False
True
So what's your question?
Well nothing I'm just kind of bewildered: I'd expect smth like that in
Perl, but not in Python.. Although I can understand the rationale after
skimming PEP 285, I still don't like it very much.
Regards,
mk
mk wrote:
>>> isinstance(False, int)
True
>>>
>>> isinstance(True, int)
True
Huh?
>>>
>>> issubclass(bool, int)
True
Huh?!
Python didn't have Booleans originally, 0 and 1 were used instead. When
bool was introduced it was made a su
On Fri, Mar 5, 2010 at 2:00 PM, Steve Holden wrote:
[...]
>
> Just a brainfart from the BDFL - he decided (around 2.2.3, IIRC) that it
> would be a good ideal for Booleans to be a subclass of integers.
>
I would never figured out
>>> bool.__bases__
(,)
Doesn't have side effects not knowing tha
On Fri, 05 Mar 2010 18:14:16 +0100, mk wrote:
>>>> isinstance(False, int)
> True
> >>>
> >>> isinstance(True, int)
> True
>
> Huh?
Yes. Do you have an actual question?
> >>> issubclass(bool, int)
> True
>
>
On Fri, Mar 5, 2010 at 9:14 AM, mk wrote:
> >>> isinstance(False, int)
> True
> >>>
> >>> isinstance(True, int)
> True
>
> Huh?
>
> >>>
> >>> issubclass(bool, int)
> True
>
> Huh?!
>
Huh, what?
http://ww
mk writes:
>>>> isinstance(False, int)
> True
>>>>
>>>> isinstance(True, int)
> True
>
> Huh?
>
>>>>
>>>> issubclass(bool, int)
> True
>
> Huh?!
>
> Regards,
> mk
Yes, and:
>>> True + Fa
mk wrote:
>>>> isinstance(False, int)
> True
>>>>
>>>> isinstance(True, int)
> True
>
> Huh?
>
>>>>
>>>> issubclass(bool, int)
> True
>
> Huh?!
>
>>> 3+True
4
>>> 3+False
3
>>>
J
>>> isinstance(False, int)
True
>>>
>>> isinstance(True, int)
True
Huh?
>>>
>>> issubclass(bool, int)
True
Huh?!
Regards,
mk
--
http://mail.python.org/mailman/listinfo/python-list
Art wrote:
I have the following problem:
ipdb> p type(self)
ipdb> isinstance(self, component.BiasComponent)
False
I thought that isinstance(obj, type(obj)) == True.
Yes, but that is not what you entered ;-).
The name 'component.BiasComponent' is not bound to type(self)
On Wed, Jun 24, 2009 at 7:57 AM, Art wrote:
> I have the following problem:
>
> ipdb> p type(self)
>
>
> ipdb> isinstance(self, component.BiasComponent)
> False
>
> I thought that isinstance(obj, type(obj)) == True.
>
> The specific problem is when I try to
I have the following problem:
ipdb> p type(self)
ipdb> isinstance(self, component.BiasComponent)
False
I thought that isinstance(obj, type(obj)) == True.
The specific problem is when I try to call the super of a class and it
only occurs after 'reload'ing the file in the interp
Gabriel Genellina wrote:
En Fri, 13 Feb 2009 08:43:03 -0200, Peter Otten <__pete...@web.de>
escribió:
class Type(type):
... def __instancecheck__(self, other): return True
...
class A(metaclass=Type): pass
...
class B: pass
...
isinstance(B(), A)
True
See also
En Fri, 13 Feb 2009 08:43:03 -0200, Peter Otten <__pete...@web.de>
escribió:
Gabriel Genellina wrote:
En Fri, 13 Feb 2009 08:07:58 -0200, Carl Banks
escribió:
But that brings up another very slight possibility, though not a very
likely one in this case: the behavior of isinstance
; likely one in this case: the behavior of isinstance can be
>> customized. It can happen unbeknownst to a user who subclasses a
>> class that does that.
>
> Really? I didn't know that -- how do you do that?
>>> class Type(type):
... def __instance
En Fri, 13 Feb 2009 08:07:58 -0200, Carl Banks
escribió:
Well, the OP said he was using Python 3.0, where all classes are new-
style classes.
But that brings up another very slight possibility, though not a very
likely one in this case: the behavior of isinstance can be
customized. It can
ity, though not a very
likely one in this case: the behavior of isinstance can be
customized. It can happen unbeknownst to a user who subclasses a
class that does that.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
maksym.ka...@gmail.com a écrit :
Hi there.
now i'm a complete newbie for python, and maybe my problem is stupid
but i cannot solve it myself
Others already addressed your problem (cf Paul and Diez answers). I'll
just allow myself to point a couple other potential problems with your code:
#
redbaron a écrit :
Don't really sure, but try to define your class as new-style one.
isinstance() works as well with classic classes.
--
http://mail.python.org/mailman/listinfo/python-list
(self, obj):
if isinstance(obj, GeoMap):
return None
return json.JSONEncoder.default(self, obj)
def main():
print(json.dumps(2 + 5j, cls=ComplexEncoder))
geomap = testdata.createTestMap()
print(json.dumps(geomap, cls=GeoMapEncoder))
pass
if __n
On Feb 12, 12:26 pm, maksym.ka...@gmail.com wrote:
>
> Well the output of
>
> > print(type(obj))
> > print(str(obj))
>
> was
>
>
>
>
> Just looks well, isn't it? i have no idea what's wrong
So then how do you know isinstance is evaluating
On 12 фев, 21:49, redbaron wrote:
> Don't really sure, but try to define your class as new-style one.
> Like
> class GeoMap(object):
> ...
Sorry, it didn't work
--
http://mail.python.org/mailman/listinfo/python-list
Don't really sure, but try to define your class as new-style one.
Like
class GeoMap(object):
...
--
http://mail.python.org/mailman/listinfo/python-list
> Here's a crazy idea out of left field. Just before calling
> isinstance, why not try:
>
> print(type(obj))
> print(str(obj))
>
> This may illuminate the unexpected behavior, you'll find out just what
> obj has in it.
>
> -- Paul
Well the output of
&
t;
> import testdata
> import json
>
> class GeoMapEncoder(json.JSONEncoder):
> def default(self, obj):
> if isinstance(obj, GeoMap):
> return None
> return json.JSONEncoder.default(self, obj)
>
> def main():
> print(json.dumps(2 + 5
ts to json notation.
So i imported json module and as shown in docs for it extended
JSONEncoder class. Look at the code below
##main module
from worldmap import GeoMap, GeoMapCell
import testdata
import json
class GeoMapEncoder(json.JSONEncoder):
def default(self, obj):
if isinstanc
Steven D'Aprano wrote:
> On Fri, 16 Jan 2009 09:58:53 +, Duncan Booth wrote:
>
>> That still leaves the question whether anyone has ever actually taken
>> advantage of this feature. You can do isinstance(x, (IntType,
>> LongType, StringTypes)) but I didn
On Fri, 16 Jan 2009 09:58:53 +, Duncan Booth wrote:
> That still leaves the question whether anyone has ever actually taken
> advantage of this feature. You can do isinstance(x, (IntType, LongType,
> StringTypes)) but I didn't even know that StringTypes existed until a
> coup
Carl Banks wrote:
> On Jan 15, 1:08 pm, Duncan Booth wrote:
>> Carl Banks wrote:
>> > I don't see what the big deal is. Right now isinstance accepts a
>> > typ
> e
>> > or a tuple of types. The code could be changed to allow a type, or
>&g
On Jan 14, 3:14 pm, "Lambert, David W (S&T)"
wrote:
> Please, why isn't a set permitted as the second argument to isinstance?
The real problem is it would be misleading. isinstance(a, myset)
suggests implementation like type(a) in myset, but it's really any
(isin
On Jan 15, 1:08 pm, Duncan Booth wrote:
> Carl Banks wrote:
> > I don't see what the big deal is. Right now isinstance accepts a type
> > or a tuple of types. The code could be changed to allow a type, or
> > any iterable the returns types (wherein every items of th
On Jan 16, 4:28 am, "Lambert, David W (S&T)"
wrote:
> Although isinstance predates sets, the python history I recall is that
> allowing tuples as second argument to isinstance happened at about the
> same time as set type was builtin.
isinstance 2nd arg as tuple of typ
Duncan Booth wrote:
Terry Reedy wrote:
Lambert, David W (S&T) wrote:
Overly terse. I do mean that this is illegal:
isinstance(s, {str, bytes})
tuples have order, immutability, and the possibility of repeat items.
A set is most reasonable in a mathematical sense.
I agree. How
Carl Banks wrote:
> I don't see what the big deal is. Right now isinstance accepts a type
> or a tuple of types. The code could be changed to allow a type, or
> any iterable the returns types (wherein every items of the sequence is
> required to be a type). What's mes
On Jan 15, 3:35 am, Duncan Booth wrote:
> Terry Reedy wrote:
> > Lambert, David W (S&T) wrote:
> >> Overly terse. I do mean that this is illegal:
>
> >> isinstance(s, {str, bytes})
>
> >> tuples have order, immutability, and the possibility of repe
Although isinstance predates sets, the python history I recall is that
allowing tuples as second argument to isinstance happened at about the
same time as set type was builtin.
--
http://mail.python.org/mailman/listinfo/python-list
split()
>
> instead of
>
> __all__ = 'this','that','imTiredOfMistypingCommasAndQuotes'
>
>
> if not isinstance(o,set_of_handled_types):
> raise TypeError('call blessed programmer, this cannot occur')
> if isinstance(o,set_of_handle_types-treat_differently):
&g
I have use case, needn't be dynamic, and it's not hard to enclose set as
tuple. But I also write (for example)
__all__ = 'this that other'.split()
string_list = 'evenOneWord'.split()
instead of
__all__ = 'this','that','i
Lambert, David W (S&T) wrote:
Overly terse. I do mean that this is illegal:
isinstance(s, {str, bytes})
tuples have order, immutability, and the possibility of repeat items.
A set is most reasonable in a mathematical sense.
You could say the same about s.startswith(("a", &q
Terry Reedy wrote:
> Lambert, David W (S&T) wrote:
>> Overly terse. I do mean that this is illegal:
>>
>> isinstance(s, {str, bytes})
>>
>> tuples have order, immutability, and the possibility of repeat items.
>>
>> A set is most reasonabl
On Wed, 14 Jan 2009 22:03:37 -0500, Lambert, David W (S&T) wrote:
> Overly terse. I do mean that this is illegal:
>
> isinstance(s, {str, bytes})
*shrug*
Just change the {} to () and it will work fine.
Or do this:
isinstance(s, tuple({str, bytes}))
> tuples have order, i
Lambert, David W (S&T) wrote:
Overly terse. I do mean that this is illegal:
isinstance(s, {str, bytes})
tuples have order, immutability, and the possibility of repeat items.
A set is most reasonable in a mathematical sense.
I agree. However, isinstance predates set. Hence the status
On Jan 15, 2:03 pm, "Lambert, David W (S&T)"
wrote:
> Overly terse. I do mean that this is illegal:
>
> isinstance(s, {str, bytes})
>
> tuples have order, immutability, and the possibility of repeat items.
In the anticipated/usual use case (the type/class names a
On Thu, Jan 15, 2009 at 1:03 PM, Lambert, David W (S&T)
wrote:
> Overly terse. I do mean that this is illegal:
>
> isinstance(s, {str, bytes})
>
> tuples have order, immutability, and the possibility of repeat items.
>
> A set is most reasonable in a mathematical
Overly terse. I do mean that this is illegal:
isinstance(s, {str, bytes})
tuples have order, immutability, and the possibility of repeat items.
A set is most reasonable in a mathematical sense.
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 14, 4:14 pm, "Lambert, David W (S&T)"
wrote:
> Please, why isn't a set permitted as the second argument to isinstance?
The Python development team might be open to adding it if you were to
submit a patch. The use case is fairly obvious. I doubt any of them
would
Lambert, David W (S&T) wrote:
Please, why isn't a set permitted as the second argument to
isinstance?
Do you mean set as a class ("isinstance(s, set)", which is valid) or a
set of classes ("isinstance(s, set([str, bytes])", which isn't valid)?
--
http://mail.
On Thu, Jan 15, 2009 at 8:14 AM, Lambert, David W (S&T)
wrote:
> Please, why isn't a set permitted as the second argument to isinstance?
Care to show us a code sample ?
We're not psychic you know...
cheers
James
--
http://mail.python.org/mailman/listinfo/python-list
Please, why isn't a set permitted as the second argument to isinstance?
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
Boris Borcic wrote:
...
- allowing containment tests, ie "x in Number" to invoke isinstance()
in the background when the container is of type . My brain is
too muddled by flu at the moment, to see whether Guido's fabled time
machine allowed him to already
Bruno Desthuilliers wrote:
[EMAIL PROTECTED] a écrit :
...
A intriguing wider proposition would be to transpose Ruby's notion of
"Open Classes" to Python built-in metaclasses (or just to type
itself ?).
No, thanks. Even the Ruby guys start to think making evrything open may
not be such a goo
Boris Borcic a écrit :
Bruno Desthuilliers wrote:
Boris Borcic a écrit :
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are rare
Bruno Desthuilliers wrote:
Boris Borcic a écrit :
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are rare;
"x is None"
[EMAIL PROTECTED] a écrit :
Bruno Desthuilliers dixit :
Boris Borcic a écrit :
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are
Bruno Desthuilliers dixit :
> Boris Borcic a écrit :
>
> > Given the ABC innovation, maybe an infix syntax for isinstance() would
> > be good.
>
> > Possibilities :
>
> > - stealing "is" away from object identity. As a motivation, true use
> > c
Boris Borcic wrote:
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are rare; forcing the usage of a
function or method to test
Boris Borcic a écrit :
Given the ABC innovation, maybe an infix syntax for isinstance() would
be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use
cases for testing object identity are rare;
"x is None" is a *very* common t
Boris Borcic:
> - combining both keywords to create a third one, eg "is in"
A note only on syntax: "isa" seems better for Python. I don't comment
how useful it can be.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Given the ABC innovation, maybe an infix syntax for isinstance() would be good.
Possibilities :
- stealing "is" away from object identity. As a motivation, true use cases for
testing object identity are rare; forcing the usage of a function or method to
test it, would diss
Tlis schrieb:
> Hi,
>
> I have found that it is possible to reassign the instance.__class__
> reference to the same class (but after reloading) to make the
> isinstance() test work again! I know that it is a kind of hacking of
> the Python interpreter, but it works :-)
I
Hi,
I have found that it is possible to reassign the instance.__class__
reference to the same class (but after reloading) to make the
isinstance() test work again! I know that it is a kind of hacking of
the Python interpreter, but it works :-)
--
http://mail.python.org/mailman/listinfo/python
On Thu, 06 Dec 2007 13:59:00 +0100, "Diez B. Roggisch" <[EMAIL PROTECTED]>
wrote:
> [snip]
>>
>> Who says it isn't feasible?
>>
>> http://twistedmatrix.com/trac/browser/trunk/twisted/python/rebuild.py
>
>Nice try - for sure. But it seems to be geared towards special cases,
>not a general-purpose "
Jean-Paul Calderone schrieb:
> On Thu, 06 Dec 2007 12:21:01 +0100, "Diez B. Roggisch"
> <[EMAIL PROTECTED]> wrote:
>> Tlis schrieb:
>>> On 5 Dec, 13:18, Steven D'Aprano <[EMAIL PROTECTED]
>>> cybersource.com.au> wrote:
On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
> You just
On Thu, 06 Dec 2007 12:21:01 +0100, "Diez B. Roggisch" <[EMAIL PROTECTED]>
wrote:
>Tlis schrieb:
>> On 5 Dec, 13:18, Steven D'Aprano <[EMAIL PROTECTED]
>> cybersource.com.au> wrote:
>>> On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
You just discovered one reason why reload() is
Tlis schrieb:
> On 5 Dec, 13:18, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>> On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
>>> You just discovered one reason why reload() is a bad idea and IMHO
>>> shouldn't be used at all - as tempting it might be.
>> I disagre
En Wed, 05 Dec 2007 15:06:43 -0300, Tlis <[EMAIL PROTECTED]> escribi�:
> With all the problems of the reload() function, I still hope, that
> there should be possible to write a safe module 'reloader', that would
> fix the references, as required (e.g. by changing the
> variable.__class__ referenc
On Dec 5, 2007 12:06 PM, Tlis <[EMAIL PROTECTED]> wrote:
> On 5 Dec, 13:18, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
> > On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
> > > You just discovered one reason why reload() is a bad idea and IMHO
> > > shouldn't be use
On 5 Dec, 13:18, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
> > You just discovered one reason why reload() is a bad idea and IMHO
> > shouldn't be used at all - as tempting it might be.
>
> I disagree -- I find reload
Steven D'Aprano wrote:
> On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
>
>> You just discovered one reason why reload() is a bad idea and IMHO
>> shouldn't be used at all - as tempting it might be.
>
>
> I disagree -- I find reload() extremely useful for interactively testing
> mo
On Tue, 04 Dec 2007 15:41:48 +0100, Diez B. Roggisch wrote:
> You just discovered one reason why reload() is a bad idea and IMHO
> shouldn't be used at all - as tempting it might be.
I disagree -- I find reload() extremely useful for interactively testing
modules. But I would never dream of usi
Tlis wrote:
> I am using a software system with an embedded Python interpreter
> (version 2.3) for scripting. The KcsPoint2D.py module contains a
> Point2D class with the following method:
>
> def SetFromMidpoint(self, p1, p2):
> if not isinstance(p1, Point2D) or not isin
I am using a software system with an embedded Python interpreter
(version 2.3) for scripting. The KcsPoint2D.py module contains a
Point2D class with the following method:
def SetFromMidpoint(self, p1, p2):
if not isinstance(p1, Point2D) or not isinstance(p2, Point2D):
raise TypeError
for functionality (e.g. presence of necessary methods)
rather than specific inheritence.
Using "isinstance" is one of those practices that can really help in
quick testbed code or in a prototype, but you usually want to take it
out later.
Cheers,
Terry
--
Terry Hancock ([EMAIL PROTECT
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,
>
e with another type
assumption. The only thing one often checks is for basestring, as
basestring supports iteration, but more than often isn't supposed to be
iterated over.
Small example to gather all strings out of a tree of objects (untested):
def foo(arg):
# string case
if isinsta
>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):
&g
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&
> 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"
>
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):
&g
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'
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"
prin
Georg Brandl wrote:
> Fredrik Lundh wrote:
> > Sion Arrowsmith wrote:
> >>
> >
> >>> based on http://docs.python.org/ref/types.html, here's a list of the
> >>> most commonly used core types:
> >>> [ ... ]
> >>> Sequences:
> >>> str
> >>> unicode
> >>> tuple
> >>> list
> >>
> >> And
Fredrik Lundh wrote:
> Sion Arrowsmith wrote:
>>
>
>>> based on http://docs.python.org/ref/types.html, here's a list of the
>>> most commonly used core types:
>>> [ ... ]
>>> Sequences:
>>> str
>>> unicode
>>> tuple
>>> list
>>
>> And set, presumably.
>
> absolutely!
>
> howeve
Sion Arrowsmith wrote:
>
>> based on http://docs.python.org/ref/types.html, here's a list of the
>> most commonly used core types:
>> [ ... ]
>> Sequences:
>> str
>> unicode
>> tuple
>> list
>
> And set, presumably.
absolutely!
however, sets don't seem to be mentioned on that p
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>based on http://docs.python.org/ref/types.html, here's a list of the
>most commonly used core types:
> [ ... ]
>Sequences:
> str
> unicode
> tuple
> list
And set, presumably.
--
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
101 - 200 of 245 matches
Mail list logo
