Re: quantum instance

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
>You could read up on __getattr__, __getattribute__, and
> >friends in the Language References section 3.3.2:
> Customizing attribute access

"and friends" include descriptors, so that the discussion
about properties here had actually led me into some better  
understanding of this realm of Python.

It ties together a bit, in that in reviewing my own code
and my own use of properties I see I did use it mostly
in comformity with the example outlined in Guido's article
on new style classes, and to solve a problem not
unrelated to the one I am trying to solve by a
"blended class".

Specifically, vpython will try to draw anything you send
to it, but if you send it a vector outside of some range
relative to the current zoom level, the display fritzes.
So in retrieving a vector (which I consider an attribute)
for purposes of rendering, I was setting a constraint
that would be sufficient to avoid the fritz, while keeping
the actual values of the vector pure, for the purposes of
further calculation. IOW I am managing the retrievel
of data from an attribute.

Another friend of __getattr__ is __slots__.  I was
confused by slots as well early on, as I think were many
others.  I satsified myself - if no one else - that my
confusion was in part generated by a general
confusion,  including some confusion in the What's New in
Python2.X (when __slots__ first appeared).

It is not too surprising that there can be some degree of
misinprepation of Guido's intention in adding a feature
to the language.  

The problem is exasperated when an example of the
mechanical use of something like properties is
presented - and confused (by folks at my level
,at least) as an actual use case of the feature.
I do think this happened with getters and setters
and properties, and think there may be some pedagogical
lesson in this somewhere.

Extending the point - one reason that I think Java
cannot work well (or as well) as an introductory language
is that it forces one to mechanically understand
attribute access modification (and such like) well
before one can be expected to understand in any
authentic manner the use cases.

The result is seditious and wide ranging, because we then
settle on an approach where expectations as to
authenticity are generally lowered.

Much preferable to understand the feature, its mechanics,
and its use case as one process.  

I get there my not concerning myself about features
I don't need, until I think I need them.  
And then determine whether it actually solves
my problem.  If I manage the mechanics, and it solves
my problem - I have my use case.

But of course I have a context - my interests.  

I think teaching programming outside a context - as an abstract
discipline - is unavoidably problematic in this regard.

Web and network programming, scientific programming, algorithomics, business programming,
graphics and entertainment programming ... all provide a context
and a context implies use cases.

I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach.

But I guess that postion runs counter to enough
established realities as to be essentially
meaningless.

My specialty.

I do think Python lends itself well to a pedagogoical approach  that gives context - whatever it might be -
due weight.

Which is what brings me here , at least indirectly.

And why I am committed to annoy everyone until
everyone sees everything my way.

;)



Art






_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Scott David Daniels
[hidden email] wrote:
>...
> I think teaching programming outside a context - as an abstract
> discipline - is unavoidably problematic in this regard.
I would have more sympathy if you would subscribe to the same philosophy
for "geometry" and "mathematics."  As someone who has concentrated on
computer science and "The Art of Computer Programming" for a huge number
of years, I am offended at the denigration of my field of study (or at
least what I perceive to be a denigration).

> I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach.
Why is this different from saying, "I am not convinced 'mathematics' as
a stand-alone subject cannot be optimum as an approach?"  "Only in the
context of physics or engineering or ...."

Please distinguish from the teaching of the computer science and/or
programming that _you_ want to learn from that that _anyone_ might
want to learn.

> And why I am committed to annoy everyone until
> everyone sees everything my way.
Well, you certainly accomplished the "annoy" part today.  Perhaps I
am just in a cranky mood.

--Scott David Daniels
[hidden email]

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
Scott David Daniels wrote:

>[hidden email] wrote:
>  
>
>>...
>>I think teaching programming outside a context - as an abstract
>>discipline - is unavoidably problematic in this regard.
>>    
>>
>I would have more sympathy if you would subscribe to the same philosophy
>for "geometry" and "mathematics."  As someone who has concentrated on
>computer science and "The Art of Computer Programming" for a huge number
>of years, I am offended at the denigration of my field of study (or at
>least what I perceive to be a denigration).
>  
>
And I would have more sympathy if you were willing to deal  separattely
and distinctly with computer science, as science and the "Art of
Computer Programming" as an art.  I personally have very little interest
in (but great respect for) the former, and a  good deal of personal
interest in the latter. Maybe its harder for those who started by
writing machine code  to make the distinction than it is for those of us
who only came to the party when and becuase high level languages were
developed.

It is indeed stimulating and challenging to attempt to communicate with
a complex machine, and do so  with elegance.

But I don't find it difficult at all to maintain that the pursuit is
different in nature from the study of mathematics and geometry.  Some
wold argue that mathematics and geometry are there whether we as a race
are or are not.  Certainly though they are there whether my machine
powers up or does not.

