diff --git a/wxPython/CHANGES.txt b/wxPython/CHANGES.txt
index 6de0030784..b1f3316222 100644
--- a/wxPython/CHANGES.txt
+++ b/wxPython/CHANGES.txt
@@ -146,7 +146,7 @@ Fixed the ActiveXWrapper problem.  Looks like when the win32com
 modules make a "callback" that they (incorrectly, IMHO) allocate a
 transient thread state structure.  Since wxPython is now saving
 tstates for it's own callbacks it ended up using garbage after
-win32com gots rid of the tstate...
+win32com got rid of the tstate...
 
 
 
diff --git a/wxPython/src/helpers.cpp b/wxPython/src/helpers.cpp
index 8be7e483b5..6ccc430366 100644
--- a/wxPython/src/helpers.cpp
+++ b/wxPython/src/helpers.cpp
@@ -590,10 +590,10 @@ void wxPySaveThreadState(PyThreadState* tstate) {
             if (info.tstate != tstate)
                 wxLogMessage("*** tstate mismatch!???");
 #endif
-            // info.tstate = tstate;    *** DO NOT updating existing ones???
+            // info.tstate = tstate;    *** DO NOT update existing ones???
             // Normally it will never change, but apparently COM callbacks
             // (i.e. ActiveX controls) will (incorrectly IMHO) use a transient
-            // tstate wich will then be garbage the next time we try to use
+            // tstate which will then be garbage the next time we try to use
             // it...
             wxPyTMutex->Unlock();
             return;