Q about assignment and references
apt.shansen at gmail.invalid
Wed Apr 7 05:31:04 CEST 2010
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
> 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
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.
... p.s: change the ".invalid" to ".com" in email address to reply privately.
More information about the Python-list