>>I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach.
>>    
>>
>Why is this different from saying, "I am not convinced 'mathematics' as
>a stand-alone subject cannot be optimum as an approach?"  "Only in the
>context of physics or engineering or ...."
>  
>
I believe computer science is a stand alone subject, and that
programming is natural in the context of a computer science
curriculum..  But I do that think someone like yourself is in fact
actually studying programming in a particular context.  Maybe its most
general context . But a quite specific context nonetheless.

>Please distinguish from the teaching of the computer science and/or
>programming that _you_ want to learn from that that _anyone_ might
>want to learn.
>
>  
>
>>And why I am committed to annoy everyone until
>>everyone sees everything my way.
>>    
>>
>Well, you certainly accomplished the "annoy" part today.  Perhaps I
>am just in a cranky mood.
>  
>
Perhaps an attempt to liberate programming from the control of computer
scientists is bound to annoy a computer scientist, a bit. ;)

Art

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Kirby Urner
In reply to this post by Scott David Daniels

I pretty much agree with Arthur that CS needs grist for its mill, and
geometry and mathematics are good suppliers.  

I would also turn that around and go with Scott's point that CS is not alone
in needing grist:  geometry and mathematics benefit by having CS supply
context and applications.

For example, a purist mathematician might scorn an approach to the concept
of vectors that uses Python code as a means to communicate just what a
vector *is* i.e. uses a computer language to help anchor a mathematical
generality.  

However, not being a purist, I think such cross-breeding begets many
positive synergies.  We get to use string substitution to generate scene
description language, directly from our Python vector class, as food for
POV-ray.[1]

Python and POV-ray are wonderful and powerful tools.  It hardly makes sense
to teach mathematics/geometry without these tools, or tools like them, if
the requisite tech is available.  They're free, after all.

In sum, it makes plenty of sense to teach CS while importing from other
fields (I'd argue that Knuth makes extensive use of pre-CS mathematics), and
it makes just as much sense teach math and geometry while importing from CS.

The advantages of a cultivating a math/CS hybrid for use in present and
future curricula are just too great to ignore.  Why rip ourselves off
unnecessarily?  We should continue this lineage, which is already a
tradition, stretching back to before Python was born.

Kirby

Related thread @ Math Forum (math-teach list):
http://mathforum.org/kb/message.jspa?messageID=3934957&tstart=0

[1]

 >>> reload(satacad)
 <module 'satacad' from 'D:\Python24\lib\site-packages\satacad.py'>
 >>> from satacad import Vector, Edge
 >>> v0 = Vector((1,1,1))
 >>> v1 = Vector((1,2,-3))
 >>> v2 = v0 + v1
 >>> e = Edge(v2,v0)
 >>> e
 Edge <2, 3, -2>, <1, 1, 1>
 >>> e.write()
 'cylinder <2, 3, -2>, <1, 1, 1>, 0.1 pigment { color Red }'
 >>> v0
 Vector <1, 1, 1>
 >>> v2*3
 Vector <6, 9, -6>

class Vector(object):

    color = 'Red'
   
    def __init__(self, xyz):
        self.xyz = xyz

    def write(self):
        basic = "cylinder <0,0,0>, <%s,%s,%s>, 0.1" % self.xyz
        return "%s %s" % (basic, "pigment { color %s }" % self.color)
   
    def __repr__(self):
        return "Vector <%s, %s, %s>" % self.xyz
           
    def __mul__(self, scalar):
        xyz = tuple([scalar * i for i in self.xyz])
        return Vector(xyz)

    def __add__(self, other):
        xyz = tuple([ i+j for i,j in zip(self.xyz, other.xyz)])
        return Vector(xyz)

    def _get_xyz(self):
        return '<%s, %s, %s>' % self.xyz
 
    coords = property(_get_xyz)
   

class Edge(object):

    color = 'Red'

    def __init__(self, v0, v1):
        self.v0 = v0
        self.v1 = v1

    def __repr__(self):
        return "Edge %s, %s" % (self.v0.coords, self.v1.coords)

    def write(self):
        basic = "cylinder %s, %s, 0.1" % (self.v0.coords, self.v1.coords)
        return "%s %s" % (basic, "pigment { color %s }" % self.color)

   


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Scott David Daniels
In reply to this post by Arthur-27
Arthur wrote:

> Scott David Daniels wrote:
>
>>[hidden email] wrote:
>>>I think teaching programming outside a context - as an abstract
>>>discipline - is unavoidably problematic in this regard.
>>
>>I would have more sympathy if you would subscribe to the same philosophy
>>for "geometry" and "mathematics."  As someone who has concentrated on
>>computer science and "The Art of Computer Programming" for a huge number
>>of years, I am offended at the denigration of my field of study (or at
>>least what I perceive to be a denigration).
OK, here I may have been unclear.  TAoCP is a set of books I love, but I
was, in fact, referring to the art of computer programming, and engaging
in a bit of a pun.  It seems to have helped confuse the issue.  I also
understand most of the best programmers I know are not computer
scientists, though many of them read in it from time to time.

> And I would have more sympathy if you were willing to deal  separattely
> and distinctly with computer science, as science and the "Art of
> Computer Programming" as an art.  
OK, we are getting to a nub here, but we are also moving to my personal
biases rather than that of the field itself.  I went to the Univ. of
Penn., where Mathematics was definitely classified an Art; even Applied
Math.  I view computer programming as an Art, not engineering nor a
science.  The art is in the clear expression of a solution to a problem.
Much of what you need to know to develop that art involves things like
brushwork -- technical skills at which you must become proficient in
order to work (the _craft_ part of computer programming), but the art
lies not only in a perfected craft, but an ability to see a problem and
find a solution that seems obvious once found.  But, to confuse the
issue a bit, I also find Mathematics and Computer Science equally arts.

> I personally have very little interest in (but great respect for)
 > the former [Computer Science], and a  good deal of personal
> interest in the latter [Computer Programming].  Maybe its harder for
 > those who started by  writing machine code to make the distinction
> than it is for those of us who only came to the party when and because
 > high level languages were developed.

> It is indeed stimulating and challenging to attempt to communicate with
> a complex machine, and do so  with elegance.
Ah -- is that what computer science is to you, or is it programming?
In my view the communication is with the reader of the program (who
may be reading for the joy, but more likely is reading in order to
alter).

> But I don't find it difficult at all to maintain that the pursuit is
> different in nature from the study of mathematics and geometry.  Some
> would argue that mathematics and geometry are there whether we as a
> race are or are not.  Certainly though they are there whether my machine
> powers up or does not.
>
>>>I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach.
Could you restate this?  I presume (but am unsure) this means:
    I believe teaching "programming" without computer science is optimal.

> I believe computer science is a stand alone subject, and that
> programming is natural in the context of a computer science
> curriculum.

> But I do that think someone like yourself is in fact  actually
> studying programming in a particular context.  Maybe its most
> general context. But a quite specific context nonetheless.
Hmmm.  I think you know me less than you think you do.  I think a
core computer science question is how efficiently some values can
_ever_ be calculated, based on as few assumptions as we can get
away with making about the nature of the machines (and languages)
doing the computation.  These kinds of results should inform how
you (or even whether you attempt to) build programs to solve these
problems.

> Perhaps an attempt to liberate programming from the control of computer
> scientists is bound to annoy a computer scientist, a bit. ;)
I suppose you might call me a computer scientist, but if so I am an
amateur computer scientist; my CS is from the love of the ideas, not
from a compensated position.  My pay has come, almost exclusively,
from being a programmer.

