Keith Dart wrote:
>On Sat, 18 Jun 2005, Michael Hudson wrote:
>
>
>
>>The shortest way I know of going from 2149871625L to -2145095671 is
>>the still-fairly-gross:
>>
>>
>>
>v = 2149871625L
>~int(~v&0x)
>
>
>>-2145095671
>>
>>
>>
>>>I suppose the best th
[me]
> > (c) The right place to do the overflow checks is in the API wrappers,
> > not in the integer types.
[Keith Dart]
> 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
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Gareth McCaughan wrote:
>> [Keith Dart:]
>>>By "normal" integer I mean the mathematical definition.
>>
>> Then you aren't (to me) making sense. You were distinguishing
>> this from a unified int/long. So far as I can see, a unified int/long
>> type *does
Gareth McCaughan wrote:
> [Keith Dart:]
>>By "normal" integer I mean the mathematical definition.
>
> Then you aren't (to me) making sense. You were distinguishing
> this from a unified int/long. So far as I can see, a unified int/long
> type *does* implement (modulo implementation limits and bugs
[GvR:]
> > Huh? C unsigned ints don't flag overflow either -- they perform
> > perfect arithmetic mod 2**32.
[Keith Dart:]
> I was talking about signed ints. Sorry about the confusion. Other
> scripting languages (e.g. perl) do not error on overflow.
C signed ints also don't flag overflow, nor do
On Tue, 21 Jun 2005, Ron Adam wrote:
> It seems to me, that maybe a single "byte_buffer" type, that can be
> defined to the exact needed byte lengths and have possible other
> characteristics to aid in interfacing to other languages or devices,
> would be a better choice.
>
> Then pythons ints, fl
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.
>
>> I
Keith Dart wrote:
> On Mon, 20 Jun 2005, Keith Dart wrote:
>
>
>>But then I wouldn't know if it overflowed 32 bits. 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
On 6/20/05, Keith Dart <[EMAIL PROTECTED]> wrote:
> However, since it is sometimes necessary to interface to other systems
> with Python, I see no reason why Python should not have a full set of
> built in numeric types corresponding to the machine types and, in turn,
> other system types. Then it
On 6/20/05, Keith Dart <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Jun 2005, Guido van Rossum wrote:
[...]
> > By far the easiest way to do arithmetic mod 2**32 is to just add "&
> > 0x" to the end of your expression. For example, simulating the
> > effect of multiplying an unsigned long by 3 w
Keith Dart wrote:
> I guess I just clarify this more. My "unsigned" type really is an object
> that represents a type of number from the external system. Previously,
> there was a nice, clean mapping between external types and Python types.
> Now there is not so clean a mapping. Not that that makes
On Mon, 20 Jun 2005, Keith Dart wrote:
> But then I wouldn't know if it overflowed 32 bits. 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 la
On Mon, 20 Jun 2005, Guido van Rossum wrote:
> [Keith Dart]
>> In SNMP, for example, a Counter32 is basically an unsigned int, defined
>> as "IMPLICIT INTEGER (0..4294967295)". One cannot efficiently translate
>> and use that type in native Python. Currently, I have defined an
>> "unsigned" type a
[Keith Dart]
> In SNMP, for example, a Counter32 is basically an unsigned int, defined
> as "IMPLICIT INTEGER (0..4294967295)". One cannot efficiently translate
> and use that type in native Python. Currently, I have defined an
> "unsigned" type as a subclass of long, but I don't think that would b
On Sun, 19 Jun 2005, Josiah Carlson wrote:
>
> Keith Dart <[EMAIL PROTECTED]> wrote:
>
>> Therefore, I would like to ask here if anyone has already started
>> something like this? If not, I will go ahead and do it (if I have time).
>
> If all you need to do is read or write C-like types to or from
Keith Dart <[EMAIL PROTECTED]> wrote:
> Therefore, I would like to ask here if anyone has already started
> something like this? If not, I will go ahead and do it (if I have time).
If all you need to do is read or write C-like types to or from memory,
you should spend some time looking through t
On Sat, 18 Jun 2005, Michael Hudson wrote:
>
> The shortest way I know of going from 2149871625L to -2145095671 is
> the still-fairly-gross:
>
v = 2149871625L
~int(~v&0x)
> -2145095671
>
>> I suppose the best thing is to introduce an "unsignedint" type for this
>> purpose.
>
> Or
Keith Dart <[EMAIL PROTECTED]> writes:
> I am very concernced about something. The following code breaks with 2.4.1:
>
> fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
>
> Where RTC_RD_TIME = 2149871625L
>
> In Python 2.3 it is -2145095671.
Well, you could always use "-2145095671"...
> Actually, thi
Guido van Rossum wrote:
>On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>
>>IIRC, there was a decision to not implement phase C and to keep the
>>trailing L in representations of long integers.
>>
>>
>
>Actually, the PEP says phase C will be implemented in Python 3.0 and
>that's
Guido van Rossum wrote:
> On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>IIRC, there was a decision to not implement phase C and to keep the
>>trailing L in representations of long integers.
> For 2.x, yes. I'm fine with marking it as Final and adding this to PEP
> 3000 instead.
Since
On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> IIRC, there was a decision to not implement phase C and to keep the
> trailing L in representations of long integers.
Actually, the PEP says phase C will be implemented in Python 3.0 and
that's still my plan.
> If so, I believe the PEP ca
IIRC, there was a decision to not implement phase C and to keep the
trailing L in representations of long integers.
If so, I believe the PEP can be marked as final. We've done all we're
going to do.
Raymond
___
Python-Dev mailing list
Python-Dev@pyth
22 matches
Mail list logo
