quantum instance

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

quantum instance

Arthur-27
Me >

>> Would we have flatted the area method before properties, through the
>> __getattr__ mechanism.  Were properties put into the language to make it
>> more convenient for us to do this kind of thing - *as a way of
>> encouraging this kind of pattern*.  I think you - implicated or
>> explicitly  - think yes. I think I explicitly think no.

John >

>I don't understand how you can say "no" to this. Properties exist
>precisely to make it simpler to call methods through attribute access
>syntax, period. My instinct is that, pre-properties, most programmers
>would not have resorted to the __getattr__ magic for these simple cases;
>they would just provide a method-call API (as I did for my graphics
>library). With properties, I would probably now take the other route.

And I don't understand how you can't understand that.

Sometimes we just disagree, it seems.

The version of Python I run - Python 2.4 (#60, Nov 30 2004, 11:49:19) -
discourages me from writing extra code for the purpose of revealing less.
It comes with no "properties" exception of which I am aware.

I guess we all have our own sense of elegance, and the properties discussion
leads me to believe that there is more than one version of Python 2.4 (#60,
Nov 30 2004, 11:49:19) floating around.  Which is as it should be.  

And as it should be taught it should be, it seems to me.

And don't expect that you disagree with *that*.

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
 
> The version of Python I run - Python 2.4 (#60, Nov 30 2004, 11:49:19) -
> discourages me from writing extra code for the purpose of revealing less.
> It comes with no "properties" exception of which I am aware.

<<...>>

>
> Art

Hey Art, this is making very little sense to me.  All versions of 2.4 should
give you 'property' syntax.  Just write:

 >>> class Foo:

       def __get_duh(self):
           return "Well, yeah, Duh!"

       duh = property(__get_duh)

 >>> obj = Foo()
 >>> obj.duh
 'Well, yeah, Duh!'


That's all in my Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32.

Let's not continue until we figure out why this isn't working for you.

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

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


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Saturday, September 17, 2005 7:41 PM
> To: 'Arthur'; [hidden email]
> Subject: RE: [Edu-sig] quantum instance
>
>
> Let's not continue until we figure out why this isn't working for you.

My version works something like this (though this is admittedly a slightly
simplified version):

>>If type(attribute)=='set by assignment' _
  and (needs(setting) or needs (getting)) =='something unusual':
       see if property function might help
  else:
       forget property function exists

Your Python version  - from what I can see - works different.  

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
 
> Your Python version  - from what I can see - works different.
>
> Art

OK, fun.  My Python version goes more like this:

Consider if client Z, inhabitant of knowledge domain X, would tend to think
of this object-related foo as a noun or a verb, e.g. without knowing
anything about Python or programming, but knowing a lot about heart surgery
and its objects, is this something I'd like to send arguments to, or will I
just set it or consult it, with no sense that I need to tweak parameters?

If verb, define a method, and capture the key arguments in a clear API.  

If noun, then aim to implement as an attribute from the point of view of the
user, but if necessary use methods under the hood, as the knowledge domain's
concept of noun versus verb may not precisely match your class designs in
Python (cite our Triangle example).

Bottom line re properties:  Python aims to be accommodating and supply a
noun where the object's user is already thinking noun (because of the native
knowledge domain).

With only a few changes, we could make the client *another programmer* i.e.
someone fluent in coding idioms.  I want other programmers to appreciate my
noun-sense and verb-sense, and so I use properties (or not) to communicate
these subtle nuances.

No one said Python couldn't be subtle.  On the contrary, we call it
expressive.

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
> If verb, define a method, and capture the key arguments in a clear API.
>

Note:  

Sometimes a verb might not imply arguments.  E.g. myheart.beat() makes sense
as a verb if it's supposed to simulate a beat.  

A rule of thumb might be:  if it's a verb, it makes sense to do it over and
over, e.g. myheart.beat(10) also makes sense.  Verbs are doings.

On the other hand, myheart.weight would seem more noun-like, even if it
changes over time.  I suppose I could just as well think of attributes as
adjectives (nouns go with 'state').

Anyway, the more general point is: it's the knowledge domain that should
determine the API, and this often means mimicking real world objects -- e.g.
trying to be "like" a heart.  

I don't believe in a philosophy that insists on making it all uniform (e.g.
either all attributes or all methods), irrespective of how things are in
reality.

