On 03/04/2013 10:20 AM Antonio Cuni wrote:
On 03/04/2013 09:42 AM, Roger Flores wrote:
On March 3, 2013 2:20 AM, Carl Friedrich Bolz wrote:
Are you*sure* you are running on a 64 bit machine?
Sure? No. I assumed it's 64bit pypy because it was generating x86_64
instructions. How would you check for sure?
uname reports x86_64 on the machine I built pypy on.
$ pypy --version
Python 2.7.3 (42c0d1650cf4, Feb 23 2013, 01:53:42)
[PyPy 2.0.0-beta1 with GCC 4.6.3]
That doesn't show the machine size.
pypy --info is interesting but doesn't help either
just a wild guess: is it possible that you generated pyc files with a 32bit
version of pypy and then imported it on a 64bit one?
For example, suppose you have this foo.py:
def foo():
return 2147483648
print type(foo())
if you import it on 32bit, it prints 'long' and generates a pyc file. If you
then import 'foo' on 64bit, it still prints 'long', but if you remove the pyc
and import again, it prints 'int'.
(This happens because 2147483648 is stored as a long inside the marshalled pyc
file).
ISTM like such a cross-import should print a warning or something (maybe silent
reimport?) even if you don't want to call it a bug.
<rant_warning>
Something bothers me about calling alternate representations different "types."
ISTM HLL types are (or should be) abstract, and concrete representation choices
are implementation details.
I'm ok with "type" from the vocabulary of C, where it *does* (now that C99
supplies specific representation-sized typedefs without having to hack them
ourselves ;-) map to choices of representation of different abstract types.
But -- I am not comfortable with type(2**31) printing two different things
in the same *HL* language, unless it is an introspection into the
implementation,
in which case I think it ought not to be called "type" but instead maybe for
example
"rtype" (for representation-type),and let "type" be reserved for abstract types
of the language. Thus we might get, e.g., (faked OTTOMH):
>>> type(2**31) # on either 64 or 32 bit interpreter
<type 'int'>
>>> type(2**63) # on either 64 or 32 bit interpreter
<type 'int'>
and current behavior extended via "rtype"
>>> rtype(2**31) # on 64 bit interpreter
<rtype 'int64_t'>
>>> rtype(2**31) # on 32 bit interpreter
<rtype 'intBInnn'> # BI for BigInt of some design nnn
>>> rtype(2**30) # on 32 bit interpreter
<rtype 'int32_t'>
>>> rtype(2**63) # on either 64 or 32 bit interpreter
<rtype 'intBInnn'> # BI for BigInt, nnn to identify different versions
if desired
by the same token, arguably an abstract string is a sequence of abstract
characters,and
>>> type(''), type(u'') # should give you
(<type 'string'>, <type 'string'>) # not (<type 'str'>, <type
'unicode'>)
whereas rtype could reveal strings as being represented as byte sequences with
or latin1 or(
dingbat encoding, or utf8 or various other unicode or wchar_t unicode etc.
Might be interesting if rtype could track jitted and ffi representations too,
and still
have type say the right thing for type(thing). Sorry, got carried away ;-/
</rant_warning>
BTW, what happens if you import in the opposite order?
Can the 32-bit interpreter process the 64-bit pyc?
Regards,
Bengt Richter
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
