Q about assignment and references

[Stephen Hansen]

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.