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(~v0x)
-2145095671
I suppose the best thing is to introduce an unsignedint type for
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* implement
[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 they
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 it a
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 would be x =
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 would
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 a problem,
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
[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 be
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 as a subclass
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 later
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(~v0x)
-2145095671
I suppose the best thing is to introduce an unsignedint type for this
purpose.
Or some kind of bitfield
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 the
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, this is
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
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 PEP 313
16 matches
Mail list logo
