|
I have been using Python 2.3 for my past programs and am now asking whether I should upgrade. The advantage of 2.3 is that a very compact, self-contained runnable download can be built. My DialogDevil is about 900K to download and converting to 2.5 makes it grow to about 1500K.
Without evaluating size, I spent several days looking at Python 3.0 because it has Unicode as the native string type and this seemed to be forward looking.
I have a prototype app built and I evaluated 3.0 by seeing what problems I ran into trying to convert it. I did the conversion manually (not using 2to3) and had little difficulty with changing print statements to print function calls or other syntax changes (e.g. import thread is not import _thread).
Separating out my file I/O methods into binary and text read/writes was a little tedious but straightforward. I implemented file copy as a binary only method because a copy is a copy, after all.
Threading works a little differently, which was a little worrisome. Threads are classified as daemonic and non-daemonic. The threading.setDaemon() call can be used to specify which threads prevent the program from exiting. My experience is that any thread exiting seemed to exit the program. This is a serious loss of application robustness.
I use the ctypes module to interface to Windows. I ran into serious problems interfacing the new unicode/block strings to ctype. Ultimately, I ripped out a major block of code and kept going.
The final problem I ran into is getting my own socket level http server running. It is clear at the buffer level, only a string of binary bytes is being tranmitted. These bytes must be packed into buffer and unpacked from buffers and converted from and to strings of Unicode characters. I did not have a lot of confidence I could do that robustly.
About this time, I stated to question the premise which made 3.0 attractive: that I needed Unicode for a modern application. Two of the crucial operations I need in the first program release are good file handling and text sorting. Besides English, the languages I know best are Japanese,  Spanish, and French. Both Japanese and French have special cases which make sorting very difficult. In Japanese, there needs to be an option to merge Hiragana and Katakana. This is somewhat like doing a case-insensitive sort in English where "a" and "A", etc. are treated as the same character. In French, accented version of the same base character are sorted right to left within the word rather than left to right.
All of this was looking like trying to do an international program in 3.0 was going to be a lot bigger job than I was prepared to tackle.
After comparison with 2.4, 2.5, and 2.6, I decided to stay with 2.3 on Windows.
I then looked at seeing if I could run my prototype on the Mac. MacOS comes with Python 2.5 installed. Based on my experience with 3.0, I pulled all of my ctypes code out of the prototype. When first running on the Mac, I ran into the same issue I saw on 3.0: the threading worked differently.
One of the worst problems converting to Mac was creating a program icon (I kid you not). There are some undocumented secrets using the Icon Composer (1) you must drag and drop the icon into the image. File open does not work. (2) I could never get drag and drop into the mask to work. Instead, the format of the image dropped must contain an image mask. Icon Composer would accept jpg, gif, whatever files but there was no working way to specify a mask. I imagine PNG would work and what I got working was TIF. The program I used to write the TIF had an odd way to specify the mask by using the selection tool and it took me a while to figure that out. I have written a program on Mac which displays html without any chrome (browser controls). Unfortunately, this program was not honoring the CSS and I think is not rendering completely. So, I set it up so that the html renders inside of Safari. I now have a prototype UI working on both the PC and Mac. The image at right is a screenshot with PC on top and Mac on the bottom.
Trackback(0)
|
Section Blog 
TrackBack URI for this entry
Subscribe to this comment's feed