I would say that writing computer programs without an understanding of
computer science is certainly possible (and I've worked with lots of
people who do so), but to write well, and to write are not the same
skill at all.

--Scott David Daniels
[hidden email]

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
Scott David Daniels wrote:

>Arthur wrote:
>
>>    
>>
>>>>I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach.
>>>>        
>>>>
>Could you restate this?  
>  
>
""""
The art is in the clear expression of a solution to a problem..
"""
and

"""
but the art lies not only in a perfected craft, but an ability to see a problem and find a solution that seems obvious once found.

""""

What problem?

What context for problems?

How to we avoid "learning to program" as a game of make beleive,
attacking self- referential problems that have already been solved.

How do we break the cycle of the best programmers solving the problem of
making the best IDE that can be used by the  best programmers -  to make
better IDEs?

Art
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
In reply to this post by Scott David Daniels
Scott David Daniels wrote:

>I would say that writing computer programs without an understanding of
>computer science is certainly possible (and I've worked with lots of
>people who do so), but to write well, and to write are not the same
>skill at all.
>
Let me sign on to your point of view.  I am writing for other human beings.

But which other human beings?

A little ditty I had written here was judged harshly (and incorrectly, I
believe), because it  spoke in a vocabulary of finance  - to programmers.

Can someone whose first identity is as a programmer judge the writing of
someone whose is not.

Back to where I started to get testy:

properties and decorators

I honestly believe that if I had seen them in my first Python Triangle
class I would have judged myself to be looking at a language that might
be swell - for somebody else.  But a little too magical,
self-referential and self-involved - for my own taste.  And would have
moved on.

Which might have saved the Python community from the annoyances of one
annoying guy.

But I can imagine someone with my sensibilities - just a lot less
annoying - having moved on, and  think that would have been a shame.

Is that really how we do a Triangle in Python today?

Can we accept the less sophisticated appraoches on equal footing?

