Title: struct module inconsistent with CPython
Type: Severity: normal
Components: Library Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: ellisj, leouserz, pjenvey, ype
Priority: low Keywords:

Created on 2003-06-13.07:34:37 by anonymous, last changed 2008-06-08.03:29:47 by pjenvey.

File name Uploaded Description Edit Remove nobody, 2003-06-13.07:34:37 demonstration of struct bug
msg850 (view) Author: Nobody/Anonymous (nobody) Date: 2003-06-13.07:34:37
See attached file

Steven Jones
msg851 (view) Author: Ype (ype) Date: 2003-06-15.18:32:28
Logged In: YES 

When testing this again, try opening in 'wb' mode also. 
msg852 (view) Author: Jonathan Ellis (ellisj) Date: 2004-02-25.21:23:11
Logged In: YES 

The behavior Steven describes is PyFile-related, not struct-
related.  You could verify this by checking that value == 
unpack(format, pack(format, value))[0].

I don't think PyFile's behavior when writing binary data to a 
non-binary file is really a bug; more like acceptable platform-
specific behavior.  [The responsible party is 
PyFile.FileFormat.getBytes.]  If you change 'w' and 'r' to 'wb' 
and 'rb' in Steven's example, Jython gives the same results as 
msg853 (view) Author: Deleted User leouserz (leouserz) Date: 2007-01-16.21:24:30
This does seem PyFile related as ellisj states.  Im outputing one string but when reading it in Im seeing a different string.  Maybe there is something wrong with the read code....  Thanks for the test case by the way.

msg854 (view) Author: Deleted User leouserz (leouserz) Date: 2007-01-16.22:41:33
yes, it appears that we permanently lose information if encoded to the filesystems default encoding.  If we encode a code point beyond 127 it looks like its byte representation becomes 63.  From the value of 63, we get a fine decoding of unicode value 63.  In other words, by coding to the platform specific value we go in a one way direction... :(.  At least this is how it looks on my system....

msg3247 (view) Author: Philip Jenvey (pjenvey) Date: 2008-06-08.03:29:46
trunk fixes this, its file object acts much more like CPython's

I reproduced the mismatch in values on Windows with Jython 2.2. Jython 
trunk on windows returns the correct value
Date User Action Args
2008-06-08 03:29:47pjenveysetstatus: open -> closed
resolution: fixed
messages: + msg3247
nosy: + pjenvey
2003-06-13 07:34:37anonymouscreate