[Pythonmac-SIG] cross-platform puzzle

[Charles Hartman]

You were (Bob was) more or less right -- which is no surprise. The 
problem turned out to stem from the fact that when the 
dialog-processing code adds a new word as a dictionary key, what it 
adds is a string that wx.TextCtrl returns when a word is 
double-clicked. On Windows, this included a trailling space, on Mac it 
didn't. So when the word-without-trailing-space was looked up, the 
program could find it on Mac but not on Windows.

So why did my wx.TextCtrl show different double-click behavior on the 
two platforms? Though I'm using Python 2.3 on both, my wxPython on Mac 
is 2.5.3.1 and on Win it was 2.5.2.8 (dumb!) so I thought that might be 
the problem. But no: I upgraded on Win, and I get the same behavior. 
I'll report this on the wxPython list.

Easily fixed, of course -- in the dialog-return code, instead of
		word = selstring.lower()
I just make it
		word = selstring.lower().strip()

Many thanks! It was driving me crazy, and you steered me right.

Charles Hartman
Professor of English, Poet in Residence
http://cherry.conncoll.edu/cohar
http://villex.blogspot.com

On Feb 21, 2005, at 9:15 PM, Bob Ippolito wrote:

>
> On Feb 21, 2005, at 8:58 PM, Charles Hartman wrote:
>
>> On Feb 21, 2005, at 8:03 PM, Bob Ippolito wrote:
>>
>>>
>>> On Feb 21, 2005, at 7:49 PM, Charles Hartman wrote:
>>>
>>>> This may be the wrong list for this question. Send me away if so, 
>>>> but I thought I'd try here first.
>>>>
>>>> I'm building Mac and Windows versions of an application with a 
>>>> dictionary as one main data structure. A dialog box lets the user 
>>>> type a string which is then used to change the value associated 
>>>> with one of the keys, or to generate a new key-value pair. At least 
>>>> if the pair is new, on Windows the test
>>>> 		if word in self.Dict:
>>>> 			newvalue = self.Dict[word]
>>>> fails even though, in the debugger, the string I see for 'word' is 
>>>> identical to one of the keys now visible in self.Dict. This is in 
>>>> Windows only; the Mac version works fine.
>>>>
>>>> The dialog box is making the proper return on both platforms, and 
>>>> the new key-value pair is being inserted into the dictionary. I 
>>>> haven't yet checked what happens if the key was an existing one and 
>>>> only the value is changed, and I suppose that might turn out to be 
>>>> the crucial question. But either way, I'm very puzzled to find a 
>>>> cross-platform disparity in this area. What am I missing?
>>>
>>> I don't think you've provided enough detail to provide a useful 
>>> guess.  You don't even specify what "fails" means, let alone which 
>>> toolkit you're using to collect the input from the user, etc.
>>>
>>> Those two lines of code are going to do the same thing regardless of 
>>> platform and should never raise an exception (if that's what "fail" 
>>> means) -- assuming that Dict is a dict and word is a str or unicode 
>>> (which is what you implied).
>>>
>> Sorry, I'll try to be more specific. I'm using wxPython 2.5.3.1, 
>> developing under Mac 10.3 with the factory-issue Framework Python 
>> 2.3. I'm trying to run also under Win XP (when I get time on a 
>> Windows machine every other day). I'm using the WingIDE on both 
>> platforms.
>
> And on Windows XP you are also using wxPython 2.5.3.1 with Python 2.3?
>
>> The app contains a dictionary whose keys are strings (English words) 
>> and whose values are lists of strings (one string per syllable, 
>> stress encoded as all caps). The program can figure out the 
>> syllabification and stress of about 5/6 of the words it encounters, 
>> so the dictionary contains the exceptions. If the user thinks the 
>> program is giving a word the wrong number of syllables or the wrong 
>> stress, s/he can double-click on the word, which brings up a 
>> wx.Dialog. The dialog has two fields (plus OK and Cancel buttons) The 
>> first field shows how the program thinks the word should be treated 
>> -- either the value associated with it in the dictionary or the value 
>> returned by routines that figure out syllabification and stress. (The 
>> user sees no difference between these cases.) The second field is a 
>> text field that allows the user to type in a new encoding for the 
>> word (syllables delimited by spaces, the stressed syllable in all 
>> caps). The string which the user types in is converted to a list of 
>> strings, like the other values in the dictionary. If the word was 
>> already a key in the dictionary, its value is replaced by the new 
>> one. If not, the word is added to the dictionary as a new key, with a 
>> value which is the list made from the string typed by the user.
>>
>> On both Mac and Windows, the modal wx.Dialog comes up fine. When it's 
>> closed the return value (the string typed by the user) is as 
>> expected. If the word was not a key in the dictionary, it shows up as 
>> a new key whose value is the string the user typed in. All correct on 
>> both platforms.
>>
>> After that, the program goes back and looks up all the words (in the 
>> line of words being processed) in the dictionary. Again, if it 
>> doesn't find a word it calculates how to syllabify-and-stress it. The 
>> method that does this begins by testing whether the word is in the 
>> dictionary:
>> 		if word in self.SD.Dict:
>> 			return self.SD.Dict[word][:]
>> 		else . . .
>> ('word' is the string which may be a dictionary key. 'self' is the 
>> class containing most of the metrical-scansion routines. 'SD' is a 
>> class, of which 'self' owns the unique instance, that's mostly a 
>> wrapper around a data item called 'Dict', which is the dictionary in 
>> question.) So if 'word' is one of the keys in the dictionary, the 
>> second line should return the value -- a syllable-and-stress-encoded 
>> string -- or rather a copy of it so that we don't mess up the 
>> dictionary when we later fiddle with the syllable strings.
>
> Are you sure that 'word' and the return value of wx.Dialog are 
> precisely str or unicode?  Check type(word) to see.  Are you sure that 
> there isn't any extraneous whitespace?  Especially line endings?  On 
> Windows you might see '\r\n' for line endings, where you'll see either 
> just '\r' or just '\n' on Mac OS X (depending on where the string is 
> coming from).  The best way to split lines in Python is the 
> ".splitlines()" method of str or unicode, as it deals with all three 
> flavors (including the obscene mixed line endings case).  You should 
> look at the repr() of word to make sure it has exactly what you expect 
> it to have (probably just the word, with no whitespace or anything).
>
> Note that strings are immutable in Python, and if "Dict" has strings 
> for values then the copy-by-slice is extraneous.  There's no reason to 
> make a copy of an object that can't possibly be changed.  I'm pretty 
> sure that slicing a string like that is going to return the same 
> object anyway.
>
>> That's how it works on Mac. On Windows, with a word that's been added 
>> to the dictionary as a new key, when it gets to the line 'if word in 
>> self.SD.Dict:' it does NOT go to the next line ('return 
>> self.SD.Dict[word][:]'), but skips to the 'else' (which contains code 
>> that calls functions that figure out syllables and stress). By 
>> "fails" I mean the test for 'word' as a key in 'self.SD.Dict' 
>> apparently returns false, even though it has been successfully added.
>>
>> At least this is true when the process involves adding a new key. I 
>> haven't yet tested whether the problem turns up when the key already 
>> existed. But in a way it doesn't matter -- what I don't understand is 
>> why what I think is a very simple dictionary lookup should find the 
>> key on the Mac and not find it on Windows. In the debugger I can look 
>> at both values -- 'word' and an entry in self.SD.Dict -- and see the 
>> same string.
>>
>> Is that any clearer? I know I could easily have made a dumb mistake 
>> that would keep the whole thing from working. But it works perfectly 
>> on Mac and does not work on Windows. That's what has me baffled.
>
> My best guess is whitespace given what you've said..
>
> -bob
>