By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,675 Members | 2,270 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,675 IT Pros & Developers. It's quick & easy.

Why we will use obj$func() often

P: n/a
"Michael Geary" <Mi**@Geary.com> wrote ...
Does anyone have some sample code where obj$func() would be used?
(Apologies if I missed it.)


There have been so many messages about delegation and binding since Greg
originally posted his meowing cat message that it's hard to remember what
the original problem was that Greg pointed out. At that time Prothon had no
solution for the problem. Now there is a released solution but it is
incomplete and has broken the xor operator ( ^ ) (don't tell anyone <grin>).
I'll restate it here in my own way (this is copied from something I posted
on comp.lang.py).

Statement of problem (These are tested programs from released Python and
Prothon:):

# Python

class klass:
def __init__(self):
self.me = 1
def func(self):
print "func1,self"+str(self.me),

class klass2(klass):
def __init__(self):
self.me = 2
def func(self):
klass.func(self) # delegation
print "func2,self"+str(self.me),

inst = klass2()
inst.func() # prints func1,self2 func2,self2

# Directly translated to Prothon

Klass = Object()
with Klass:
.me = 0 # extra line
def .__init__():
.me = 1
def .func():
print "func1,self"+.me,

Klass2 = Klass()
with Klass2:
def .__init__():
.me = 2
def .func():
Klass.func() # does not do what python does
print "func2,self"+.me,

inst = Klass2()
inst.func() # prints func1,self0 func2,self2

As you can see, the call Klass.func() got the function func from the object
Klass and then called it on Klass using Klass as the target "self" instead
of the instance "inst". This is not what Python did and this is the
problem.

In Python the call klass.func() was different because Python knows that
klass is a class and therefore obviously cannot be the target of call (an
instance), so it made the programmer pass the instance self to use as a
parameter.

To fix this, we need to be able to specify in general, what the self object
is going to be during the execution of a function in Prothon (I call this
choice of self "binding self to function" even though it's temporary during
execution).

Greg's solution was to replace the period before the function name in
klass.func() with a different symbol to indicate that the func is not
supposed to be bound to klass as the syntax normally suggests (as in
list.sort!()), but instead defaults to the current self. My final scheme is
almost the same but instead of just defaulting to self, it specifically
forces it to self (this may seem like a semantic difference, but don't say
that to Greg <grin>).

So now we have this solution. Note that delegation to an ancestor prototype
(class in Python), is a common operation, especially in the __init__
function:

Klass = Object()
with Klass:
def $__init__():
$me = 1
def $func():
print "func1,self"+$me,

Klass2 = Klass()
with Klass2:
def $__init__():
$me = 2
def $func():
Klass$func() # voila! problem fixed
print "func2,self"+$me,

inst = Klass2()
inst.func() # prints func1,self2 func2,self2

Jul 18 '05 #1
Share this Question
Share on Google+
90 Replies


P: n/a
My apologies. I posted this to c.l.p. by accident. I meant to post this
to Prothon-users.

"Mark Hahn" <ma**@prothon.org> wrote in message
news:d2Uhc.22272$dZ1.1600@fed1read04...
"Michael Geary" <Mi**@Geary.com> wrote ...
Does anyone have some sample code where obj$func() would be used?
(Apologies if I missed it.)
There have been so many messages about delegation and binding since Greg
originally posted his meowing cat message that it's hard to remember what
the original problem was that Greg pointed out. At that time Prothon had

no solution for the problem. Now there is a released solution but it is
incomplete and has broken the xor operator ( ^ ) (don't tell anyone <grin>). I'll restate it here in my own way (this is copied from something I posted
on comp.lang.py).

Statement of problem (These are tested programs from released Python and
Prothon:):

# Python

class klass:
def __init__(self):
self.me = 1
def func(self):
print "func1,self"+str(self.me),

class klass2(klass):
def __init__(self):
self.me = 2
def func(self):
klass.func(self) # delegation
print "func2,self"+str(self.me),

inst = klass2()
inst.func() # prints func1,self2 func2,self2

# Directly translated to Prothon

Klass = Object()
with Klass:
.me = 0 # extra line
def .__init__():
.me = 1
def .func():
print "func1,self"+.me,

Klass2 = Klass()
with Klass2:
def .__init__():
.me = 2
def .func():
Klass.func() # does not do what python does
print "func2,self"+.me,

inst = Klass2()
inst.func() # prints func1,self0 func2,self2

As you can see, the call Klass.func() got the function func from the object Klass and then called it on Klass using Klass as the target "self" instead
of the instance "inst". This is not what Python did and this is the
problem.

In Python the call klass.func() was different because Python knows that
klass is a class and therefore obviously cannot be the target of call (an
instance), so it made the programmer pass the instance self to use as a
parameter.

To fix this, we need to be able to specify in general, what the self object is going to be during the execution of a function in Prothon (I call this
choice of self "binding self to function" even though it's temporary during execution).

Greg's solution was to replace the period before the function name in
klass.func() with a different symbol to indicate that the func is not
supposed to be bound to klass as the syntax normally suggests (as in
list.sort!()), but instead defaults to the current self. My final scheme is almost the same but instead of just defaulting to self, it specifically
forces it to self (this may seem like a semantic difference, but don't say
that to Greg <grin>).

So now we have this solution. Note that delegation to an ancestor prototype (class in Python), is a common operation, especially in the __init__
function:

Klass = Object()
with Klass:
def $__init__():
$me = 1
def $func():
print "func1,self"+$me,

Klass2 = Klass()
with Klass2:
def $__init__():
$me = 2
def $func():
Klass$func() # voila! problem fixed
print "func2,self"+$me,

inst = Klass2()
inst.func() # prints func1,self2 func2,self2


Jul 18 '05 #2

P: n/a
Mark Hahn wrote:
My apologies. I posted this to c.l.p. by accident. I meant to post this
to Prothon-users.

Oh, no problem, there's some Python content (see below for some comments
on it)...
....
# Python

class klass:
def __init__(self):
self.me = 1
def func(self):
print "func1,self"+str(self.me),

class klass2(klass):
def __init__(self):
self.me = 2
def func(self):
klass.func(self) # delegation
print "func2,self"+str(self.me),

inst = klass2()
inst.func() # prints func1,self2 func2,self2
....
In Python the call klass.func() was different because Python knows that
klass is a class and therefore obviously cannot be the target of call (an
instance), so it made the programmer pass the instance self to use as a
parameter.

This isn't really a very clear description of what's going on in
Python. It won't matter to the Prothon users, but don't want any Python
users to get confused...

Looking up klass.func returns an unbound instance method, this is a
function wrapper which basically just says "hey, you're a member
function of a class, check to be sure that your first argument is a
member of that class". This is done by the function's descriptor
hooks which allow it to return a wrapped object when the user
attempts to retrieve the value from another object (such as a class
or an instance). So, in a sense, yes, the class cannot be the
target of that *particular* call, as the unbound method object you
retrieved will reject anything other than an instance of the class.

Bound instance methods are a similar wrapper, but they say
"curry/bind your first argument (normally self) to this value then
call the underlying function". They are created on object.method
access by the same function descriptor hooks.

The point of all that being that classes most definitely *can* be the
target of a call. Python's classes are first-class objects. In
particular, they are instances of metaclasses, and can have meta-methods
defined which take the class as their first parameter just like a normal
method-call.
class k(type): .... def r( cls ):
.... return 42
.... class x: .... __metaclass__ = k
.... x.r() 42


There's very little "special" about classes other than that they have
some syntactic shortcuts for creating them and for looking up attributes
of their instances within them. Python isn't looking at every method
call and saying "hey, that's a class, that can't be the first parameter
to a function/method!", it (particularly the unbound instance object) is
saying "hey, you're not an instance of my class, go to heck" and never
thinks about whether the object is *particularly* a class or not.

Classes are special in Python, but not nearly as special as you might
think from a class-less perspective :) ,
Mike