Art









_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Scott David Daniels
Arthur wrote:
> Back to where I started to get testy:
>
> properties and decorators
>
> I honestly believe that if I had seen them in my first Python Triangle
> class I would have judged myself to be looking at a language that might
> be swell - for somebody else.  But a little too magical,
> self-referential and self-involved - for my own taste.  And would have
> moved on.

I understand that properties and decorators look like obscure magic.
I ask you to suspend judgment on those (an act of faith), until you
understand why such features seriously assist the readability of code
and designs.  This act of faith can be based on a respect for the
obvious effort somebody has gone to in other ways to make Python such
a clear and simple language.

I don't object to your not wanting to use such constructs, but rather
to your desire to remove them from the language (or veto adding them)
in order to make it "simpler."  I'm sure others have said as much about
the ridiculous idea of making a value for the square root of minus one,
or for the incomprehensibly strained "line at infinity."

When you ask what these features provide, I try to explain how they make
it possible to write some very clear simple code.  I think Kirby will
attest to the fact that decorators seriously improved the readability
of his "hypertoons" code.  Decorators should be used sparingly, if at
all.  That is not to say they shouldn't exist.  The key to understanding
when decorators are useful can be summarized as "whenever you feel
you are writing boilerplate your skin should itch."  This doesn't mean
that you should not write boilerplate on occasion, but rather that you
should be searching for a way around it.

I tried to explain to you why I found properties such a useful addition.
Their existence allows me to write code without the "protective
generality" of always writing accessors and mutators in case, some two
years hence, I need to change more than the single attribute on a
mutation, or decide some value that I have been storing is much better
left calculated.  This was unconvincing to you, but you responded
more in the vein of "nobody should be allowed to use this, so the code
I read is simpler."  I am surprised you accept exceptions (a relatively
recent development in the design of computer languages).

The rule I use in commenting code is that you should not comment use of
features of a language in code written in that language.  Programmers
who read code written in Python are responsible for learning Python, and
there is no excuse for code like:
     a = range(12)  # Make a list of integers between 0 and 11 inclusive
The comment slows down your reading of the code and distracts you from
reading the application itself.  The language is the given.  When you
choose a language, you buy its tradeoffs.  If you cannot stand
descriptors, insist on python 2.3.  When you ask what something is good
for, and get given an explanation that turns out to not make your life
simpler, don't presume that the examples given are therefore useless.
You have not spent a career writing code that must be rewritten
constantly (to accommodate changing requirements); properties help in
that task, in part because you can avoid using them until necessary,
with their existence in your back pocket.

 > Can we accept the less sophisticated approaches on equal footing?

We can accept the less sophisticated approach to designing programs
as workable.  Do you seriously think that when designing a language
equal weight should be given to those that understand the implications
of a decision and those who "go with their gut?"  It is one thing to
make ivory tower decisions, and another to know the impact a decision
might have.


--Scott David Daniels
[hidden email]

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
Scott David Daniels wrote:

>I understand that properties and decorators look like obscure magic.
>I ask you to suspend judgment on those (an act of faith), until you
>understand why such features seriously assist the readability of code
>and designs.  This act of faith can be based on a respect for the
>obvious effort somebody has gone to in other ways to make Python such
>a clear and simple language.
>  
>
No faith.  If that were me I'd be writing  "protected" before my methods
knowing there was a damn good reason for it. That I was practicing good
objected oriented design.  And that I was solving a problem I just
didn't happen to know I had, but most assuredly did.

If language design decisions were not all about trade-offs, language
design would be easy.  It would be as silly for me to suggest that
properties and decorators do not bring advantages as it would be for you
to suggest that those advantages come for free.

My argument though is with you, not Guido.  It is about use cases for
existing features, not about the features themselves.  And in the
particular case of properties, it was only in going back to Guido's own
use case illustration that I begin to develop some comfort with why
properties are there - why they are a neat solution to a limited set of
problems.  I understand them now more in  terms  of  something akin to  
a GUI event, or a SQL trigger.  You  have a need  to know  when  
something  attempts to set or  get  a particular attribute. The relation
to the actual attribute might be tenous.  It's an event.  It might begin
a process that sends an e-mail to Mary. Who knows what. Its all quite
practical and tangible stuff, though.

It has nothing yet, in my mind, to do with decoupling anything from
anything else as a matter of good OOP design.

And to the extent you feel properties are well used in that regard, than
you are developing your own use cases which may or may not be similar to
Guido's ideas and implicit in the design of the language. And I guess I
am suggesting you are suggesting too much by suggesting otherwise.


Art


Am I making any sense whatever?

Art


 But I still don't see the connection to XP programming, API design



