[Pythonmac-SIG] cross-platform puzzle

[Bob Ippolito]

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