In my Triangle class, it made sense for sides a,b,c to be come across as
attributes, and likewise angles A,B,C.  Likewise area and perimeter.  

But if I rotate it by 45 degrees, that seems like a verb, likewise if I
translate or scale it.  It's my common sense notion of a triangle, its
properties, its capabilities, that drives my API, i.e. it's the knowledge
domain, not so much Python.

And yes, there's room for judgment and different APIs, depending on who does
the programming and who represents the knowledge domain.

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

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


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Saturday, September 17, 2005 9:07 PM
> To: 'Arthur'; [hidden email]
> Subject: RE: [Edu-sig] quantum instance
>
>
> > Your Python version  - from what I can see - works different.
> >
> > Art
>
> OK, fun.  My Python version goes more like this:
>
> Consider if client Z, inhabitant of knowledge domain X, would tend to
> think
> of this object-related foo as a noun or a verb

My clients use a version of Python compatible to my own.

But have no interest in what I might tend to think they might tend to think.


They like information -  hard information.  

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
> My clients use a version of Python compatible to my own.
>
> But have no interest in what I might tend to think they might tend to
> think.
>
> They like information -  hard information.
>
> Art

Yes, well, we all have limited experience, depending to some degree on which
clients we work for.  I really do work with cardiologists and heart surgeons
some.  

Fortunately for you and me, Python is emerging from the collective
experiences of a lot of people, a lot of walks of life, not just from Art's
or Kirby's.  

I'm glad I'm not confined to using your version of Python.

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

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


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Sunday, September 18, 2005 11:41 AM
> To: 'Arthur'; [hidden email]
>
> I'm glad I'm not confined to using your version of Python.

As I said, so am my.

I have my confidence scale.  But as I've said previously -it's *never* 10
out of 10.

But I do I think we have no choice but to teach in a way that let's our
students know there are competing versions in play.  I think *that* with a
very high level of confidence.

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 Arthur-27


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
>
> I'm glad I'm not confined to using your version of Python.

My other problem is this:

Did somebody forgot to mention to me, pre-Python2.2, that the language was
missing a fundamental construct for the proper configuration of the proper
API framework?

And allowed me go about my business of constructing improper API frameworks
- because that is what the language supported.

Is it the same somebodies who jump at me when I question the new Python who
would have jumped at me if I had questioned the old?  It often seems so.

Is information hiding also part of community building?

If so, what is being hidden now?

Art

I don't believe the above, BTW -  as long as I stick to my guns that
properties are a minor piece of syntax sugar with a lot being read into
their appearance in the lnaguage. And that if Guido was all-seeing he might
have anticipated a lot more than intended being read into them.

Or else I don't want to believe the above - so I stick to my guns.

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
> My other problem is this:
>
> Did somebody forgot to mention to me, pre-Python2.2, that the language was
> missing a fundamental construct for the proper configuration of the proper
> API framework?

Apparently many programmers felt this lack, including Guido, and added the
missing capability.

To answer your question:  yes, no one thought to tell you -- not clear what
that'd have accomplished.  It's your responsibility to read the PEPs.

> And allowed me go about my business of constructing improper API
> frameworks - because that is what the language supported.
>
> Is it the same somebodies who jump at me when I question the new Python
> who would have jumped at me if I had questioned the old?  It often seems
> so.

You're free to raise objections at any point along the way, no?  Others do,
and often in tones less dark and paranoid, which is probably why they
sometimes get more attention.  