>I don't object to your not wanting to use such constructs, but rather
>to your desire to remove them from the language (or veto adding them)
>in order to make it "simpler."  I'm sure others have said as much about
>the ridiculous idea of making a value for the square root of minus one,
>or for the incomprehensibly strained "line at infinity."
>
>When you ask what these features provide, I try to explain how they make
>it possible to write some very clear simple code.  I think Kirby will
>attest to the fact that decorators seriously improved the readability
>of his "hypertoons" code.  Decorators should be used sparingly, if at
>all.  That is not to say they shouldn't exist.  The key to understanding
>when decorators are useful can be summarized as "whenever you feel
>you are writing boilerplate your skin should itch."  This doesn't mean
>that you should not write boilerplate on occasion, but rather that you
>should be searching for a way around it.
>
>I tried to explain to you why I found properties such a useful addition.
>Their existence allows me to write code without the "protective
>generality" of always writing accessors and mutators in case, some two
>years hence, I need to change more than the single attribute on a
>mutation, or decide some value that I have been storing is much better
>left calculated.  This was unconvincing to you, but you responded
>more in the vein of "nobody should be allowed to use this, so the code
>I read is simpler."  I am surprised you accept exceptions (a relatively
>recent development in the design of computer languages).
>
>The rule I use in commenting code is that you should not comment use of
>features of a language in code written in that language.  Programmers
>who read code written in Python are responsible for learning Python, and
>there is no excuse for code like:
>     a = range(12)  # Make a list of integers between 0 and 11 inclusive
>The comment slows down your reading of the code and distracts you from
>reading the application itself.  The language is the given.  When you
>choose a language, you buy its tradeoffs.  If you cannot stand
>descriptors, insist on python 2.3.  When you ask what something is good
>for, and get given an explanation that turns out to not make your life
>simpler, don't presume that the examples given are therefore useless.
>You have not spent a career writing code that must be rewritten
>constantly (to accommodate changing requirements); properties help in
>that task, in part because you can avoid using them until necessary,
>with their existence in your back pocket.
>
> > Can we accept the less sophisticated approaches on equal footing?
>
>We can accept the less sophisticated approach to designing programs
>as workable.  Do you seriously think that when designing a language
>equal weight should be given to those that understand the implications
>of a decision and those who "go with their gut?"  It is one thing to
>make ivory tower decisions, and another to know the impact a decision
>might have.
>
>
>--Scott David Daniels
>[hidden email]
>
>_______________________________________________
>Edu-sig mailing list
>[hidden email]
>http://mail.python.org/mailman/listinfo/edu-sig
>
>  
>

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Dethe Elza
In reply to this post by Scott David Daniels
Arthur,

You may be happy to know that hard-core computer scientists cannot  
agree on the benefits of abstractions such as decorators.

Paul Graham attributes power and elegance to the tersest languages[1]
[2], claiming that fewer lines of code means fewer bug, less time  
writing the code, and less time maintaining the code.

Meanwhile Richard Gabriel notes[2] that code can share with poetry  
the aspect of Compression, in which a few words can hold a great deal  
of meaning, but he is careful to note that this can easily be taken  
too far, resulting in incomprehensible gibberish (in poetry or in code).

Perhaps this comes down to the fact that both men are old hands at  
Lisp, but while Graham literally wrote the book on Common Lisp[3],  
Gabriel wrote "A Critique of Common Lisp."

Graham used a simplistic program to demonstrate succinctness, a straw  
man I could argue against, but it demonstrates what I'm talking  
about, using Python's standard foil: Perl.  The goal is to create a  
function which generates accumulators: Given a number n, it will  
return a new function which takes another number i, and returns n  
incremented by i, storing the accumulating result.

Graham's canonical example is in Common Lisp, and is indeed quite  
succinct.

(defun foo (n)
   (lambda (i) (incf n i)))

And in Perl you have

sub foo {
   my ($n) = @_;
   sub {$n += shift}
}

Which is succinct and perhaps readable to someone thoroughly familiar  
with Perl, but does look like line noise to me.

Perhaps the most succinct you can get this in Python is the following:

def foo(n):
      def bar(i, l=[n]):
          l[0] += i
          return l[0]
      return bar

Although this is quite a bit longer than the Lisp version, it is  
nearly as unreadable as the Perl code.  In part this is because  
Python distinguishes between expressions and statements, so we cannot  
"return l[0] += i".  Also, Python does not allow us to assign to  
local integers, so we hack around this by putting the integer "n" in  
a mutable container "l = [n]".  And lambdas don't allow statements  
(or is it expressions?) so that keeps it from getting succinct as well.

But of course, this is not the canonical Python.  Canonical Python  
would create a class:

class foo:
     def __init__(self, n):
         self.n = n
     def __call__(self, i):
         self.n += i
         return self.n