By the way, the modern Python idiom is:

super( klass2, self ).func( )

but that wouldn't help in explaining the logic for the Prothon
choice, so no biggie :) .

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #3

P: n/a
Mike C. Fletcher wrote:
This isn't really a very clear description of what's going on in
Python. It won't matter to the Prothon users, but don't want any
Python users to get confused...
My inability to understand this stuff is what drove me to do Prothon <grin>.
All the hidden wrapped this and wrapped that confused me to no end.
By the way, the modern Python idiom is:

super( klass2, self ).func( )


You're kidding. That seems like a big leap backwards in friendliness. Kind
of a syntax castor oil.

That's explains why Joe Mason did his proposal for Prothon delegation using
that same idiom for Prothon. I thought he was somewhat crazy wanting us to
type all that each time.

What problem caused Python to want to switch to such a general operation?
What is the usage case that is so important that it is making eveyone wear
out their keyboards typing that monstrosity?

Oh well, I guess it gives me one more argument to pitch for Prothon...
Jul 18 '05 #4

P: n/a
Mark Hahn wrote:
My inability to understand this stuff is what drove me to do Prothon
<grin>.
All the hidden wrapped this and wrapped that confused me to no end. ... You're kidding. That seems like a big leap backwards in friendliness.
Kind
of a syntax castor oil.


Says the guy who's introducing a new operator to his language before
even understanding the behavior of the original one, by his own
admission ...

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Human love is often but the encounter of two weaknesses.
-- Francois Mauriac
Jul 18 '05 #5

P: n/a

"Erik Max Francis" <ma*@alcyone.com> wrote ...
Says the guy who's introducing a new operator to his language before
even understanding the behavior of the original one, by his own
admission ...


Well, I do tend to exaggerate a bit. I can understand it when I study it,
but in everyday coding it does not roll off my fingers. Also, it is
possible to design something new without understanding the old. It might
even be an advantage in some circumstances to not be tainted by old
concepts.

I am serious when I say I think that Python has headed off into egghead land
a bit and I feel that keeps a lot of people from switching to it. I think
that this heady stuff scares them off. I really am trying to make things
simpler in Prothon. Now, whether I can succeed or not is another question.
Only time will tell.
Jul 18 '05 #6

P: n/a
Mark Hahn wrote:
Well, I do tend to exaggerate a bit. I can understand it when I study
it,
but in everyday coding it does not roll off my fingers. Also, it is
possible to design something new without understanding the old.
It is _possible_. But it is not a very good idea.
I am serious when I say I think that Python has headed off into
egghead land
a bit and I feel that keeps a lot of people from switching to it. I
think
that this heady stuff scares them off. I really am trying to make
things
simpler in Prothon. Now, whether I can succeed or not is another
question.
Only time will tell.


Other than the basic premise of Prothon, every single decision I've seen
you make (or consider) looks wholly stylistic, awkward or even arcane,
and the opposite of the one I, or I think Guido, would have chosen.
Being a fan of Io, I think prototype-languages are interesting. Even so
far, I lost interest in looking at the actual main feature of Prothon,
after seeing all the extra baggage that was brought on in unecessary
stylistic changes.

Seriously considering every single possible proposal is not
constructive. Without a strong sense of what the language should look
like, Prothon is going to continue to look more and more like Perl.
It's already most of the way there.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I love Mickey Mouse more than any woman I've ever known.
-- Walt Disney
Jul 18 '05 #7

P: n/a
Mark Hahn wrote:
I am serious when I say I think that Python has headed off into egghead land
a bit and I feel that keeps a lot of people from switching to it. I think
that this heady stuff scares them off.


Not likely. Most people learning or using Python still have little
interest in or need for metaclass programming, and I *strongly*
doubt it has scared off more than a handful of people.

Likewise, the differences between prototype-based languages and
class-based languages do not appear significant enough to be
the sole reason to pick one over the other. The community,
on the other hand, and the libraries -- well, those are good
reasons for picking Python. It will be interesting to see whether
Prothon manages to achieve similar success in either area.
And if it does, well, see my first point in this sentence again...

-Peter
Jul 18 '05 #8

P: n/a
Mark Hahn wrote:
Mike C. Fletcher wrote:
By the way, the modern Python idiom is:

super( klass2, self ).func( )


You're kidding. That seems like a big leap backwards in friendliness.


Don't worry, the traditional form of super call in Python
isn't going away any time soon. It's not replaced by this;
they do different things.

The new form is occasionally needed, but not very often.
I haven't found a use for it myself yet. (I *thought* I
had found one the other day, but it turned out I hadn't.)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Jul 18 '05 #9

P: n/a

"Peter Hansen" <pe***@engcorp.com> wrote ...
It will be interesting to see whether
Prothon manages to achieve similar success in either area.


I apologize if I got competitive. As I have said many times, I don't
expect Prothon to compete with Python. It's hard to bust your butt on
something day in and out without getting carried away.
Jul 18 '05 #10

P: n/a

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:40***************@alcyone.com...
Seriously considering every single possible proposal is not constructive.
I could see one making an argument about efficiency, but to say it's not
constructive is ludicrous.
Without a strong sense of what the language should look
like, Prothon is going to continue to look more and more like Perl.
It's already most of the way there.


You haven't seen the final product. My design process is (and always has
been) to go through an expansion phase where more and more gets added or at
least considered and then through a contraction phase where the fat gets cut
out. I find this process works very well.

Please hold off your ad hominem attacks until the product is designed, thank
you very much.
Jul 18 '05 #11

P: n/a
On Thu, 22 Apr 2004 20:31:41 -0700, Mark Hahn wrote:
"Erik Max Francis" <ma*@alcyone.com> wrote:
Seriously considering every single possible proposal is not
constructive.
[...]
Without a strong sense of what the language should look
like, Prothon is going to continue to look more and more like Perl.
It's already most of the way there.


Please hold off your ad hominem attacks until the product is designed,
thank you very much.


Please understand what an ad hominem attack is before accusing others of
using it, thank you very much:

<http://www.infidels.org/news/atheism/logic.html#hominem>

