On 2010-04-06 19:51:07 -0700, jdbosmaus said:
Pretty new to Python, but I thought I understood what is meant by "an assignment is a reference."
An assignment isn't really a reference, it binds a name to an object. Not quite the same thing. But, what's really the problem here is -- wxPython is not really Pythonic. wx is written in C++, and has its own semantics which are quite distinct from Python's. wxPython is a wrapper around those classes that make certain attempts at slight Pythonicness, but can't really do very much about it.
For example, in Python? You never get a copy of anything unless you explicitly ask for it. The wx stuff chooses to make copies which have their own little lifetimes at various points. These ideals sometimes align. Many times they do not. (For example, its possible for a wx object to 'die' but its python wrapper to live on-- you'll see a PyDeadObjectError.)
Now, what bothers me is that in the 3rd and 4th lines, the RHS "esource.Font" returns a wx.Font object that is a *copy* of the font object of the button.
Well, first, I'd never write "esource.Font"; the properties just sort of confuse the issue in wxPython. I like properties; I don't really like them in wx contexts.
"blah = esource.Font" is the same as "blah = esource.GetFont()", and yes, it returns a copy. The only way to know that is to read the wx docs. Its sorta un-pythony, but, its how wx works.
And, "esource.Font = blah" is the same as "esource.SetFont(blah)".
Then in the for-loop we assign the font object to a LHS object that ... semantically, looks exactly like the thing that returned a *copy* up above.
On this point, you have to remember: a property looks like an attribute, however its -really- a wrapper around a getter and a setter to do stuff under the hood which is more complicated then actually setting an attribute.
The real problem here is that it was probably a bad decision to use a property for a getter... which isn't a getter, but a copier.
esource.GetFont() isn't terribly more clear that its a Copy operation, but it looks less crazy then the property way of doing things.
There's two different object models here interacting in a non-perfect way. wxWidgets and Python don't quite think alike, so wxPython is slightly schizo. That said, it still is my favorite GUI library. :)
I could understand if the setting-semantics in the for-loop needed to be something like "x.SetFont(fontUn)", or even "x.SetFont = fontUn". (for "could understand" read "would be much happier.")
x.SetFont(fontUn) works perfectly well :)
What I can't understand is how the semantics that actually works makes sense in terms of Python's assignment conventions.
You basically sort of have to build a wall when dealing with wxObjects. They don't really always behave like regular Python objects, so using them -like- Python Objects (e.g., with properties instead of the accessors) tends to confuse matters.
-- --S ... p.s: change the ".invalid" to ".com" in email address to reply privately. -- http://mail.python.org/mailman/listinfo/python-list