I think you effectively self-marginalize by casting yourself as this
always-marginalized kibitzer.  You're too interested in the soap opera (real
or imagined), seem less attentive to real engineering considerations.

You seem reluctant to believe that real engineering could be a basis for
changes to Python, prefer to invoke images of secret cabals and
behind-the-scenes machinations.  I chalk this up to personality and
temperament.

> Is information hiding also part of community building?
>
> If so, what is being hidden now?
>

You'd have to be on py-dev or be reading the PEPs to get a sense of what's
in the pipeline (maybe you are -- I'm not at the moment, but from time to
time dive into the PEPs).  I mentioned after Europython about how yield, and
hence generators, are getting more features.

I think the process whereby Python Enhancement Proposals get submitted and
hashed through *is* a vital part of Python-the-community and even
Python-the-language, and should be taught, including right from the start,
when introducing it to newbies.

By design, I don't think edu-sig is the place to hash through the merits of
this or that PEP.  Other mechanisms have been established.  So if you
confine your kibitzing to edu-sig, then it's perfectly fine that your
objections don't get a lot of attention.  This is not the place for them, if
their purpose is to influence Python's evolution and direction.  

On the other hand, I think edu-sig *is* the place to voice pedagogical
concerns, i.e. to talk about how we might best teach the language to others.


I think you've given us a lot of valuable input along these lines over the
years and I'm glad you've been generous with your time.  Plus there's Pygeo
itself, which showcases the capabilities of Python/VPython pretty
effectively -- a great advertisement for why Python is such a valuable asset
(including the part about you learning it on your own, having come from
another walk of life besides professional programming -- a good story, all
the better because true).

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
> But I do I think we have no choice but to teach in a way that let's our
> students know there are competing versions in play.  I think *that* with a
> very high level of confidence.
>
> Art

Different teachers will inevitably bring their own "spin" to their teaching.

I can well imagine a class in which Python is brought up primarily to talk
about its deficiencies and inferior qualities e.g. a presentation by some
Scheme guy, pissed that the Python community is making inroads in K-12 and
anxious to head that off.

The background of the teacher matters.  John Zelle has taught Java a lot,
and brings that experience to bear.  At OSCON, I attended a talk on Ruby
geared especially to Java programmers, e.g. "this is how you're used to
doing it in Java, here's how you might do the same thing in Ruby" (followed
by a much shorter piece of code).

I don't think it's the obligation of a teacher to accommodate the spins and
slants of every other teacher, e.g. I'm happy to teach about the property
feature without a hint of your dark warnings about "information hiding" and
the like.  Let Arthur handle Arthur's spin.  Let students drift from one
teacher to another, building up their own biases and spins.

I think we've already agreed it comes down to judgment.  And when it comes
to judgments, we may differ.  That in itself gives neither of us the right
to complain that the other is "discounting" or "ignoring" the other.  The
right to go with one's own sense of right and wrong is a feature, not a bug.
I see no reason to complain if you teach a different version of Python from
mine.
 
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

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


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Sunday, September 18, 2005 4:44 PM
> To: 'Arthur'; [hidden email]
> Subject: RE: [Edu-sig] quantum instance
>
> > My other problem is this:
> >
> > Did somebody forgot to mention to me, pre-Python2.2, that the language
> was
> > missing a fundamental construct for the proper configuration of the
> proper
> > API framework?
>
> Apparently many programmers felt this lack, including Guido, and added the
> missing capability.

Can you please support your statement!

Guido added properties to the language. No doubt. He says they are about
"managed attributes". His example in the original presentation of the use of
properties was quite narrow. In fact it was only in referring back to it
that I feel I began to get my head on straight about what properties were
really intended to be about (IMO).

I believe I am interpreting his purpose much more carefully then are you.  

You feel otherwise.

We are in Lit class arguing interpretation, the author's intent. Some
authors successfully use ambiguity to their advantage.  Perhaps there is a
good deal here.  But in this milieu I can't believe a straight forward
reading of the author's stated intent - which is where I feel I am - is
without merit.