Erik's assertions were relating to the topic, not to your person or
circumstances. They were not argumentum ad hominem.

--
\ "If you go to a costume party at your boss's house, wouldn't |
`\ you think a good costume would be to dress up like the boss's |
_o__) wife? Trust me, it's not." -- Jack Handey |
Ben Finney <http://bignose.squidly.org/>
Jul 18 '05 #12

P: n/a

"Ben Finney" <bi****************@and-benfinney-does-too.id.au> wrote ...
Please understand what an ad hominem attack is before accusing others of
using it, thank you very much:


What did I do? Prothon is accused of looking like Perl (which I mistakenly
took as an ad hominem slur, but now I see that he was serious) and I am
accused of not knowing the English language (even though I have degrees from
both Stanford University and Princeton University).

I guess I'll go back to the Prothon mailing lists with my tail between my
legs....
Jul 18 '05 #13

P: n/a
Mark Hahn wrote:

"Ben Finney" <bi****************@and-benfinney-does-too.id.au> wrote ...
Please understand what an ad hominem attack is before accusing others of
using it, thank you very much:


What did I do? Prothon is accused of looking like Perl (which I mistakenly
took as an ad hominem slur,


Ok, I gotta admit, that's understandable.
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #14

P: n/a
Mark Hahn wrote:
Mike C. Fletcher wrote:
This isn't really a very clear description of what's going on in
Python. It won't matter to the Prothon users, but don't want any
Python users to get confused...
My inability to understand this stuff is what drove me to do Prothon <grin>.
All the hidden wrapped this and wrapped that confused me to no end.

Fascinating. Most users never even notice this stuff, let alone getting
so worked up about it that they start a whole separate language ;) .
After all, they don't generally even know that metaclasses *exist* and
just know that it all works exactly as they would expect. You for
instance, were describing how the interpreter just knows that a class
can't be the target of an unbound class method. Sure, *maybe* it's all
a hideously complex mess that has people running screaming from Python
in horror, but from where I sit it is an extremely elegant system that
most people use without any impedance mismatch at all.
By the way, the modern Python idiom is:

super( klass2, self ).func( )


You're kidding. That seems like a big leap backwards in friendliness. Kind
of a syntax castor oil.

Explicit is better than implicit. You are attempting to call the
superclass' method; using:

klass.func( self )

is actually a far less maintainable and composable idiom. Here you are
saying "call this *particular* superclass' method", introducing a
dependency on the class' current superclass inside the method call. The
super() version does introduce a dependency on the *current* class
inside the call, but that's generally far less likely to mess up as code
gets revised.

super(), in other words, is a practical solution to avoiding the
explicit dependencies that crop up when you directly reference a
super-class. It solves problems *for large-systems developers* who need
robust, cooperative, composable functionality (e.g. via mix-in
classes). klass.func() might seem prettier and shorter in small
systems, but it's something that Python's user community has outgrown
over the years (if you can troll so can I ;) ).
That's explains why Joe Mason did his proposal for Prothon delegation using
that same idiom for Prothon. I thought he was somewhat crazy wanting us to
type all that each time.

It's not the most elegant spelling of the idiom, that's true, but it was
added without introducing any new magic. When creating a new language
you can decide to add new magic to the system solely as a question of
"what is right". When evolving a highly successful system, introducing
new magic is a serious concern:

super.func()

with super as a key-word would be fine in Prothon, as there's no code
that depends on using the name super.

super().func()

would work just as well, with the interpreter figuring out which class
super() is being called from within but what happens when it's defined
outside a class and injected later? After all, it's the class where it's
*defined* that matters, not the one where it's being used. So Guido
went for the minimum of magic. There's no special restriction on a
function that uses super that the function must be defined in a class,
there's no rules to figure out whether it affects inner or outer
classes, there's, in short, no magic required to learn the idiom, it's a
simple class instantiation like just about everything else.

Special cases aren't special enough to break the rules.
Although practicality beats purity.

super is used primarily by large-systems developers (meta-programmers),
so having the functionality require the introduction of special magic
and rules for regular users (every time they see an instance of "magic"
they need to learn what it does) seems unnecessarily "special".
Implementing super as a simple class means that, should someone be
interested, they can simply look up the implementation and go "ah, I see
what it does", but until then they can understand it as a simple call
that returns a wrapper which gives the superclass of the passed class in
the passed instance' mro... i.e. it's a black box that follows all the
regular rules of functions/callables in Python.

Language design is about balancing the minimal set of ideas needed to
give full generality and power with the need for expressivity and
practicality. So far Guido's decisions have been, IMO, a fairly good
balance. There are warts, but every language will have warts. Python
is a *small* language where, particularly in the later incarnations the
special cases are going away and the same basic mechanisms are getting
used in more and more places (e.g. with descriptors). The reduction of
special cases is an important design tool.
What problem caused Python to want to switch to such a general operation?
What is the usage case that is so important that it is making eveyone wear
out their keyboards typing that monstrosity?

Remember, this is the Python list, we tend to find hugely rhetorical
arguments somewhat off-putting ;) . On the other hand, we've
extinguished more potential flamewars than I can count over the years,
so it's not like the universe is going to collapse because of a few
overblown statements :) . If it did I would have doomed us all ages ago
:) .
Oh well, I guess it gives me one more argument to pitch for Prothon...

Sure, the magic you sprinkle through your system is part of its flavour
and character, that character is how languages sell themselves. Though
honestly, if someone seriously came up to me and said:

"Switch to Frobnaz, it has explicit syntax for referencing a
superclass rather than that archaic explicit invocation stuff in Python"

I'd probably dismiss them out of hand as being so totally out of touch
with reality as to be not worth the effort of listening (well, not
really, I *try* not to dismiss people out of hand no matter how crazy
they are). Addressing a few of Python's warts is *not* going to make
the world beat a path to your door. If you are going to get people to
make a clean leap to your language (i.e. it's not source-code compatible
with their current language, and doesn't have some compelling
feature/niche) you need to design something that's about two times
better, and you don't design something twice as good by copying and
tweaking. You do it by making intelligent design decisions that create
a coherent language that fits well with people's expectations, that fits
in their mind without a lot of magic and arbitrary rules to remember
(PERL, of course being the exception that proves the rule, where the
attempt is to simply guess everything the user might want to do and
create an explicit syntax for that ;) ).

Your language *will* have it's own warts, that's a simple reality,
pointing out that you don't have the same warts *in the same places* as
another language is not a compelling argument for switching. For
instance, I would almost certainly consider the fishHeight$Somewhere()
syntax to be a wart ;) , so being told that I can save 20 characters or
so in typing super (which I've only done maybe one or two hundred times
since it was introduced) by introducing something that my end-developers
are going to have to be trained on doesn't really make me wet my pants
in anticipation and joy :) . After all, I've probably typed almost that
much in this email alone.

Oops, dang keyboard wore out again ;) ,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #15

P: n/a
Mike C. Fletcher wrote:
Fascinating. Most users never even notice this stuff, let alone getting
so worked up about it that they start a whole separate language ;) .
Well, I do exaggerate a bit :)
super(), in other words, is a practical solution to avoiding the
explicit dependencies that crop up when you directly reference a
super-class.
Prothon also has a seperate super operator ( ^ ). ^var means to get the
first attrbute named var from a prototype of self instead of self itself.
It uses the ordered list of prototypes like Python does. So ^func() does
what you are referring to.

Internally in the interpreter I have the full Python super function almost
exactly. It's no coincidence. You need that to make inheritance work. I
can bring it out for the Prothon user, but I originally designed prothon
with keywords and symbols, not functions, something I'm taking a lot of heat
for now.
Sure, the magic you sprinkle through your system is part of its
flavour
and character, that character is how languages sell themselves.
Though honestly, if someone seriously came up to me and said:

"Switch to Frobnaz, it has explicit syntax for referencing a
superclass rather than that archaic explicit invocation stuff in
Python"

I'd probably dismiss them out of hand as being so totally out of touch
with reality as to be not worth the effort of listening (well, not
really, I *try* not to dismiss people out of hand no matter how crazy
they are). Addressing a few of Python's warts is *not* going to make
the world beat a path to your door.
You've stretched my "one more thing to pitch" statement to the extreme
statement of "switch to this because of this one thing". Of course one
isn't going to care about one thing.
Your language *will* have it's own warts, that's a simple reality,
pointing out that you don't have the same warts *in the same places*
as another language is not a compelling argument for switching. For
instance, I would almost certainly consider the fishHeight$Somewhere()
syntax to be a wart ;)


You may very well be right. I'm trying to get it to fit into an overall
scheme, but it may not work. By itself it definitely is a wart. Don't
forget that you are looking at it in the context of Python. It is being put
into a different language with different problems.

My biggest problem right now is stupid aesthetics. I have to decide where
to place Prothon on the continuum between lisp and perl. When I crossed the
line and added $ for self people screamed bloody murder that it looked like
Perl. Before when I had a period for self they thought it looked great. I
can't believe how much they care about something so silly.

Anyway, thanks very much for your input. I'm sorry if you wore out your
keyboard. Luckily the prices have really come down :)
Jul 18 '05 #16

P: n/a
Mark Hahn wrote:
Mike C. Fletcher wrote:

....
Internally in the interpreter I have the full Python super function almost
exactly. It's no coincidence. You need that to make inheritance work. I
can bring it out for the Prothon user, but I originally designed prothon
with keywords and symbols, not functions, something I'm taking a lot of heat
for now.

Heat is a good way to bake ideas and remove impurities.
You've stretched my "one more thing to pitch" statement to the extreme
statement of "switch to this because of this one thing". Of course one
isn't going to care about one thing.

Well, as I said, if you're going to have fun trolling I get to have fun
trolling back ;) . Basically, I'm saying this particular detail is not
an argument worth making on its own. The argument is going to be "it's
a clean, simple, balanced and elegant syntax" and this level of detail
is just part of that picture. Artwork is judged as a whole, and one
might critique a particular facet if it's horrible, but perfection is
assumed otherwise.
You may very well be right.
Never happened before, why assume it'd start now :) .
My biggest problem right now is stupid aesthetics. I have to decide where
to place Prothon on the continuum between lisp and perl.
*poke* surely you see the humour that a Python user will derive from
that statement :) ;) .
When I crossed the
line and added $ for self people screamed bloody murder that it looked like
Perl. Before when I had a period for self they thought it looked great. I
can't believe how much they care about something so silly.

Comparatively, instance-attribute access is used three or four times a
minute when coding, while super is used once or twice a month for
non-framework-programmers, so yes, I can see someone screaming bloody
murder if they suddenly are looking at a screen full of $This and $that
variables. $ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.

Readability counts

BTW, I'm a professional designer, so "stupid aesthetics" are what I care
about whenever I get a chance ;) .
Anyway, thanks very much for your input. I'm sorry if you wore out your
keyboard. Luckily the prices have really come down :)

Unfortunately, MS doesn't make the classic Natural Keyboard any more
(they just make that darned Natural Elite and the
egads-it's-covered-in-pointless-extra-buttons USB Natural), so I have to
savour every keystroke ;) .

That's why I never post to newsgroups,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #17

P: n/a
On Fri, Apr 23, 2004 at 01:24:42AM -0700, Mark Hahn wrote:
My biggest problem right now is stupid aesthetics. I have to decide where
to place Prothon on the continuum between lisp and perl. When I crossed the
line and added $ for self people screamed bloody murder that it looked like
Perl. Before when I had a period for self they thought it looked great. I
can't believe how much they care about something so silly.


I didn't know about your ^ syntax either.

In Python, there is one way[*] to get an attribute on an object. This
works whether it's a data attribute on the instance, a data attribute on
the class or a superclass, an instancemethod, classmethod, or
staticmethod:

obj.attr

Having all of obj.attr, obj$attr and obj^attr *does* reek of perl's
$var, @var, %var distinction (which I have never bothered to
understand).

To me it looks like you've eliminated/combined one thing (instances +
classes become objects) but as a result you've had to invent two new
kinds of complication.

What may have made people jump to a conclusion about $ is that you wrote
something like "$ will remind users of $elf". This reeks of Perl's bad
explanations of why all their internal variables with punctuation names
are really mnemonic for something:
$/ The input record separator, newline by default.
(Mnemonic: / delimits line boundaries when quoting poetry.)
$. Current line number for the last filehandle accessed.
(Mnemonic: many programs use "." to mean the current line
number.)
Yeah, right.

Jeff[*] Yes, I know full well there are other ways you can do it
getattr(obj, "attr"), obj.__dict__['attr'], etc, etc. My point is,
then, that everything can be done with a single "dotted name" syntax.

Jul 18 '05 #18

P: n/a
Mike C. Fletcher wrote:
instance, I would almost certainly consider the fishHeight$Somewhere()


Mike, you haven't been keeping up with the other thread. I think the
decision is now:

fish_height$some_where()

;-) ;-)

-Peter
Jul 18 '05 #19

P: n/a
On Thu, 22 Apr 2004 18:28:37 -0700,
Erik Max Francis <ma*@alcyone.com> wrote:
Being a fan of Io, I think prototype-languages are interesting. Even so
far, I lost interest in looking at the actual main feature of Prothon,
after seeing all the extra baggage that was brought on in unecessary
stylistic changes.


There's a rule in experiments that you should only change one thing at a
time, trying to answer a single question with each change. Prothon started
out asking two questions:

* Does implementing an interpreter on top of the Apache Portable Runtime
for the sake of free threading work? (Presumably the answer is yes, since
Prothon does run. I haven't seen performance numbers on Prothon, though.)
* Is prototyping a workable replacement for a class-based object system?
Unclear, since I don't know that anyone has written sizable systems
in Prothon yet.

The problem is that if you then make a whole bunch of additional changes --
a 'with' statement, changing the rules for indenting, changing the names of
various built-in methods -- it becomes harder for Python users to try out
the new language for a while because there are more changes they have to
cope with. After a certain point the number of crossover users dwindles to
near-zero. None of these changes is critical or results in a 100%
improvement in functionality (or even a 10% one), but their collective
effect is to make the distance too great to cross conveniently; you might as
well start a new language with a blank sheet of paper at that point.

--amk
Jul 18 '05 #20

P: n/a
"Mark Hahn" <ma**@prothon.org> wrote in message news:<lS1ic.25535$dZ1.24380@fed1read04>...
I guess I'll go back to the Prothon mailing lists with my tail between my
legs....


Don't do that. It appears that this list is currently hosting even
more really grumpy people than usual. :P
Don't pay them any attention, maybe they'll go away.
Jul 18 '05 #21

P: n/a
On Thu, 22 Apr 2004 18:28:37 -0700, Erik Max Francis <ma*@alcyone.com>
wrote:
Mark Hahn wrote:
Well, I do tend to exaggerate a bit. I can understand it when I study
it,
but in everyday coding it does not roll off my fingers. Also, it is
possible to design something new without understanding the old.


It is _possible_. But it is not a very good idea.
I am serious when I say I think that Python has headed off into
egghead land
a bit and I feel that keeps a lot of people from switching to it. I
think
that this heady stuff scares them off. I really am trying to make
things
simpler in Prothon. Now, whether I can succeed or not is another
question.
Only time will tell.


Other than the basic premise of Prothon, every single decision I've seen
you make (or consider) looks wholly stylistic, awkward or even arcane,
and the opposite of the one I, or I think Guido, would have chosen.
Being a fan of Io, I think prototype-languages are interesting. Even so
far, I lost interest in looking at the actual main feature of Prothon,
after seeing all the extra baggage that was brought on in unecessary
stylistic changes.

Seriously considering every single possible proposal is not
constructive. Without a strong sense of what the language should look
like, Prothon is going to continue to look more and more like Perl.
It's already most of the way there.


Mark: """
Please hold off your ad hominem attacks until the product is
designed, thank you very much. """

I would take this as constructive criticism, not an ad-hominem attack.

-- Perl-like syntax:
Special symbols and capitalization to indicate variable scope,
closures, dynamic variables, etc.
local, Global, .x, ^x, X, &x, x, @x

Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.

-- Special syntax to indicate binding of functions. Python solves
this problem neatly, at the expense of some implicitness.
bound_func = cat1.func # cat1 is an instance
unbound_func = Cat.func # Cat is a class
Prothon's insistence on having not a trace of class-like behavior has
opened a can-of-worms. Iron out the wrinkles on one place and they
pop up in another.

== Benefits of Prothon ==

In spite of these criticisms I do believe Prothon has made a big
contribution in the *simplification* of classes. There are also some
smaller items worth looking at ( break tags, uniform syntax for
mutation!, boolean?, ... )

-- Dave

Jul 18 '05 #22

P: n/a

"A.M. Kuchling" <am*@amk.ca> wrote in message
news:Wq********************@speakeasy.net...
On Thu, 22 Apr 2004 18:28:37 -0700,
Erik Max Francis <ma*@alcyone.com> wrote:
Being a fan of Io, I think prototype-languages are interesting. Even so
far, I lost interest in looking at the actual main feature of Prothon,
after seeing all the extra baggage that was brought on in unecessary
stylistic changes.
There's a rule in experiments that you should only change one thing at a
time, trying to answer a single question with each change. Prothon started
out asking two questions:


Well, we didn't really start out to ask questions. We started out to design
a new language. We happened to like Python so we stole most of the syntax
from Python. Tim Peters and some other Pythoneers saw the existence of
Prothon as an opportunity to get some of these questions answered though for
Python.
* Does implementing an interpreter on top of the Apache Portable Runtime
for the sake of free threading work? (Presumably the answer is yes, since Prothon does run. I haven't seen performance numbers on Prothon, though.) * Is prototyping a workable replacement for a class-based object system?
Unclear, since I don't know that anyone has written sizable systems
in Prothon yet.

The problem is that if you then make a whole bunch of additional changes --
a 'with' statement,
This was required. Not having a class statement meant there was no way to
group the definition of functions and other attribute assignments together
when building a prototype or even a plain object. When playing with early
versions of the language it was unusable without the "with".
changing the rules for indenting
Actually no rules changed for indenting. Well, we added a rule that you
couldn't mix tabs and spaces within a single block, but that is not an
unreasonable requirement. We also added a new way to do continuations, but
that is optional.
changing the names of various built-in methods
The names are totally unchanged. We just changed the style to camelCase and
added ! and ? for readability. These are all mechanical changes and no
memorization is required.
it becomes harder for Python users to try out
the new language for a while because there are more changes they have to
cope with. After a certain point the number of crossover users dwindles to near-zero.
Yes, many people are afraid to try new things. That is a shame. Of course
if it was identical to Python many people still wouldn't try it.

I think everyone here is operating under fear, uncertainty, and doubt. Most
of the reports on the Prothon mailing list of people who have actually
picked up Prothon and played with it have been happy. People look at the
surface and are prejudiced, just like looking at people with different skin
color.

The best example is the current suggestion that self be changed to the
dollar-sign. Now anyone with any intelligence knows that changing the 4
letters "self" to the one symbol $ does nothing to change the language, but
several people here on c. l. p. claim that because you see dollar-signs
Prothon has now "become Perl". That is narrow-minded prejudice. What's
funny is that many people were happy with the current Prothon's use of
period for self but object to dollar-sign because now it looks like Perl.
Go figure.
None of these changes is critical or results in a 100%
improvement in functionality (or even a 10% one), but their collective
effect is to make the distance too great to cross conveniently; you might as well start a new language with a blank sheet of paper at that point.


Don't forget that we are not claiming to be Python. We intended from the
beginning to be a new language. We are using everything from Python that
isn't broken, and we get to define what is broken in Python :)

We are definitely fighting a battle to improve things while keeping the best
of Python. There is no way to make everyone happy. There have been people
who have come to our mailing list whose "suggestions" for Prothon were to
basicly keep Prothon exactly like Python and not change anything. There are
also people who claim that any change from the Self language means that it
is not a real Prototype-based language. And of course a smattering of
people who claim it must be like Lisp :)
Jul 18 '05 #23

P: n/a

"Mike C. Fletcher" <mc******@rogers.com> wrote ...
$ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.


Well I have a problem now. I gave people on my mailing list a choice
between $var, `var, ~var, and ^var. The current tally is four votes for
$var and none for any of the others. According to your criteria, $var is
the worst and ~var should be the best. Am I correct?
Jul 18 '05 #24