As you can see, this is not much longer, and (in my eyes at least),  
vastly more readable.  No hacks with lists, it clearly shows that  
we're accumulating the value.  If I were to use this in any real  
system, I would change "self.n" to "self.accumulator" or some such,  
and make it even longer, because readability counts more than  
succinctness, despite what Graham claims[5].

If you're still reading this far you may have noted that I haven't  
actually talked about decorators at all.  In my code, I have come to  
places where there are aspects which cut across classes and methods  
in a way that's not always intuitive or easy to capture in standard  
object-oriented code.  In Java and some other languages they are  
implementing Aspect-Oriented Programming (AOP), where you create  
"cutpoints" where code will be injected for different "aspects" which  
are defined elsewhere.  Generating this code is called "code weaving"  
or "aspect weaving" and the result is not intended to be read or  
modified by humans.  Debugging this type of code must take the  
patience of a saint, since all your line numbers and references would  
have disappeared in the warp and weft.

With decorators I get an 80/20 solution to aspects which cover all of  
the most common (and dare I say, important) uses of AOP, without  
compile-time weaving, or losing line numbering or stack tracing or  
any of my standard editing, reading, or debugging toolkit.  For me,  
this is a big win, and I'm happy to have decorators in my toolbox.  
I'm also quite happy to have generators, list comprehensions,  
properties, and descriptors, because these all fill needs for times I  
have bumped up against a wall of complexity and my code has grown too  
big, too multi-branched to fit comfortably in my head.  Since I do a  
lot of "hobby coding" in my limited spare time, on a lot of different  
project, being able to fit the code in my head is essential.  I need  
to be able to come to a project I left off with months ago and  
quickly grok what it does and why.

That said, I don't make daily use of decorators, descriptors,  
properties, or even generators.  Just as a carpenter's toolbox may  
contain hammers and screwdrivers he uses everyday, and also more  
specialized planes or chisels he uses more rarely (but still values  
having the right tool for the job when he needs it), these are my  
more specialized tools.  I do use list comprehensions daily, they  
have become one of my favored hammers, but I do try to take care to  
use them in a way which enlightens the code rather than obfuscates  
it, which they can certainly do.

And while Lisp hackers like Graham cannot understand why anyone  
wouldn't want to use his all-powerful language, the Smalltalk  
community is equally amused when the concepts they cut their teeth on  
in the seventies are finally adopted by more mainstream languages
[6].  Power quote: "Reinventing Smalltalk, one decade at a time."

--Dethe

[1] http://www.paulgraham.com/icad.html (especially see "Appendix:  
Power" at the end).

[2] http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf (Reuse  
vs. Piecemeal Growth chapter)

[4] http://www.paulgraham.com/acl.html (ANSI Common Lisp)

[3] http://dreamsongs.com/NewFiles/clcrit.pdf (A Critique of Common  
Lisp)

[5] http://www.paulgraham.com/power.html (Succinctness is Power, a  
direct attack on Python)

[6] http://www.intertwingly.net/blog/2005/09/09/The-Case-for-Dynamic- 
Languages (slides link)


"And you think you're so clever and classless and free"
— John Lennon on prototype-based programming



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Dethe Elza
In reply to this post by Arthur-27
On 13-Sep-05, at 7:22 PM, Arthur wrote:

> My argument though is with you, not Guido.  It is about use cases for
> existing features, not about the features themselves.  And in the
> particular case of properties, it was only in going back to Guido's  
> own
> use case illustration that I begin to develop some comfort with why
> properties are there - why they are a neat solution to a limited  
> set of
> problems.  I understand them now more in  terms  of  something akin to
> a GUI event, or a SQL trigger.  You  have a need  to know  when
> something  attempts to set or  get  a particular attribute. The  
> relation
> to the actual attribute might be tenous.  It's an event.  It might  
> begin
> a process that sends an e-mail to Mary. Who knows what. Its all quite
> practical and tangible stuff, though.

As Guido has said, properties don't do anything that couldn't be done  
before with __getattr__ and __setattr__, they just give a cleaner  
syntax for it.  Since VPython makes extensive use of __getattr__ and  
__setattr__, do you think you would like the package more or less if  
they used properties instead?  Or perhaps if instead of (I don't  
actually remember if VPython allows named colours, but bear with me  
for this example):

ball = sphere(color=blue)
# a blue sphere appears on the screen
ball.color = 'red'
# the ball changes instantly to red

would this be better if we wrote:

ball = sphere(color='blue')
ball.setColor('red')

does that make it more readable, or less?

--Dethe

