[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