P: n/a
"David MacQuigg" <dm*@gain.com> wrote
I would take this as constructive criticism, not an ad-hominem attack.
Yes, I admitted I was mistaken. I was upset when I read the message and I
misread it as a slur.
Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.


The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3

Jul 18 '05 #25

P: n/a

"Peter Hansen" <pe***@engcorp.com> wrote ...
Mike, you haven't been keeping up with the other thread. I think the
decision is now:

fish_height$some_where()


That is like SO two-hours-ago. Marcia like, told me that Biff like, said
that Trish like, said camelCase was SO out, can you BELIEVE IT????
Jul 18 '05 #26

P: n/a
On Fri, Apr 23, 2004 at 10:55:55AM -0700, Mark Hahn wrote:
I think everyone here is operating under fear, uncertainty, and doubt. Most
of the reports on the Prothon mailing list of people who have actually
picked up Prothon and played with it have been happy. People look at the
surface and are prejudiced, just like looking at people with different skin
color.


Oh please, don't conflate irrational prejudice (racism) with rational
prejudice (it looks perl-ish, and I don't like the way perl looks, therefore
I don't like the way Prothon looks). Your accusation isn't up to the level
of that fellow spewing Totalitarian rhetoric about the "mental sickness" of
people who wrote/use python, but it isn't far off.

-jack
Jul 18 '05 #27

P: n/a
Mark Hahn wrote:
"Mike C. Fletcher" <mc******@rogers.com> wrote ...
$ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.


Well I have a problem now. I gave people on my mailing list a choice
between $var, `var, ~var, and ^var. The current tally is four votes for
$var and none for any of the others. According to your criteria, $var is
the worst and ~var should be the best. Am I correct?

Depends on the font ;) . Certainly $ is going to have the most
(negative) impact on readability, but the other three are all basically
lightweight enough that they don't read as characters (basically any
glyph that fills the same space as a lower-case o is going to markedly
change the shape of a word. ` is the least likely to be read as a
character, but is really hard to distinguish from ', so likely not a
great choice. ^ doesn't occupy the middle space, so doesn't get read as
a character either. ~ doesn't read as one either because it doesn't
touch the baseline.

$, however, is going to be familiar to your PERL aficionados, and
familiarity counts a lot for those who are familiar with it, regardless
of whether it's technically easier to read. The other three are
basically just arbitrary punctuation, so people don't have any
associations built up with them (they don't look at them and
automatically think "attribute access"). The dot character does have
lots of attribute-access associations; hence a leading dot (which
doesn't read as a character) will tend to test favourably on both scales
(practical and familiar).

Have fun,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #28

P: n/a

"Jack Diederich" <ja**@performancedrivers.com> wrote in message
Oh please, don't conflate irrational prejudice (racism) with rational
prejudice (it looks perl-ish, and I don't like the way perl looks, therefore I don't like the way Prothon looks). Your accusation isn't up to the level of that fellow spewing Totalitarian rhetoric about the "mental sickness" of people who wrote/use python, but it isn't far off.


I apologize to anyone that I offended by thinking that I related the
problems of racism to language discussion. I realize now that the analogy
was poorly chosen, even if based on something. I just meant that people
"pre-judge" Prothon based on it's looks.
Jul 18 '05 #29

P: n/a

"Mark Hahn" <ma**@prothon.org> wrote in message
news:Pedic.28731$dZ1.11479@fed1read04...

"Peter Hansen" <pe***@engcorp.com> wrote ...
Mike, you haven't been keeping up with the other thread. I think the
decision is now:

fish_height$some_where()


That is like SO two-hours-ago. Marcia like, told me that Biff like, said
that Trish like, said camelCase was SO out, can you BELIEVE IT????


Peter: You were making fun of how of fast I'm changing things in Prothon,
right? I was going along with that humour in my message. Someone in a
private message accused me of making fun of you, which I was definitely not
doing.

Boy, I better shut up. I'm just getting myself in deeper and deeper trouble
every message I post today.
Jul 18 '05 #30

P: n/a
On Fri, 23 Apr 2004 11:21:16 -0700, "Mark Hahn" <ma**@prothon.org>
wrote:
"David MacQuigg" <dm*@gain.com> wrote
Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.
The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):


Sorry for my ignorance, oh master. :>)
# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3


