Re: [Edu-sig] quantum instance
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] Sent: Monday, September 19, 2005 4:09 PM To: [EMAIL PROTECTED] Cc: edu-sig@python.org; '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 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. 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 Interface. 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 - in reality. Speculating along those lines of course makes me an obnoxious bastard - but we already knew that. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
- Original Message - From: Kirby Urner [EMAIL PROTECTED] Date: Tuesday, September 20, 2005 12:34 pm Subject: RE: [Edu-sig] quantum instance 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. You win. But only in the sense that you get the last word. Even *I'm* tired of the thread. Let's move on. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
You win. But only in the sense that you get the last word. Got it. I'll keep in mind you've not changed your position. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Laura: 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 this case. 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. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
- Original Message - From: Kirby Urner [EMAIL PROTECTED] 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 scientists/users. 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. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 [1], 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 expressive one). 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 scientists/users. 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. Art 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. Kirby [1] for more re 'object worlds', see 'Designing Engineers (Inside Technology) by Louis L. Bucciarelli (MIT Press, 1996). http://www.amazon.com/exec/obidos/tg/detail/-/0262522128/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
- Original Message - From: Kirby Urner [EMAIL PROTECTED] Subject: RE: [Edu-sig] quantum instance 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 have your intuition as to someone else's intuition control - in a scientific setting. We are at unscience**2 - before we get started. The closest thing to reality we might have to grasp unto is the grammar of the language in which we are choosing to converse. I would urge you to go with that. I will, in any case. In part at the urging of *my* version of Python. 2.4 Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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 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 somewhat optional. 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 alive. I would urge you to go with that. I will, in any case. In part at the urging of *my* version of Python. 2.4 Art 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 something. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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? 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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_. 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 ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Zelle Sent: Sunday, September 18, 2005 11:03 PM To: edu-sig@python.org 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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, 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 9:07 PM To: 'Arthur'; edu-sig@python.org 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: Arthur [mailto:[EMAIL PROTECTED] I'm confused I tell you ;) I think what I am trying to communicate is the fact that folks like me are not really interested in being: taught how to program Though we are anxious to be taught how to program What could be clearer? Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur, It often seems to me that I agree with you, but you think that you don't agree with me. This may be one of those cases. Arthur wrote: -Original Message- I'm confused I tell you ;) Scott David's Triangle did *not* use a property for area. I think that was quite purposeful. OTOH, his general explanation for the use case of properties in respect to API design seemed to me to be a perfect defense of the extensive use of a pattern of: @property def getx(self): return self._x @porperty def sety(self,x) self._x =x because while now x is a normal attribute you never know what tomorrow may bring. First up, I don't particularly like the decorator syntax here. However main concern is (in your words) the use cases for properties. No one is arguing that you should use use properties anywhere where normal attribute access suffices. The point is that you can just use the simple attribute access mechanism if that is what you need now. Later on, if your design changes, you can use properties so that the API remains unchanged even though you are now using a method call. Not having to change the API is good in two ways. First, it means that existing clients don't break, and second at preserves the simpler user model of assigning and reading attributes. This second advantage is one that a desginer might choose to use up-front. That is, even when an initial design uses a method call, it might be convenient for users to have an attribute-based API (ala VPython). OTOH, as you point out Alex did use exactly your case of the area of a Triangle to illustrate properties in Nutshell. Was he simply illustrating mechanics or, in so doing, advocating a use case as well? 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. 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. John and Dethe point out that when a color attribute in vpython is changed the proverbial e-mail to Mary needs to be sent - rerender. Before properties it was done under the covers, now we have the convenience of properties as an alternative. The unambiguous use case, IMO. John feels the appearance of properties in the language to be an unambiguous win. I would probably agree if I didn't believe it had the side effect of having some of us second-guessing the way they did business pre-properties. H. Are you saying adding something to the language that provides a more elegant way of doing what you were doing before (__getattr__) is a bad thing? Or are you talking about using properties everywhere you used to just do attribute reference? The former I don't understand. The latter I already addressed; don't use a property unless that is what you need. I guess I am pleading for constraint in the presentation of properties to novices, with clear *and narrow* use cases. I can't disagree with this. Beginners don't need properties. Start with attribute reference. It's important to realize that this would be anathema in many OO languages (Smalltalk, Java, C++), but it's OK in Python because it still maintains implementation independence. I used to be able to guarantee this through __getattr__ and friends. Now it's much simpler with properties. Its part of my campaign for this year's Willison award. I'm think my chances are 50/50, best case ;) Best of luck to you. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
I don't see you as confused. Can't we agree about anything? I'm confused I tell you ;) Scott David's Triangle did *not* use a property for area. I think that was quite purposeful. I was referring to my Triangle class in http://mail.python.org/pipermail/edu-sig/2005-August/005063.html (admittedly not my first version). I use properties (for the triangle's angles too), and area is a property (behind which is getArea). I don't use any decorators, though Scott has shown how we might do this by then. I wrote: It's easy to think of angles and area as attributes, even if we don't allow them to be set except through changes to edges. Why should we force a user to remember what's a method and what's not, given edges, angles and area (could add perimeter too). OTOH, his general explanation for the use case of properties in respect to API design seemed to me to be a perfect defense of the extensive use of a pattern of: @property def getx(self): return self._x @porperty def sety(self,x) self._x =x because while now x is a normal attribute you never know what tomorrow may bring. And I say such defensive programming is unnecessary in Python. You can turn 'x' into a property later, and define new private variable '_x' behind it, if that's what you need to do. Plus there's no setter here, only a getter, so if you wanna go the whole nine yards you'll need to go a little further than above. OTOH, as you point out Alex did use exactly your case of the area of a Triangle to illustrate properties in Nutshell. Was he simply illustrating mechanics or, in so doing, advocating a use case as well? I don't know about advocating a use case. He's *presenting* a primitive use case in which making use of the property feature makes sense, is motivated by the circumstances. It's like showing how using the cork screw feature on a Swiss Army knife when you have this bottle of wine and nothing else handy to open it with. Does that mean I advocate drinking a lot of wine? Maybe, but that's not important here. 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. I think using __getattr__ is comparatively more trouble and maybe more trouble than it's worth. The property feature makes such code less cluttery, requires less hackery and I agree with you that this is in line with our definition of 'syntactic sugar': I think it's fine to call it syntactic sugar when we make object attributes call their associated accessors and mutators behind the scenes. (same post as linked above). And although I admire Scott's ability to use decorators in this context (a better idea than my using them to support differentiation ala calculus), I'm not myself motivated to use decorators in this way at this time. John and Dethe point out that when a color attribute in vpython is changed the proverbial e-mail to Mary needs to be sent - rerender. Before properties it was done under the covers, now we have the convenience of properties as an alternative. The unambiguous use case, IMO. I don't think the Triangle or Rectangle examples are any less ambiguous. Better to not have to install the whole VPython library just to find your first use case, which is implemented in C++ after all (even the color change part). But I do agree this is an unambiguous use case (one of many) -- John was being very apropos in bringing it up. John feels the appearance of properties in the language to be an unambiguous win. I would probably agree if I didn't believe it had the side effect of having some of us second-guessing the way they did business pre- properties. I guess I am pleading for constraint in the presentation of properties to novices, with clear *and narrow* use cases. I think that's fine. I generally agree with you that Java throws too much at the novice and gets her into habits of mind *without much justification* and this is unsatisfying to questioning minds. Python starts with *far* less clutter, but the real world rationale for properties (or wine and Swiss Army knives) hasn't gone away. They still turn out to be useful, as do other design patterns the Java books go on about. Its part of my campaign for this year's Willison award. I'm think my chances are 50/50, best case ;) Art Things we agree on: too much up front clutter is bad, Java has too much up front clutter, CS would do well to import math and geometry as grist for its mill, to illustrate new mechanics based on use cases. Plus I think kids learning math need more Swiss Army knives like Python. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
I think what I am trying to communicate is the fact that folks like me are not really interested in being: taught how to program Though we are anxious to be taught how to program What could be clearer? Art I think you've made it clear that you don't like to have a lot of unmotivated mechanics thrown at you because CS says you need them. Unless you've seen the use cases, and are directly motivated by them, you're not one to sit at the feet of CSers and just take their word for it. I like and support your question authority attitude. I think it's right for you to *not* take anything on faith alone. And CS shouldn't require you to. It's not that kind of discipline. You: That being said, I think in this particular thread about properties, the use cases were there from the beginning. What you came to after that was that it comes down to judgments and possible differences therein: We end up, as Laura says (I think), only able to make judgment calls as to what is and what is not appropriate as to what to expose and what not to expose, depending on what we are trying to accomplish. Judgment calls are to me a-theoretical. I think I understand the basic theory - and reserve to the right to do little more than take it under advisement. http://mail.python.org/pipermail/edu-sig/2005-August/005110.html I have no problem with any of the above. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] OTOH, his general explanation for the use case of properties in respect to API design seemed to me to be a perfect defense of the extensive use of a pattern of: @property def getx(self): return self._x @porperty def sety(self,x) self._x =x because while now x is a normal attribute you never know what tomorrow may bring. And I say such defensive programming is unnecessary in Python. You can turn 'x' into a property later Yes. John explains this as well. I told you I was confused. But I remain confused to the extent that this - from where I sit - rather obscure and remote situation comes up prominently as a reason properties are so welcome as a builtin function. As I don't think I sit anywhere *that* far off the mainstream of things. As an emergency fix - __getattr_ and __setattr__ would serve as well. As well as in also. As well as in as well as I guess is open to debate, but I keep thinking we are in obscure corner of things in any case - and having to get there as a use case for properties implies a stretch, and for me, is therefore a source of suspicion. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:edu-sig- [EMAIL PROTECTED] 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: Scott David Daniels wrote: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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 [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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
Re: [Edu-sig] quantum instance
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
Re: [Edu-sig] quantum instance
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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Scott David Daniels wrote: [EMAIL PROTECTED] 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
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=3934957tstart=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
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance?
Say, in the course of the manipulation of c its radius approaches towards infinity, and upon the radius becoming than some Max, I want c to suddenly think of itself as a Line instance rather than as a Circle instance. Footnote: In Fuller's synergetic geometry, circles don't become infinite lines, but just bigger and bigger circles. Lines that appear locally straight are just that: local. Clearly we're starting with different assumptions than those of Euclidean greek metaphysics. More from Democritus. Lines aren't perfectly straight either -- zoom in and they become zig-zaggy/wavilinear. Zoom out, and all you get are curves and great circles. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance?
Arthur wrote: Trying to handle the sudden change of state of an instance of an object - a quantum instance c starts as a Circle instance. Say, in the course of the manipulation of c its radius approaches towards infinity, and upon the radius becoming than some Max, I want c to suddenly think of itself as a Line instance rather than as a Circle instance. doable? hints? Art As a sketch: class Blended(object): MaxRadius = 123456 def __init__(self, radius): self._active = Circle(radius=radius) self._other = Line() self.radius = radius # Switch to Line if necessary def __getattr__(self, name): return getattr(self._active, name) def __setattr__(self, name, value): if name[0] == '_': object.__setattr__(self, name, value) elif name[0] != 'radius': return setattr(self, value) if value self.MaxRadius: if isinstance(self._active, Line): self._active, self._other = self._other, self._active else: if isinstance(self._active, Circle): self._active, self._other = self._other, self._active self._active.radius = value You could read up on __getattr__, __getattribute__, and friends in the Language References section 3.3.2: Customizing attribute access --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