"Trusting a scientist on questions of metaphysics is like paying  
someone else to worship God for you." -- Bill Welton


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dethe Elza
> As Guido has said, properties don't do anything that couldn't be done
> before with __getattr__ and __setattr__, they just give a cleaner
> syntax for it.  Since VPython makes extensive use of __getattr__ and
> __setattr__, do you think you would like the package more or less if
> they used properties instead?  Or perhaps if instead of (I don't
> actually remember if VPython allows named colours, but bear with me
> for this example):
>
> ball = sphere(color=blue)
> # a blue sphere appears on the screen
> ball.color = 'red'
> # the ball changes instantly to red
>
> would this be better if we wrote:
>
> ball = sphere(color='blue')
> ball.setColor('red')
>
> does that make it more readable, or less?

What are you saying here?

ball.color='red' is what is readable.

Why is the color attribute of the sphere anything other than a normal Python
attribute initialized by a keyword argument, with some default? It is set
and retrieved.  No magic.

Are you suggesting that since normal attribute mechanics use __getattr__ and
__setattr__ under the hood, my issue with the use cases of properties are
somehow an issue with Python's entire attribute mechanism.  

If so you have indeed joined the debate, as such ;)

If vpython has some implementation specific reason to need to send an e-mail
to Mary when I change the color attribute, I may in fact have a preference
for the use of __setattr__  directly, as more expressive of the fact that we
are under the hood a bit - but that admittedly can get ugly and the truth is
I would probably myself opt for the convenience of property, maybe going the
whole nine yards and using the further convenience of its decorator form.

If I were sending an e-mail to Mary.

Art


"I didn't get a harrumph out of that guy"
                   Mayor, Blazing Saddles


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

John Zelle
Hi All,

This has been an interesting and enlightening discussion. I have a bit
of knowledge of VPython internals, so I thought I'd jump in here.

Arthur wrote:

>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]] On
>>Behalf Of Dethe Elza
>>As Guido has said, properties don't do anything that couldn't be done
>>before with __getattr__ and __setattr__, they just give a cleaner
>>syntax for it.  Since VPython makes extensive use of __getattr__ and
>>__setattr__, do you think you would like the package more or less if
>>they used properties instead?  Or perhaps if instead of (I don't
>>actually remember if VPython allows named colours, but bear with me
>>for this example):
>>
>>ball = sphere(color=blue)
>># a blue sphere appears on the screen
>>ball.color = 'red'
>># the ball changes instantly to red
>>
>>would this be better if we wrote:
>>
>>ball = sphere(color='blue')
>>ball.setColor('red')
>>
>>does that make it more readable, or less?
>
>
> What are you saying here?
>
> ball.color='red' is what is readable.
>
> Why is the color attribute of the sphere anything other than a normal Python
> attribute initialized by a keyword argument, with some default? It is set
> and retrieved.  No magic.

Actually, there is some magic going on here. Even at the surface level,
setting this attribute has the side effect of changing the appearance of
the object on screen. The efficient way to make sure that happens is for
the setting of the attribute to actually produce the update. In other
words, it actually performs a method call. Beneath the surface, VPython
is using a compiled C++ module where these attribute accesses are mapped
into C++ getter and setter type methods.

>
> Are you suggesting that since normal attribute mechanics use __getattr__ and
> __setattr__ under the hood, my issue with the use cases of properties are
> somehow an issue with Python's entire attribute mechanism.  
>
> If so you have indeed joined the debate, as such ;)
>
> If vpython has some implementation specific reason to need to send an e-mail
> to Mary when I change the color attribute, I may in fact have a preference
> for the use of __setattr__  directly, as more expressive of the fact that we
> are under the hood a bit - but that admittedly can get ugly and the truth is
> I would probably myself opt for the convenience of property, maybe going the
> whole nine yards and using the further convenience of its decorator form.
>

I think the point here is that VPython chooses to use the more Pythonic
interface allowing the user to "think" about colors (and virtually all
other aspects of an visible object) as simple attributes, whereas
underneath it is performing method calls. An alternative API would be to
simply expose the methods [e.g. mysphere.setColor(color.red)]. In fact,
I was first taken aback by VPython's use of what appears to be direct
attribute reference. With experience, I have come to appreciate it.

The beauty of properties is that it provides an easy and elegant way to
provide an attribute-based interface for the client, while allowing the
implementer the flexibility to intercept attribute requests through
methods. Of course, VPython did this using pre-property techniques. But
it's a generally useful thing to do, so making it easy and elegant for
the implementer seems to be a rather unambiguous win.

Just my $.02

--John

--
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA
[hidden email]          (319) 352-8360
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
In reply to this post by Arthur-27


> -----Original Message-----
> From: edu-sig-bounces+ajsiegel=[hidden email] [mailto:edu-sig-
> bounces+ajsiegel=[hidden email]] On Behalf Of Arthur
> the
> whole nine yards and using the further convenience of its decorator form.