Maybe the cigar is just a cigar.

> To answer your question:  yes, no one thought to tell you -- not clear
> what
> that'd have accomplished.  It's your responsibility to read the PEPs.
>
> > And allowed me go about my business of constructing improper API
> > frameworks - because that is what the language supported.
> >
> > Is it the same somebodies who jump at me when I question the new Python
> > who would have jumped at me if I had questioned the old?  It often seems
> > so.
>
> You're free to raise objections at any point along the way, no?  Others
> do,
> and often in tones less dark and paranoid, which is probably why they
> sometimes get more attention.

I am dark and paranoid when I confront what I (rightly or wrongly) interpret
as some form of group think.  There are reasons for it.  Apologies.

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
> > Apparently many programmers felt this lack, including Guido, and added
> > the missing capability.
>
> Can you please support your statement!
>

The fact that it was added isn't evidence programmers wanted it added?

> Guido added properties to the language. No doubt. He says they are about
> "managed attributes". His example in the original presentation of the use
> of properties was quite narrow. In fact it was only in referring back to
> it that I feel I began to get my head on straight about what properties
> were really intended to be about (IMO).
>
> I believe I am interpreting his purpose much more carefully then are you.
>
> You feel otherwise.

The whole idea of attributes managed through setters and getters (mutators)
is a known design pattern.  SmallTalk wouldn't even allow direct assignment
to attributes, right?  *All* access to variables is "managed."

Setters and getters are built into C# as well, at the syntax level.  Not
because of Python though.  We're talking about a feature of the OO model
that's been around for awhile.  Python acquired this feature later in its
development, but not out of the blue.  

Like many features in Python, you can point to their precedents in other
languages.  List comprehensions from Haskell, generators from Icon...
(correct me if I'm wrong).  Many programmers wouldn't need to closely study
Guido's examples to show what properties are good for; it'd was already a
tool in their tool chest, in other languages (or in Python using __setattr__
and __getattr__ -- less convenient).

You come to OO through Python and all of a sudden it acquires one of these
new (to you) features.  To you, it seems like something alien is creeping
in, perhaps against some deep-seated philosophy that you've come to respect.
You worry something valuable is being undermined.  These developments seem
sinister, all about "information hiding" or whatever.  

But to someone else, a long-time OO coder (who maybe started in SmallTalk)
the reaction is more like "about time, what took you so long?"

> We are in Lit class arguing interpretation, the author's intent. Some
> authors successfully use ambiguity to their advantage.  Perhaps there is a
> good deal here.  But in this milieu I can't believe a straight forward
> reading of the author's stated intent - which is where I feel I am - is
> without merit.
>
> Maybe the cigar is just a cigar.
>

Kinda cryptic.  

I think people are being quite up front about what properties are good for,
why other programming languages besides Python manage access to attributes
(e.g. to protect private variables from direct exposure through the API).  

Python could get along nicely without 'em at first, sure, but adding a
property method was a small price to pay for a valuable feature programmers
have come to expect within the OO paradigm.  

What's so hard to understand here?

> I am dark and paranoid when I confront what I (rightly or wrongly)
> interpret as some form of group think.  There are reasons for it.  
> Apologies.
>
> Art

What's wrong with "group think"?  I know we're supposed to reflexively
dislike the sound of that, but when a community reaches a consensus, based
on professional history and prior experience, must it always be wrong?

I feel the explanations put forward for why the property feature was added
have made plenty of sense.  You seem to reject them on the basis of:  well
if *I* Arthur didn't need them, how come anyone else should?
 
I felt the same way about Guido's change to the division operator. In the
new design, a/b will always be a float, a//b always an integer -- much
better, and not a politically motivated cave-in to newbies learning VPython
(the dark motive you always persisted in reading in).

Perhaps my version of Python is evolving at a faster rate, and in different
directions, than you necessarily need in your version, for what you're
trying to do.  What's the harm in that, as long as your code still runs?

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

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


> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Sunday, September 18, 2005 7:45 PM
> To: 'Arthur'; [hidden email]
> Subject: RE: [Edu-sig] quantum instance
>
> > > Apparently many programmers felt this lack, including Guido, and added
> > > the missing capability.
> >
> > Can you please support your statement!
> >
>
> The fact that it was added isn't evidence programmers wanted it added?

Though not necessarily for the purposes you seem to suppose.

>
> > Guido added properties to the language. No doubt. He says they are about
> > "managed attributes". His example in the original presentation of the
> use
> > of properties was quite narrow. In fact it was only in referring back to
> > it that I feel I began to get my head on straight about what properties
> > were really intended to be about (IMO).
> >
> > I believe I am interpreting his purpose much more carefully then are
> you.
> >
> > You feel otherwise.
>
> The whole idea of attributes managed through setters and getters
> (mutators)
> is a known design pattern.  SmallTalk wouldn't even allow direct
> assignment
> to attributes, right?  *All* access to variables is "managed."

> Setters and getters are built into C# as well, at the syntax level.  Not
> because of Python though.  We're talking about a feature of the OO model
> that's been around for awhile.  Python acquired this feature later in its
> development, but not out of the blue.

Python is not Java or C# or Smalltalk.

I know - because if it were I wouldn't be programming in it.
 
> What's wrong with "group think"?  I know we're supposed to reflexively
> dislike the sound of that, but when a community reaches a consensus, based
> on professional history and prior experience, must it always be wrong?
>
> I feel the explanations put forward for why the property feature was added
> have made plenty of sense.  

I have heard 3 or 4 explanations. And don't see much logical connection
between them.

It sometimes appears that community ethos is to work backward form the fact
that it is there, to the knowing explanation for why its good its there.  

My only objection to it being there - in fact - is the lack of consensus as
to the compelling reason it is necessary.  There seems to be agreement, in
fact, on only this one aspect of the reason for its presence as a built_in
function.  The fact that the reason is compelling.

Whatever the hell it is.

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
> Whatever the hell it is.
>
> Art
>

As you wish.  

However I'm going to resist the temptation (won't be suckered into?)
restating the rationale(s).  

