Error when write dicom with Ironpython

[GoogleCodeExporter]

c:\> ipy
IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18408 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> import dicom
>>> da = dicom.read_file("CT.test01.dcm")
>>> dicom.write_file("CT.out.dcm")

Which causes the following error message:

File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 338, in 
write_file
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 278, in _write_file_meta_info
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 196, in write_dataset
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 132, in write_data_element
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filebase.py", line 47, in write_tag
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filebase.py", line 86, in write_leUS

Original issue reported on code.google.com by shkt...@gmail.com on 13 May 2014 at 6:41

[GoogleCodeExporter]

Could you please provide the remainder of the error message? There should be 
one more line right after the trace that you've pasted here with the actual 
error message.

Thanks

Original comment by Suever@gmail.com on 13 May 2014 at 6:43

[GoogleCodeExporter]

Forget the last line of the error message:

TypeError: expected str, got bytes

Original comment by shkt...@gmail.com on 13 May 2014 at 6:59

[GoogleCodeExporter]

Indeed revision r455026896441 changed struct formats from string to byte 
literals. I'm not sure why this would be needed for Python 3. The Python 3 
struct.pack() documentation and example code do not refer to byte literals for 
the format:
https://docs.python.org/3/library/struct.html#examples

You need to change line:
self.write(pack(b"<H", val))
back to:
self.write(pack("<H", val))

The same for other similar errors.

Original comment by Dimitri....@gmail.com on 7 Jun 2014 at 10:29

[GoogleCodeExporter]

Thanks for your help, Dimitri. Originally, I had thought that maybe the 
explicit byte literals for the format were to help with 2to3 conversion as it 
often performs better when you explicitly state types, but it appears that is 
not the case in this instance. That is a simple change that we can definitely 
make.

There are, however, bigger problems with IronPython compatibility. After making 
this basic change IronPython will still fail many of the unit tests because of 
the difference in handling of strings in IronPython and standard Python 2.x. It 
will likely take a decent amount of effort to get the code base to be 
compatible with IronPython, Python 2.x, and 3.x and I just haven't had the 
opportunity to take a closer look at this. I'm willing to try to tackle this at 
some point, but anyone who has more experience with IronPython is welcome to 
pitch in.

Original comment by Suever@gmail.com on 7 Jun 2014 at 4:40