#4 UTF-encoded cif files do not work

[Peter Brommer]

In line 985 and 989 of uctools.py, the translate method is called with 2 arguments. However, for unicode objects, the translate method only accepts one argument (see http://docs.python.org/2.7/library/stdtypes.html#string-methods ). This causes the try to fail (silently), and we're left without a H-D string. This then leads to the error message
"***Error: cell setup: Found neither Hall nor H-M symbol and space group 227 does not have a unique setting."

Offending cif is attached.

[Peter Brommer]

And, a little tampering (and this thread on stack overflow) provides a quick fix:

~~~~~~
:::python
remove_whitespace_map = dict((ord(char), None) for char in string.whitespace)
try:
self.HMSymbol=cifblock['_symmetry_space_group_name_H-M'].translate(remove_whitespace_map)
except:
pass
try:
self.HMSymbol=cifblock['_space_group_name_H-M_alt'].translate(remove_whitespace_map)
except:
pass
~~~~~~~

makes my unicode file run.

Hope that helps.

[Torbjörn Björkman]

This does not give me any problems. Weird.

[Torbjörn Björkman]

Ah, I had to set UTF encoding in the file. I get a different problem though and there is also the problem that a correc CIF file is not in fact allowed to use anything but ASCII encoding. Yet. That will change in CIF2, so maybe we better think ahead and fix it anyway.

[Peter Brommer]

Hm. Strange. I looked a bit further and found it made a difference, which version of PyCifRW I used. With the 4.0 version, I get the error that can be fixed with my modification. With the 3.5 version, neither version works. This relates to a difference in StarFile.py in ReadStar.

However, when I unpack the cif2cell tar.gz file and use the cif2cell script contained therein, it works with PyCifRW out of the box. If I use the python setup.py generated versions, it does not. The sole difference between those files is that the pre-generated one starts with
~~~~~

!/usr/bin/env python

while the newly generated one starts with

!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

~~~~~~

The fun part is that /usr/bin/env python evaluates to a series of soft links ending up at /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7. Both this file and the other one are actually part of the same Mac Port python27. If I have time, I'll dig a little deeper, where all of this is coming from.