Sometimes "persuading Arthur" is just too much work -- and to what end?

Besides, your version of Python doesn't have these features, so what's the
problem?

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

John Zelle
In reply to this post by Arthur-27


Arthur wrote:

>
> My only objection to it being there - in fact - is the lack of consensus as
> to the compelling reason it is necessary.  There seems to be agreement, in
> fact, on only this one aspect of the reason for its presence as a built_in
> function.  The fact that the reason is compelling.
>

I thought we already agreed that properties are a _convenience_. We
could already do everything that properties give us using __getattr__
and friends. The _convenience_ was added because many people find it
useful. You seem to be saying that having multiple good reasons for a
feature is an argument against its inclusion! Most of us consider
multiple justifications evidence of a compelling feature. To extend the
argument in your direction: I _can_ do everything I _need_ to do in C++,
Java, or even assembler. I choose to use Python exactly because it makes
the things I need to do _more convenient_ to accomplish.

Mind you, I have managed quite well in Python without properties. Now
that I have them, I will use them. Furthermore, because it allows me to
do something I feel is useful in a simpler way, I will probably use them
more often than I used __getattr__ magic before. That is, the benefit I
derive (attribute access syntax with implementation independence) is now
offset by an even smaller overhead cost (code complexity). Plus my code
is more transparent, a double win. And it in no way affects how you have
to write your code, so that argument that you don't want to do things
the "Java way" (or any other way) is a complete strawman.

I still have not read an argument that the property feature itself is in
_any_ way a bad thing. Only your claim that  some people may like them
for reasons that differ from Guido's (and even that is open to
interpretation--I happen to view Guido's use-case and the
implementation-independence use-case as one and the same). Hence I stand
by my previous conclusion that properties are an unambiguously Good
Thing (tm).

