[Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
kirby urner
kirby.urner at gmail.com
Mon Aug 7 23:56:16 CEST 2006
On 8/7/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> On the other hand, after doing even more coding in Python, I'm really
> missing even more all the Smalltalk development tools, a situation which
> PataPata hopes to improve a little, of course, at some continued effort
> which looks somewhat boring/daunting at this point. :-) Venting a little,
> there is also not much one can do about the fact that the Smalltalk syntax
> and message passing approach (to me) is clearer for prototype based
> systems than Python's parenthetical functional notation. This is because
> in Smalltalk or Self, "self x" to get and "self x:" to set are clearly
> messages and not possibly variable accesses, unlike Python's "self.x",
> "self.x = value", "self.x()", "self.x(value)" permutations adding
> possibility for confusion (i.e. should self.x to get a property value be
> used with equals or as a function call?).
Although you've rarely deigned to engage in nitty gritty syntax
discussions when I bring them up, in response to your "judgments",
I'll risk it again:
What's the confusion in this case?
self.x, as seen from the inside, is a property, or a function's
address, likewise a property (looking at it sideways, not loading with
arguments or void, and calling with parentheses [1]).
But usually we'd write obj.x or some such, as if querying an object
from outside. val = obj.x is "getting" whereas obj.x = val is
"setting".
Outside, obj.x specifies a property, whereas use of parentheses
signifies invoking a callable i.e. a method in the object's hierarchy
__dict__s someplace (perhaps way up high in some tree).
The major exception: if we want functions to operate even when the
user gets to use plain old property syntax -- so providing is the
purpose of the infamous property() function (which Arthur thinks was
brough over just to make inferior Java coders feel at home -- and he's
not the only one who thinks that).
If there's ambiguity in Python, it's in __init__ and __call__ both
being invoked by the same syntax (a pair of parentheses). I haven't
made a complete study of all the ways to confuse myself about this
issue, but what experiments I *have* run indicate a rational sense of
operator precedence, i.e. you have to __init__ something before
there's something to even __call__.
Kirby
PS: I expect this'll be rejected from patapata-discuss but I'm
echoing the CC as a matter of courtesy.
[1] A. Martelli talks about this distinction in his discussions about
Ruby. That reminds me of something I posted in wwwanderers.org
recently -- I'll copy here to edu-sig.
More information about the Edu-sig
mailing list