Here is how I would do it in Python:

class Accumulator:
def __init__(self):
self.count = 0
def bump(self):
self.count += 1
print self.count

c = Accumulator()
c.bump()
c.bump()
c.bump()

It took me a few minutes to understand what the "closure" was doing.
The Python code is more clear ( at least for anyone who will have to
be working with classes anyway). There is nothing new to learn.

Functionality = same
Size of Source Code = same
Transparency = Python wins

-- Dave

P.S. A sincere apology for my gibe above. I couldn't resist. :>)
Jul 18 '05 #31

P: n/a
Mark Hahn wrote:
(by the way, Python cannot do this)
sure can, if you use mutable integers.
# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count


</F>


Jul 18 '05 #32

P: n/a
Mark Hahn wrote:
....
Peter: You were making fun of how of fast I'm changing things in Prothon,
right? I was going along with that humour in my message. Someone in a
private message accused me of making fun of you, which I was definitely not
doing.

Ah, too bad, you might have fit in if you did ;) . He's just *so* much
fun to poke fun at. For crimminy's sake, he's from Canada, and you know
how ridiculous they all are... blubber-eating igloo-wardens every last
one of them. It's practically impossible to take one of them seriously
as a computer programmer, I mean, really, a modern computer would just
melt the igloo down around their heads.

