On Tue, 21 Jun 2005, Guido van Rossum wrote:
[two messages mixed]
> Huh? C unsigned ints don't flag overflow either -- they perform
> perfect arithmetic mod 2**32.
I was talking about signed ints. Sorry about the confusion. Other
scripting languages (e.g. perl) do not error on overflow.
>
>> In my usage, the
>> integer will be translated to an unsigned (32 bit) integer in another
>> system (SNMP). I want to know if it will fit, and I want to know early if
>> there will be a problem, rather than later (at conversion time).
>
> So check if it is >= 2**32 (or < 0, of course).
That's exactly what I do. ;-) The "unsigned" subclass of long is part of
the API, and checks the range when it is created (and they get created
implicitly when operated on).
> (a) Stop worrying about speed. The overhead of a single Python
> bytecode execution is probably more than the cost of an integer
> operation in most cases.
I am not thinking of the integer operation, but the extra Python
bytecode necessary to implement the extra checks for overflow.
>> Again, because I want to catch the error early, before conversion to the
>> external type.
>
> This is a very specialized application. Your best approach is to check
> for overflow before passing into the external API -- ideally the
> wrappers for that API should do so.
> (c) The right place to do the overflow checks is in the API wrappers,
> not in the integer types.
That would be the "traditional" method.
I was trying to keep it an object-oriented API. What should "know" the
overflow condition is the type object itself. It raises OverFlowError any
time this occurs, for any operation, implicitly. I prefer to catch errors
earlier, rather than later.
> (b) I don't know what you call a "normal" integer any more; to me,
> unified long/int is as normal as they come. Trust me, that's the case
> for most users. Worrying about 32 bits becomes less and less normal.
By "normal" integer I mean the mathematical definition. Most Python users
don't have to worry about 32 bits now, that is a good thing when you are
dealing only with Python. However, if one has to interface to other
systems that have definite types with limits, then one must "hack around"
this feature. I was just thinking how nice it would be if Python had, in
addition to unified ("real", "normal") integers it also had built-in
types that could be more easily mapped to external types (the typical
set of signed, unsigned, short, long, etc.).Yes, you can check it at
conversion time, but that would mean extra Python bytecode. It seems you
think this is a special case, but I think Python may be used as a "glue
language" fairly often, and some of us would benefit from having those
extra types as built-ins.
--
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keith Dart <[EMAIL PROTECTED]>
public key: ID: F3D288E4
=====================================================================
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
