I recently started on a project where I'd like to use wxPython to make
a GUI. The project involves the running of some algorithm that returns
a double, indicating the result of the given parameters, let's call
the module foo.
Now, this code works:
···
----------
import foo
parameter_file = "my_parameters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
----------
But this code behaves unexpectedly:
-------------
import foo
import wx
app = wx.App()
parameter_file = "my_paremeters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
---------------
Both snippets of code will run fine, but the first will return a value
somewhere along 0.06, while the second one returns values somewhere
along 0.00005. Now, the outcome is not deterministic but it should not
vary this much, and the problem can be easily seen by commenting out
the line app = wx.App() and uncommenting it.
So, apparently, somehow, the initalization of the wx.App interferes
with the module foo. Does anyone have a suggestion on where to look
for the problem?
This is on a machine running 32-bit Ubuntu 11.04 by the way.
GTK will set the locale settings based on the environment when it is initialized (which happens during the creation of the wx.App object.) Does your module foo do anything that could be dependent on locale settings, such as whether "," and "." are thousands separator and decimal point, or vice versa?
···
On 6/16/11 3:12 AM, Egbert van der Wal wrote:
I recently started on a project where I'd like to use wxPython to make
a GUI. The project involves the running of some algorithm that returns
a double, indicating the result of the given parameters, let's call
the module foo.
Now, this code works:
----------
import foo
parameter_file = "my_parameters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
----------
But this code behaves unexpectedly:
-------------
import foo
import wx
app = wx.App()
parameter_file = "my_paremeters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
---------------
Both snippets of code will run fine, but the first will return a value
somewhere along 0.06, while the second one returns values somewhere
along 0.00005. Now, the outcome is not deterministic but it should not
vary this much, and the problem can be easily seen by commenting out
the line app = wx.App() and uncommenting it.
So, apparently, somehow, the initalization of the wx.App interferes
with the module foo. Does anyone have a suggestion on where to look
for the problem?
This is on a machine running 32-bit Ubuntu 11.04 by the way.
I recently started on a project where I'd like to use wxPython to make
a GUI. The project involves the running of some algorithm that returns
a double, indicating the result of the given parameters, let's call
the module foo.
Now, this code works:
----------
import foo
parameter_file = "my_parameters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
----------
But this code behaves unexpectedly:
-------------
import foo
import wx
app = wx.App()
parameter_file = "my_paremeters"
result = foo.run(parameter_file)
print "The result was: %.5f" % result
---------------
Both snippets of code will run fine, but the first will return a value
somewhere along 0.06, while the second one returns values somewhere
along 0.00005. Now, the outcome is not deterministic but it should not
vary this much, and the problem can be easily seen by commenting out
the line app = wx.App() and uncommenting it.
So, apparently, somehow, the initalization of the wx.App interferes
with the module foo. Does anyone have a suggestion on where to look
for the problem?
This is on a machine running 32-bit Ubuntu 11.04 by the way.
GTK will set the locale settings based on the environment when it is initialized (which happens during the creation of the wx.App object.) Does your module foo do anything that could be dependent on locale settings, such as whether "," and "." are thousands separator and decimal point, or vice versa?
You are right. I never knew that the input and output of iostream did depend on locale settings, but apparently a setlocale(LC_ALL, "C") before running the rest of the code fixes it.