*poof*

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #33

P: n/a

"Fredrik Lundh" <fr*****@pythonware.com> wrote ...
(by the way, Python cannot do this)


sure can, if you use mutable integers.


That's interesting. I've never heard of them. Can you show me a code
example?
Jul 18 '05 #34

P: n/a
In article <w8dic.28710$dZ1.11206@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:
The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3

It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()
Regards. Mel.
Jul 18 '05 #35

P: n/a
In article <ma**************************************@python.o rg>,
"Mike C. Fletcher" <mc******@rogers.com> wrote:
Mark Hahn wrote:
My inability to understand this stuff is what drove me to do Prothon <grin>.
All the hidden wrapped this and wrapped that confused me to no end.
Fascinating. Most users never even notice this stuff, let alone getting
so worked up about it that they start a whole separate language ;) .
After all, they don't generally even know that metaclasses *exist* and
just know that it all works exactly as they would expect. You for
instance, were describing how the interpreter just knows that a class
can't be the target of an unbound class method. Sure, *maybe* it's all
a hideously complex mess that has people running screaming from Python
in horror, but from where I sit it is an extremely elegant system that
most people use without any impedance mismatch at all.


I perhaps encountered this..

connection = serial.Serial ( ... )
# connection is a file-like object,
# having the usual `write` method

engine = MyFiniteStateMachine ()
# engine happens to have a `writer` method that
# funnels out the machines products
# The default is effectively `def writer (self, s): print s`

engine.writer = connection.write
# we channel engine's output through the serial connection

Plugged together, it just works, as Mike says. No
trouble when engine's internal calls to `self.writer` end up
accessing a completely different object's method. It's only
lately that I've stopped to gawp at it, and wonder.

Regards. Mel.
Jul 18 '05 #36

P: n/a
Mark Hahn wrote:
"Fredrik Lundh" <fr*****@pythonware.com> wrote ...
(by the way, Python cannot do this)


