> >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?
> 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.
Yes, that's true of course. You make a lot of good points.
In the case of property syntax, I think as you do, that it adds clarity to
the code. It also encourages a practice Arthur doesn't like, and I have no
problem with that, as I don't think Arthur's distrust is well founded in
But it *is* possible for a language to make wrong turns, and even though old
code still runs, the new features encourage a lot of bad habits and in
general contribute to the unreadability of the code. Python *could* take
these turns for the worse. Feature creep/bloat might eat away from its
integrity from within.
I was being too glib.
And again, I have no problem encouraging the use of attribute syntax to
invoke methods if that's what makes an API easier to use and maintain.
We saw how that works in VPython (C++/color), how it works in a triangle,
how it might work in any number of not-that-unusual circumstances. Arthur
thinks maybe this practice lacks integrity but I think he's just projecting
from some other knowledge domain he's been exposed to. I refuse to be
swayed by his sense of aesthetics in this case.
----- Original Message -----
From: Kirby Urner <[hidden email]>
Date: Monday, September 19, 2005 12:18 pm
Subject: RE: [Edu-sig] quantum instance
> 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.
Working with, rather than against, others' misaligned intuitions is
the anti-thesis of the scientific spirit.
You don't propose that there is no meaningful distinction between
methods and attributes.
You might be able to con me into believeing *that*, at least. ;)
Instead you acknowledge the distinction but are consciously
using the power to shuffle appearances to appease and re-enforce
intuitions that happen to be wrong.
I have to suppose that a intepretation of computer science that
seems to support that approach is a misreading of the science.
I am a great believer in the proposition that in the end, Reality wins.
Put properties away in your use case, and you have no choice but to
transcend the users' misaligned intuitions, and align with reality.
I don't for a moment believe that can be harmful to your
All of which is besides the point.
Please stop implying that you have some insight that Python is
encouraging you toward this approach.
> Working with, rather than against, others' misaligned intuitions is
> the anti-thesis of the scientific spirit.
Which is maybe why I'm working against your misaligned intuitions. ;-D
> You don't propose that there is no meaningful distinction between
> methods and attributes.
> You might be able to con me into believeing *that*, at least. ;)
> Instead you acknowledge the distinction but are consciously
> using the power to shuffle appearances to appease and re-enforce
> intuitions that happen to be wrong.
No, the knowledge domain isn't "wrong" when it thinks of angles A,B,C as
*attributes* of a triangle, or myaccount.balance as an *attribute* of my
bank account -- even if there're SQL lookups or cosine calculations going on
behind the scenes.
How a particular programming language needs to work to satisfy a use case
needn't trump the basic intuitions of the user. You want to "educate" your
user about what you had to do in Python. I say the user shouldn't have to
care about that. Python is a servant, a tool, not a dictator.
I don't give a rats ass what hoops you needed to jump through to make
'weight' an attribute of my heart object, not a method. As the client
cardiologist, I'm telling you what I want the API to look like -- or I'll
get a more competent programmer.
You don't want to acknowledge that verb-sense and noun-sense are prior to
any programming language (part of ordinary thinking). The whole idea of OO
is we're modeling object-worlds , trying to make our code meet the
expectations of users who may *already have* a refined understanding of
their own discipline (gasp!).
We're here to learn from clients, and do our best to mirror their
expectations, not second-guess them at every turn. You seem temperamentally
incapable of adopting this attitude.
> I have to suppose that a intepretation of computer science that
> seems to support that approach is a misreading of the science.
> I am a great believer in the proposition that in the end, Reality wins.
Python isn't "reality". It's a modeling tool. Programmers and programming
languages are about helping scientists and others get work done, not
educating them about what a Python callable is, vs. an attribute.
How your objection sounds to me: "how can you in good faith make humans
look *that big* on a movie screen? -- humans really aren't that huge, nor
are they flat." You seem to deny that it's OK to model, to represent, to
use any special effects.
Artists use perspective to give the illusion of depth on a flat surface --
is that somehow anti-scientific in your book? Properties are an "illusion"
in the same sense. They're about mirroring expectations -- *legitimate*
expectations. Likewise with the whole OO apparatus of classes and objects
-- the cues come from reality, but the implementation (in the form of a
computer language) is merely a representation (we hope a nuanced and
> Put properties away in your use case, and you have no choice but to
> transcend the users' misaligned intuitions, and align with reality.
> I don't for a moment believe that can be harmful to your
I do. You're arrogantly putting Python front and center, thinking it
defines "reality" in some sense, over and above what your client learned in
medical school, banking school or whatever. *Ask* them what's a verb and
what's a noun, don't *tell* them. Python shouldn't get in their way.
> All of which is besides the point.
> Please stop implying that you have some insight that Python is
> encouraging you toward this approach.
> It's slander - as far as I am concerned.
You were the one suggesting Python was (inadvertently?) encouraging the use
of attribute syntax to trigger methods. I'm agreeing with you, it does, and
it should -- and it's not inadvertent.
Bottom line: We're trying to paint it as *they* see it. This is not
pandering. It's working with professionals who know their own jobs -- yet
may know nothing much about programming.
> You want to have your intuition as to someone else's intuition control -
> in a scientific setting. We are at unscience**2 - before we get started.
No, we're having a meeting of the minds, me and the client. I go through
iterations of the API, and the client lets me know if I'm on the right
track. You make it sound like it's all guess work. It ain't.
In financial planning, isn't it a good idea to ask the client what his or
her goals might be, his or her sense of what's an ethical investment, other
questions? This is what I'd want in a financial planner.
Client-centric consulting, we might call it. Basic good sense, and already
a popular business model. Contract programmers aren't *totally* clueless.
> The closest thing to reality we might have to grasp unto
> is the grammar of the language in which we are choosing to converse.
Which *isn't* Python. I've been in hours and hours of meetings with clients
and haven't had to force them into learning how to use my tools (Visual
FoxPro, Python, whatever).
My job is to learn as much of the knowledge domain as needed to meet my
clients' legitimate expectations as already competent professionals. If my
client wants to learn more programming in the process, fine, but that's
And if/when I need a heart operation (god forbid), I don't need to know
about all the surgeon's tricks of the trade, when it comes to keeping me
> I would urge you to go with that.
> I will, in any case.
> In part at the urging of *my* version of Python.
I'll pass on taking your advice. I've been a contract programmer for
several decades, much longer than you have. I think that counts for
> You'd have to be on py-dev or be reading the PEPs to get a sense of
> 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.
Or read "What's New in Python 2.X" that Andrew Kuchling writes for
every release. Here is the 2.4 version:
"No lesson seems to be so deeply inculcated by experience of life as
that you should never trust experts. If you believe doctors, nothing
is wholesome; if you believe theologians, nothing is innocent; if you
believe soldiers, nothing is safe."
--Lord Salisbury, 19th century British prime minister
> We saw how that works in VPython (C++/color), how it works in a
> how it might work in any number of not-that-unusual circumstances.
I thought I had written an example using PyGame, but I don't see it
now. Perhaps it was when I was having trouble with my mail last month.
In any case, one more usecase for properties, related to Kirby's
triangle example, is PyGame's Rect. A Rect has the following
properties, all modifiable, and setting any of them will update any
Certainly these are merely conveniences which could be replaced with
just left,top,width,height (or various other combinations). However,
in a game you are likely to need a substantial subset of these in the
course of the game, and having easy accessors like
this makes the code vastly more readable than strewing
if (sprite.left + sprite.width) > some_offset:
when what you mean is
if sprite.right > some_offset:
For what it's worth
A good engineer is a person who makes a design that works with as few
original ideas as possible. --Freeman Dyson
> -----Original Message-----
> From: Kirby Urner [mailto:[hidden email]]
> Sent: Monday, September 19, 2005 4:09 PM
> To: [hidden email] > Cc: [hidden email]; 'John Zelle'
> Subject: RE: [Edu-sig] quantum instance
> > You want to have your intuition as to someone else's intuition control -
> > in a scientific setting. We are at unscience**2 - before we get
> No, we're having a meeting of the minds, me and the client. I go through
> iterations of the API, and the client lets me know if I'm on the right
> track. You make it sound like it's all guess work. It ain't.
Of course you are not representing that you are talking about an actual
Python Application Programmers Interface that you have written for actual
surgeons who intend to use it - in reality - as an Application Programmers
You are talking about something else, applying a few decorators to a few
property functions, which then entitle you to talk about it as if you were -
Speculating along those lines of course makes me an obnoxious bastard - but
we already knew that.
> Speculating along those lines of course makes me an obnoxious bastard -
> but we already knew that.
No you're right of course. I was conflating a lot of experience into a
story about me and the heart surgeons, but at some expense in realism.
More realistically, the point of contact between my "world of code" and the
knowledge domain of cardiology is the event-driven GUI -- that's what we
focus on and iteratively rework. I've had my GUIs running in operating
rooms (e.g. CORIS), but these days they mostly run on back office desks at
Regional Heart Data Services (less stressful for me, plus I don't have to
change clothing just to get access to the site).
The low level methods vs. attributes thing is more within the object world
of programmers coding for other programmers.
As a FoxPro programmer, I get to interact with library objects through APIs.
FontBold is an attribute of a text field and is either true or false. In
code: thisform.text1.FontBold = .T. (not a method call). DateFormat is
another attribute (not a method call) and accepts values 1-14 (e.g. 7 is
described as 'Japan' and formats a date as yy/mm/dd).
When I change an attribute at design time, I'll often see immediate changes
in the form I'm designing. My change to a property triggers methods in the
underlying GUI that is the FoxPro IDE itself -- a very typical use case,
replicated throughout the programming world (e.g. in VPython).
Given I'm trying to help math teachers integrate programming into their new
math/CS hybrid course materials, the use of Python properties is more
explicit when I'm doing my flavor of Pythonic mathematics. That's where
you'll find myvector.length triggering _get_length() behind the scenes.
Your idea that an API should carry information about the underlying
mechanisms, at the expense of mirroring expectations inherent in the user's
knowledge domain, is wrongheaded. OO is all about modeling object worlds,
meeting user expectations (where users may be other programmers), and
Python's property feature is one standard tool for achieving this. Meeting
user expectations is neither anti-scientific nor pandering -- it's the job
of a competent programmer, including when coding for other programmers.
Your objections against having attribute syntax trigger setters and getters,
couched in some sanctimonious rhetoric about "reality" and the badness of
"information hiding" comes across on my end as bogus, poorly thought out,
reflective of your inexperience and apparently weak grasp of what OO
programming is all about. From my point of view, you simply don't know what
you're talking about.
I'm in no way persuaded that you have some special insight into what the
property feature is "really" intended to provide, based on some supposedly
close reading of Guido's examples. It's there for the same reason it's in
other OO languages, to help coders build and maintain APIs that make sense
to their users.
> I'm in no way persuaded that you have some special insight into
> what the
> property feature is "really" intended to provide, based on some
> supposedlyclose reading of Guido's examples. It's there for the
> same reason it's in
> other OO languages, to help coders build and maintain APIs that
> make sense
> to their users.