> Whatever the hell it is.

"It" is convenience. Convenience is the compelling argument. I guess
I'll have to accept your offering the we simply disagree here. My only
misgiving is that I still don't know exactly what we're disagreeing
about. But we've probably already spent more time and effort than this
particular disagreement was worth.

--
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


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of John Zelle
> Sent: Sunday, September 18, 2005 11:03 PM
> To: [hidden email]
> Subject: Re: [Edu-sig] quantum instance
>
>
>
> Arthur wrote:
>
> >
> > My only objection to it being there - in fact - is the lack of consensus
> as
> > to the compelling reason it is necessary.  There seems to be agreement,
> in
> > fact, on only this one aspect of the reason for its presence as a
> built_in
> > function.  The fact that the reason is compelling.
> >
>
> I thought we already agreed that properties are a _convenience_.

John had written -

"""
Properties exist
precisely to make it simpler to call methods through attribute access
syntax, period. My instinct is that, pre-properties, most programmers
would not have resorted to the __getattr__ magic for these simple cases;
they would just provide a method-call API (as I did for my graphics
library). With properties, I would probably now take the other route.
"""

Properties - which were meant as a *mere convenience* - seem here to  be
influencing an outcome. To me, a not insignificant outcome. Not what one
thinks of when one thinks of mere convenience.

Kirby believes - is "adamantly" too strong -  that properties were added to
the language just so as to influence this kind of outcome. To bring Python
more in line with generally accepted OOP thinking and practice.  

That is not an unreasonable thing to believe when one considers the name of
the function, the general milieu of the influence of the leading languages
such as Java and C#.

I happen not, however, to believe it.

Perhaps because I don't want to.

My thought is that it is highly preferable - except in highly unusual
circumstances - to call methods through method call syntax and to access
attributes through attribute access syntax.  For reasons that are only
obvious - we know better whether we are accessing something akin to a stored
value or, in contrast, calling for something akin to a calculation of a
value. Which is information. Information is good.

Knowing that there is authority in OOP theory that appears to be directly
contrary to my preference here. And not caring a whole lot.

The question is:

Is the inclusion of properties into Python in fact to any extent as Kirby
(and you, I think) seem to interpret it - an implicit vote on this matter?

That is the essential question I have been trying to pursue - not whether it
is more or less convenient.  It is more.  

But its cost is the extent to which it influences outcomes in unintended
directions. If it was intended to influence toward greater use of the
technique of calling methods through attribute access syntax, it is an
unambiguous win.  Because it  - witness your statement above - undoubtedly
does.

If one believes - as do I - that there was no such intention, then the
addition of properties has suffered from the fate of having unintended
consequences.  And in that sense cannot be viewed as an unambiguous win.

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

Laura Creighton
In reply to this post by Kirby Urner
In a message of Sun, 18 Sep 2005 16:45:21 PDT, "Kirby Urner" writes:

>Perhaps my version of Python is evolving at a faster rate, and in differe
>nt
>directions, than you necessarily need in your version, for what you're
>trying to do.  What's the harm in that, as long as your code still runs?
>
>Kirby


There is enormous potential harm in this.  The problem is that
programming is not an individual activity.  When new features make
code harder to read, or harder to understand, then readers are
penalised at the expense of writers.  When bugs are easier to make,
or harder to detect when reading code, then everybody suffers.

This is terrible for the productivity of a company.  Once your company
is beyond a certain size -- the exact number is subject to debate, and
it varies depending on what language you use -- and once your codebase
is beyond a certain size, you will find that you spend far, far, far
more time _reading_ code than _writing_ it.  The more senior you are,
the worse this is, and managers often end up writing little or no code
at all.