Oops. Forgot.  Can't use @property for a set.  Because of course @property
is itself in some sense an accident of history.

Dying to share all this in Python 101.

Art



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Scott David Daniels
In reply to this post by Arthur-27
Arthur wrote:
>...  But I still don't see the connection to XP programming, API design
Do you truly not understand my position, or merely disagree with it?

--Scott David Daniels
[hidden email]

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Dethe Elza
In reply to this post by Arthur-27
Thanks John, you set what I meant.

On 14-Sep-05, at 8:21 AM, Arthur wrote:
> Oops. Forgot.  Can't use @property for a set.  Because of course  
> @property
> is itself in some sense an accident of history.

Not so much an accident of history: property was never intended as a  
decorator and probably shouldn't be used as one.  If you really want  
to create a read-only decorator, make a new one called "readonly" or  
some such.  You can still *implement* it with property, of course.

> Dying to share all this in Python 101.

Not every part of the language needs to fit into an introduction.  
There are obscure parts of English that not everyone uses day to day,  
but that doesn't mean I argue with poets who use them.

--Dethe


"I started with nothing, and I still have most of it."  -- Steven Wright


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dethe Elza
>
> Not every part of the language needs to fit into an introduction.
> There are obscure parts of English that not everyone uses day to day,
> but that doesn't mean I argue with poets who use them.

This started with a Triangle class.

It has 3 sides,

And an area.

And I have made the most excellent point about confusing students by not
being clear about whether one is explaining mechanics and or illustrating a
use case.

If you want to see me as a confused student - you're welcome.

Art


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Arthur-27
In reply to this post by Scott David Daniels


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Scott David Daniels
> Arthur wrote:
> >...  But I still don't see the connection to XP programming, API design
> Do you truly not understand my position, or merely disagree with it?
>

Let's say I don't understand.

And as much as people want to believe I relish being off topic, I don't
believe I am.

I am a confused student - let's say - trying to explain the nature of my
confusion.

Am I communicating the nature of my confusion in an incomprehensible way.
Am I simply not paying attention.  Do I not want to learn?

Or is there some failure in the communication process for which we need to
take joint responsibility?

Art


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Kirby Urner
In reply to this post by Arthur-27
Art:
> I would probably myself opt for the convenience of property, maybe going
> the whole nine yards and using the further convenience of its decorator
> form.

Footnote:  

Although I think Scott did an admirable job of showing how the property
function could be served with the new decorator syntax, I don't think the
trade off in convenience is necessarily worth the convoluted helper
functions that make this short-cut doable.

That being said, I'm quite pleased that Scott spelled it out, and I have in
fact used his invention (in subsequent code).  

In yet more recent code (satacad.py with Vector, Edge and Polyhedron
classes), I'm back to straight attr = property(args) syntax, and quite
satisfied with it.  I feel no strong temptation to use decorators in this
context.

In sum, I wouldn't necessarily go "the whole nine yards" as you've put it.

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: quantum instance

Kirby Urner
In reply to this post by Arthur-27
> This started with a Triangle class.
>
> It has 3 sides,
>

It had 3 sides that I made open to rebinding, such that mytri.a = 6 could be
used to change the shape of the triangle at run time, ergo its area -- which
is why I wanted to see area as both an attribute (makes sense) and a
read-only one at that (because rebinding area could mean any number of side
combinations -- too impractical for my current needs).

> And an area.
>

The area gets to come off as an attribute, as in mytri.area, but it's
triggering a method, cuz my user may have changed one of the sides in the
meantime.  I don't recompute area until I have to (or my Triangle doesn't,
whatever).

> And I have made the most excellent point about confusing students by not
> being clear about whether one is explaining mechanics and or illustrating
> a use case.
>

I think I was clear:  the use case of implementing a Triangle class with
modifiable edges drives home the point of syntax like property.  And as I
mentioned at the time, Alex Martelli gives a similar use case regarding the
Rectangle ('Python in a Nutshell').  In both cases, I think the use case
gives a good example of why we might want to use such syntax (I'm not saying
anything about decorators -- a whole different discussion).

If by mechanics you mean syntax (and underlying implementation) then I think
here we have geometry providing grist for the CS mill (as you said we should
do, and as I agreed we should).  Math feeds CS with examples, and CS
provides math with machine-executable notations -- a two way street of great
pedagogical value.

> If you want to see me as a confused student - you're welcome.
>
> Art

I don't see you as confused.  But I don't see me as confused either.  The
examples were clear, the mechanics are clear.  All that remains are
differences in judgment as to whether this or that other use case merits
using the property feature.  Sometimes, using properties is as bad an idea
as it is a good one, in other contexts, especially in Python, which doesn't
penalize so heavily if you decide to change your design later (so don't
clutter your code just because "you'll wish you had someday").

Kirby


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
12