Am Montag 13 Dezember 2010 18:59:24 schrieb Jon Wright:

Numpy is now supposed to be working with python 3.1. It seems the conversion was not as difficult as feared, but they did have several people working on it.

http://www.mail-archive.com/[email protected]/msg26524.html The numpy team documented the porting process here: https://github.com/numpy/numpy/blob/799179d1466f274dfef66d6aeea394b2c7cff729... While at the moment python3 does not give much gain for cctbx (despite imho cleaner syntax) as most of the performance critical code is written in c++ future development of python will most likely travel the py3k road. Therefore in my opinion it would be a good practice to have new cctbx code compatible with python3 wherever it is possible. and to port print statements to the new print function peau-á-peau. For legacy versions of python one could include a universal print function like this: http://www.daniweb.com/code/snippet217214.html That way a future switch to python3 would be less painful. From this rather old message at http://mail.python.org/pipermail/cplusplus- sig/2009-July/014664.html it looks like boost.python should be python3 ready as well by now. So with numpy 1.5 (+scipy) and boost.python most dependencies of cctbx seem to be python3 enabled by now. As more and more libraries move to python3 imho it be good to plan ahead with cctbx as well. Btw. is there a coding style document/policy for cctbx? If so where can I find it and would it be a good idea to add some note there that contributors should check their code for possible incompatibilites using python's "-3" parameter and fix those before commit? With regards, Jan M. Simons Institute of Crystallography RWTH Aachen

Hi Jan,

compatible with python3 wherever it is possible. and to port print statements

to the new print function peau-á-peau. For legacy versions of python one could

include a universal print function like this: http://www.daniweb.com/code/snippet217214.html That way a future switch to python3 would be less painful.

I don't want to burden people with python3 discipline until we get closer to the transition. I think it will be a big effort with or without the steps you are suggesting and that it will be better to concentrate the work as much as possible. (Depending on how fast python3 is picked up we may even want to combine with the transition to C++0x.)

From this rather old message at http://mail.python.org/pipermail/cplusplus- sig/2009-July/014664.html it looks like boost.python should be python3 ready as well by now. So with numpy 1.5 (+scipy) and boost.python most dependencies

of cctbx seem to be python3 enabled by now. As more and more libraries move to

python3 imho it be good to plan ahead with cctbx as well.

Just a note: cctbx does NOT depend on numpy, although recent versions support fast copies from cctbx arrays (scitbx.array_family.flex) to and from numpy arrays if the numpy headers are available at compile time.

Btw. is there a coding style document/policy for cctbx?

There is a little bit in the file phenix_regression/svn_commit_procedures which you can find in the Phenix installers (www.phenix-online.org). The file really should be somewhere else and the tests should be structured and parallelized... but sorry, it is always difficult to find the time for such housekeeping. Let me know if you are interested in svn write access for adding to and maintaining the cctbx. Ralf