On 2006-08-29, Simon Forman <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-08-28, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > Antoon Pardon wrote:
>> >> There seem to be enough problems that work with ints but not with
>> >> floats. In such a case enforcing that the number you work with
>> >> is indeed an int seems fully appropiate.
>> >
>> > I've _never_ seen a case where enforcing types in the manner of the OP
>> > is appropriate.
>> >
>> > It fails with trivial wrappers like
>> >
>> > class myInt(int):
>> >     def printFormatted(self):
>> >         ..........
>> >
>> > Even looser checking with isinstance is rarely right.  You may want to
>> > exclude floats, but that doesn't mean you want to exclude int-like
>> > objects that don't inherit from int.
>>
>> That may be true. But one may wonder if this is a failing of the
>> programmer or a failing of the language that doesn't support
>> such things.
>
> What the hell are you talking about?

Yes, I should have been more clearer.

> I'm curious: what is the meaning, to you, of the word "this" in your
> sentence above?

That something like "type(x) == int" or "isinstance(x, int)" doesn't
allow to check for all int like objects, nor that there is some python
idiom that should allow you to test for such a thing (although it might
be circumvented).

With that second sentence I mean that there could exist a python
convention that prescribed that all int like objects had to be
subtypes of int. In that case code that followed the convention
could use "isinstance(x, int)" to check for int like objects.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to