sure can, if you use mutable integers.


That's interesting. I've never heard of them. Can you show me a code
example?


Make a container. Put an integer in it. Pass the container around.
Change the integer that's contained in it.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I'm paranoid. But am I paranoid enough?
-- Louis Wu
Jul 18 '05 #37

P: n/a
In article <ma**************************************@python.o rg>,
"Mike C. Fletcher" <mc******@rogers.com> wrote:
Mark Hahn wrote:
"Mike C. Fletcher" <mc******@rogers.com> wrote ...
$ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.


Well I have a problem now. I gave people on my mailing list a choice
between $var, `var, ~var, and ^var. The current tally is four votes for
$var and none for any of the others. According to your criteria, $var is
the worst and ~var should be the best. Am I correct?

Depends on the font ;) . Certainly $ is going to have the most
(negative) impact on readability, but the other three are all basically
lightweight enough that they don't read as characters (basically any
glyph that fills the same space as a lower-case o is going to markedly
change the shape of a word. ` is the least likely to be read as a
character, but is really hard to distinguish from ', so likely not a
great choice. ^ doesn't occupy the middle space, so doesn't get read as
a character either. ~ doesn't read as one either because it doesn't
touch the baseline.

$, however, is going to be familiar to your PERL aficionados, and
familiarity counts a lot for those who are familiar with it, regardless
of whether it's technically easier to read. The other three are
basically just arbitrary punctuation, so people don't have any
associations built up with them (they don't look at them and
automatically think "attribute access"). The dot character does have
lots of attribute-access associations; hence a leading dot (which
doesn't read as a character) will tend to test favourably on both scales
(practical and familiar).


Hm, I do have some associations with the other three, and
also with $ in an infix position. Maybe I have more junk
than usual in my mental closet, but we are supposed to
venerate the aged so I will report without embarrassment
that I remember VMS library functions like RMS$PARSE etc.
This basically goes along with the argument above - it's
a single identifier, $ is not punctuation. VMS is still
around, too.

The C use of ~ (bitwise negation operator) and ^ (bitwise
xor) should be a problem, but otherwise I guess ~ seems
like a character to me too. In an infix position. hi~ho
vs. hi_ho, same look to me. They are also operators in
the Plan 9 rc shell, incidentally - glob match and distributive
concatenation, respectively.

Any of the four would be an unhappy choice, in my view.
Maybe there's some way to use :

Donn Cave, do**@u.washington.edu
Jul 18 '05 #38

P: n/a

"David MacQuigg" <dm*@gain.com> wrote ...
The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Pythoncannot do this):
Sorry for my ignorance, oh master. :>)


That's ok grasshopper :)
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

Here is how I would do it in Python:

class Accumulator:
def __init__(self):
self.count = 0
def bump(self):
self.count += 1
print self.count It took me a few minutes to understand what the "closure" was doing.
The Python code is more clear ( at least for anyone who will have to
be working with classes anyway). There is nothing new to learn.

Functionality = same
Size of Source Code = same
Transparency = Python wins
Yes, it's a tie in this example. There are many cases however where you are
already in a situation where you have a function and the closure is
beneficial and creating a "class" would be unneeded overhead. I don't
really have the time to create something large enough here to demonstrate
it. You'll just have to take my word for it (or not).

It's a tool for your toolchest and it's the kind of thing that if your not
familiar with it you'll never miss it, but once you learn it and use it a
few times you'll wonder how you ever lived without it. Also I can drag out
the old tired argument that if the closure bothers you "you don't have to
use it".
P.S. A sincere apology for my gibe above. I couldn't resist. :>)


I'm sure I deserve it.

Jul 18 '05 #39

P: n/a

"Mel Wilson" <mw*****@the-wire.com> wrote in message
news:ulXiAls/KH*******@the-wire.com...
It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()


True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them seperate.
Jul 18 '05 #40

P: n/a
Mark Hahn wrote:
"Mark Hahn" <ma**@prothon.org> wrote in message
news:Pedic.28731$dZ1.11479@fed1read04...
"Peter Hansen" <pe***@engcorp.com> wrote ...
Mike, you haven't been keeping up with the other thread. I think the
decision is now:

fish_height$some_where()


That is like SO two-hours-ago. Marcia like, told me that Biff like, said
that Trish like, said camelCase was SO out, can you BELIEVE IT????


Peter: You were making fun of how of fast I'm changing things in Prothon,
right? I was going along with that humour in my message. Someone in a
private message accused me of making fun of you, which I was definitely not
doing.


No offense taken, nor thought to be intended. (Best to include
a smiley next time, however, just in case. I think the newsgroup
needs more of those right now. I think it's those damn crows outside
my window that are getting everyone on edge. You can hear them,
right? They're very loud... where's a kid with a BB gun when you
need him?)

-Peter
Jul 18 '05 #41

P: n/a
Mike C. Fletcher wrote:
Mark Hahn wrote:
...
Peter: You were making fun of how of fast I'm changing things in Prothon,
right? I was going along with that humour in my message. Someone in a
private message accused me of making fun of you, which I was
definitely not doing.

Ah, too bad, you might have fit in if you did ;) . He's just *so* much
fun to poke fun at. For crimminy's sake, he's from Canada, and you know
how ridiculous they all are... blubber-eating igloo-wardens every last
one of them. It's practically impossible to take one of them seriously
as a computer programmer, I mean, really, a modern computer would just
melt the igloo down around their heads.


See you downtown at the PyGTA meeting on Tuesday, Mike. And remember
your snowshoes this time, for heaven's sake. It's still *April*, for
cryin' out loud!

-Peter
Jul 18 '05 #42

P: n/a
Mark Hahn wrote:
"Mike C. Fletcher" <mc******@rogers.com> wrote ...

$ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.