This means that any productivity gains you get when you add {feature}
which makes it easier to write code X has to be weighed against the
productivity losses when you have to read {feature}.  Since readers
outnumber writers, there comes a point where no feature should be
added that produces less-readable code, on the grounds of productivity
gains to the code-writers alone.  Remember, the productivity of a
company is not driven by the speed at which your coders can write
new code.  Instead it is the speed at which they can understand the
codebase, and the ease in which they can make modifications to it, and
how bug-free those modifications are that matter.  So if your new
feature makes the code harder to read, it had better make certain
bugs harder to make, or certain modifications easier to make in a
bug free way, or have some other benefit.

Some languages have developed the way they have precisely because
they have persued some other benefit to the exclusion of all else.
C++ sacrifices readability for speed. This was a fine trade for
those people who absolutely must have the speed.  But as CPUs
got faster, people found their companies were more productive
using something else.

If you have worked commercially, then you will already be familiar
with this situation.  'I don't have time to understand this code, I
will just rewrite it instead'.  This happens all the time.  Writing is
easy.  Understanding is hard.  But every time this happens, there is
an indication that something is seriously wrong in your company.
The fact that it is wrong in everybody else's company too is no
excuse, just a sad commentary on the state of the art.

Was the original code too poorly written?  poorly documented? Is the
new programmer too lazy to read the code?  Too unskilled at reading
code?  Is the old code obscure but really damn excellent at something
important, and the new version inferior? Will it cause subtle bugs?
What about the reabability of the new version?  Next week will
somebody come along, not understand _it_ either, and reinvent the
wheel a third time?

Sometimes the problem is with the language itself.  Take Perl.
I never bother, any more, trying to deeply understand what any
Perl script I find is doing.  I just rewrite it in Python.  I will
never have any confidence in my ability to 'understand' what an
arbitrary Perl script does.  I've been wrong too often.  

One of the sad things about life as a commercial programmer is that
often only the most junior programmers get to write code all day.
This is because somebody else has come and given them the specs and
told them what to write.  Everybody else has to figure out what to
write and where to write it, which requires being familiar with the
code base, which requires reading it regularly, which takes time.
This means that the coolest in new features, those meant to be used
_sparingly_ fall directly into the hands of those who do not have the
maturity and experience to know when not to use them.  With predictable
results. :-)

This means come code review time, you have to waste a whole bunch of
time explaining to your junior people why they need to rewrite their
code to not use this feature.  This makes code review a lot more
painful and acrimonious than it was.  And it is difficult on the
reviewer.  What do you say when you are only 65% convinced that this
is a poor use of {feature}?  Especially when what you want to say
amounts to 'my XX years of experience in the field say that this is
too cutesy?'  Your junior programmers may only conclude from this that
you are an senile old fart.  You may conclude that they lack the
wisdom that God gave green apples.  Age-based splits in your company
are among the hardest things to combat and sap morale and team building.
Pair programming will not work unless there is mutual respect.

In general, the greater the difference between 'your best people'
and 'your worst people' the harder productivity suffers.  If the
language is hard to use, you may find out that only your top people
provide positive value to the company.  Your worst people subtract
value.  Not only do the things they write have to be rewritten, but
everybody wastes time on bugs they caused, and talking to them with
their problems and so on and so forth.  I once managed a project
that was late, and the only way we found to fix it was to take the
6 worst people on the team and send them to the other side of the
country to take 3 weeks of training in some damn thing that wasn't
even relevant to what our company did -- I forget what.   Then
everybody else got the job done.  But those 6 people didn't learn
much about how to be productive.  What they really needed was
training in UI design and how to use C++ without screwing up so much.
But Andrew Koenig hadn't written _C++ Traps and Pitfalls_ yet,
http://www.accu.org/bookreviews/public/reviews/c/c002114.htm
so we couldn't give them a course based on it.  And so it goes.
Some languages have grown so much that only experts can be
productive with it.

What's more, even after you have your own company in shape, with nobody
abusing the new features any more, you still have to interface with
code written by people who do not work for your company.  And they may
not have as strict a set of standards as you do. If the innappropriate
use of a new feature makes for buggy code, then you may be forced to
not use some package that over-uses the feature despite its attractiveness
in other ways.  And you have absolutely no control over these people.

Even deciding whether to use somebody else's code requires reading it.
If the code is hard to read, you may find that you do not have the
time.  Obscure language features can make 'spot the poorly written
code' game a lot harder.  What you need is a way to quickly tell if
the code you are reading is good or not.  For my own peace of mind, I
have decided that 'anybody who over-uses language feature X as much as
those guys do is statistically unlikely to be up to anything good' - but
I know as well as anybody that 'statistically unlikely' is not the
same thing as 'never'.  What opportunities are being missed?

It is the tragedy of the commons all over again.  Code-writers have
the interest and motivation to add every feature they dream up into
the languages they create, in the same way that sheep-owners have
the interest and motivation to overgraze the commons.

Laura
_______________________________________________
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

Laura Creighton
In a message of Mon, 19 Sep 2005 12:21:28 +0200, Laura Creighton wrote:
<probably too much>

I just want to mention that I like properties.  I think they make the
code easier to read.  I've read too much code where people who
wanted the behaviour of properties got out __getattr__ and did
it wrong.  Or decided that some hideous thing using metaclasses
was the way to go.  Or that using __slots__ to restrict access
was a fine idea.  So I think that code readability has improved.

My problem with properties is some of the people who use them.  There
is a class of people who go around compulsively adding restrictions,
wherever they go, whenver they cannot think of a reason not to.  It
makes them feel 'safer' or 'more professional' or something.
Unfortunately, this desire to over-control everything frequently
shows up in people who have no more imagination than a turnip.  This
is a bad combination.

Laura



_______________________________________________
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
Arthur:
> My thought is that it is highly preferable - except in highly unusual
> circumstances - to call methods through method call syntax and to access
> attributes through attribute access syntax.  For reasons that are only
> obvious - we know better whether we are accessing something akin to a
> stored value or, in contrast, calling for something akin to a calculation
> of a value. Which is information. Information is good.

And this is what I *don't* believe.  I think it's preferable to make mytri.A
(angle A) come across as an attribute, not a method call, even if I use a
method call to compute it on the fly.  

I want to be able to express user intuitions about what's a method and
what's an attribute drawing from a knowledge domain.  I don't want to
instruct a user in how Python must necessarily force a different view.

If the user wants to know whether a method is being invoked, the user should
just look at my source code (I think open source is highly preferable).

> Is the inclusion of properties into Python in fact to any extent as Kirby
> (and you, I think) seem to interpret it - an implicit vote on this matter?
>

Sure.  A lot of us think properties are a good idea.  *Every* feature added
to Python may be seen as an implicit "vote" although the precise process
whereby features get added is a little different from simple polling.

> But its cost is the extent to which it influences outcomes in unintended
> directions. If it was intended to influence toward greater use of the
> technique of calling methods through attribute access syntax, it is an
> unambiguous win.  Because it  - witness your statement above - undoubtedly
> does.
>

Yes, an unambiguous win.  Using attribute syntax to invoke methods is a good
thing in some circumstances (they don't even have to be "unusual"
circumstances).

I think you're misplacing your distrust.  If the source code is not
available at all, that's one issue.  There're lots of ways to hide
information in that case, including back doors, trap doors, whatever.  

But properties are not about hiding the source.  Properties are about making
the control panel more rational and stable from a user's point of view
(where the user may be oneself or another programmer).

> If one believes - as do I - that there was no such intention, then the
> addition of properties has suffered from the fate of having unintended
> consequences.  And in that sense cannot be viewed as an unambiguous win.
>
> Art

I believe encouraging the use of attribute syntax to invoke methods behind
the scenes is synonymous with managed access to class internals.  It's what
OO is encouraging and what Python is encouraging.  I don't subscribe to your
philosophy that we should avoid doing this.  I do it, and will continue to
do it, without apology.

Kirby


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