Well I have a problem now. I gave people on my mailing list a choice
between $var, `var, ~var, and ^var. The current tally is four votes for
$var and none for any of the others. According to your criteria, $var is
the worst and ~var should be the best. Am I correct?


If I recall correctly, ObjectRexx uses ~ the way Python uses . (dot).
I wasn't really partial to it, but it didn't really stand in the way
of writing or reading the code.

I have to go with Mike on the problem with $ however...
Jul 18 '05 #43

P: n/a

"Mel Wilson" <mw*****@the-wire.com> wrote ...
connection = serial.Serial ( ... )
# connection is a file-like object,
# having the usual `write` method

engine = MyFiniteStateMachine ()
# engine happens to have a `writer` method that
# funnels out the machines products
# The default is effectively `def writer (self, s): print s`

engine.writer = connection.write
# we channel engine's output through the serial connection

Plugged together, it just works, as Mike says. No
trouble when engine's internal calls to `self.writer` end up
accessing a completely different object's method. It's only
lately that I've stopped to gawp at it, and wonder.


That is a powerful testimonial to the "walks like a duck" principal which
has nothing to do with classes or prototypes. Thankfully that works in a
simple classless language like the current Prothon.
Jul 18 '05 #44

P: n/a
On Fri, Apr 23, 2004 at 01:01:10PM -0700, David MacQuigg wrote:
On Fri, 23 Apr 2004 11:21:16 -0700, "Mark Hahn" <ma**@prothon.org>
wrote:
"David MacQuigg" <dm*@gain.com> wrote
Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.


The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):


Sorry for my ignorance, oh master. :>)
# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3


Here is how I would do it in Python:

class Accumulator:
def __init__(self):
self.count = 0
def bump(self):
self.count += 1
print self.count

c = Accumulator()
c.bump()
c.bump()
c.bump()


A more word-for-word translation of the Prothon would be
def countup():
count = [0]
def f():
count[0] += 1
print count[0]
return f

c = countup()
c()
c()
c()

But yeah, using an object as an accumulator is more
transparent.

-jackdied

Jul 18 '05 #45

P: n/a

"Peter Hansen" <pe***@engcorp.com> wrote ...
I have to go with Mike on the problem with $ however...


I think he makes sense also, which means my democracy is in trouble. I put
it out for a vote and everyone is voting for $. I should have figured this
would happen. More people use Perl than Python also :) (Just kidding -- no
flames please -- just kidding).
Jul 18 '05 #46

P: n/a
On Fri, 23 Apr 2004 13:40:55 -0700, "Mark Hahn" <ma**@prothon.org>
wrote:
"David MacQuigg" <dm*@gain.com> wrote ...
>def getFunc():
> counter = 0
> def count():
> &counter += 1
> print &counter
> return count

Here is how I would do it in Python:

class Accumulator:
def __init__(self):
self.count = 0
def bump(self):
self.count += 1
print self.count

It took me a few minutes to understand what the "closure" was doing.
The Python code is more clear ( at least for anyone who will have to
be working with classes anyway). There is nothing new to learn.

Functionality = same
Size of Source Code = same
Transparency = Python wins


Yes, it's a tie in this example. There are many cases however where you are
already in a situation where you have a function and the closure is
beneficial and creating a "class" would be unneeded overhead. I don't
really have the time to create something large enough here to demonstrate
it. You'll just have to take my word for it (or not).

It's a tool for your toolchest and it's the kind of thing that if your not
familiar with it you'll never miss it, but once you learn it and use it a
few times you'll wonder how you ever lived without it. Also I can drag out
the old tired argument that if the closure bothers you "you don't have to
use it".


I appreciate that I may be missing something important because it can
only be seen in a larger example. For many years I scoffed at C++
thinking I could do anything I needed without OOP.

Still, the question of whether we should include special syntax for
closures is an important question that deserves some time on a
use-case before even putting it into Prothon, let alone expecting
Python users to learn it.

I'm not seeing the "overhead" of classes that you refer to. To me, a
class is very lightweight thing. I use nested classes, for example to
store hierarchies of variables, like
window1.plot2.xaxis.label.font.size = 12

It is quite alright to show a small example and expect us to
extrapolate to something 100 times larger. Even if we extrapolate the
example above, however, Python still wins.

I don't like the "toolchest -- don't have to use it" argument, because
that could be used to justify *any* added syntax, and I really like
the compactness of Python. The more overlapping features we have, the
more confusion there will be in reading someone else's programs, for
example.

I don't like the "once I learn it argument" either. An equally valid
argument is that people who have developed a *habit* in other
languages of using closures, are now unnecessarily dependent on them,
and will have to learn simpler techiques to get by in Python.

By the way, if we work on the example a little, Python wins on
transparency *and* codesize.

class A:
count = 0
def bump(self):
A.count += 1
print A.count

c = A().bump
c(); c(); c()

-- Dave

Jul 18 '05 #47

P: n/a
In article <lkfic.29767$dZ1.17301@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:
"Mel Wilson" <mw*****@the-wire.com> wrote in message
news:ulXiAls/KH*******@the-wire.com...
It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()


True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them sep~rate.


I don't think a closure variable prefix sounds very good.

What you're doing there looks to me a bit like Objective
CAML's ref type. "a = ref 0" is a mutable container for an
immutable integer. It's just syntactic sugar for a mutable
record; the sugar is the assignment a := 1, and then there's
some special dereference notation -- a := !a + 1, something
like that, I forget.

There could be a case for a mutable-container-of-one-item
type in Python, with or without special syntax. Without
the syntax, it's still mildly interesting because it expresses
intent - both to the human reader, and to other software
components which should not be invited to delete or add
items etc.

class Ref:
def __init__(self, a):
self.value = a
def __setattr__(self, a, v):
if a == 'value':
self.__dict__['value'] = v
else:
raise AttributeError, a

var = Ref(0)

var.value = var.value + 1
I personally think syntactic sugar wouldn't add any real
value to that, but that just seems to be one of those
matters of taste, where some people like languages like
Pe... oops.

Donn Cave, do**@u.washingtno.edu
Jul 18 '05 #48

P: n/a

"Donn Cave" <do**@u.washington.edu> wrote ...
What you're doing there looks to me a bit like Objective
CAML's ref type. "a = ref 0" is a mutable container for an
immutable integer. It's just syntactic sugar for a mutable
record; the sugar is the assignment a := 1, and then there's
some special dereference notation -- a := !a + 1, something
like that, I forget.


I'm not doing anything nearly that complex. &var just gives access to the
outer closure scope and directly accesses var in that scope, just like
accessing a global variable. It isn't just syntax sugar for var[0] because
it has none of the list overhead associated with the var[0] kludge. & just
tells the compiler where to find the variable, just like capitalized
variables in Prothon say to find them in the global space and .var says to
find var in self.

The whole point is to make things simpler, more readable, and more
efficient, but when people see the & symbol they somehow automatically think
it's complex. Maybe my mind doesn't work like everyone else's.
Jul 18 '05 #49

P: n/a
On Fri, 23 Apr 2004 13:50:24 -0700, "Mark Hahn" <ma**@prothon.org>
wrote:
"Mel Wilson" <mw*****@the-wire.com> wrote in message
news:ulXiAls/KH*******@the-wire.com...
It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()


True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them seperate.


We need to see what the problem is before we can judge a solution.
Just showing a code snippet and saying "do this" is not a good
statement of the problem. As you have seen, there are simple elegant
solutions that don't follow your code line-for-line, and there are
inelegant solutions that are very close. Both categories seem to
solve what we think the problem is, but you may have another problem
in mind. A use-case would be helpful.

As an alternative, we could work with a clear statement of the
problem, something like: The proposed syntax will allow assigning
values to (not just referencing) variables in a scope surrounding a
nested function. This will be useful when the existing alternatives
are not appropriate:
1) Attach the variable to an instance.
2) Make the variable global.
3) Add the variable to the function argument list.
4) ...

I've probably mistated it, but you see what I'm getting at, something
that de-couples the user-level problem from the particular mechanisms
of the language. Trying to reproduce these mechanisms in Python will
be the road to Per ... dition. :>)

-- Dave

Jul 18 '05 #50

90 Replies

This discussion thread is closed

Replies have been disabled for this discussion.