> 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
- 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&qu
> Speculating along those lines of course makes me an obnoxious bastard -
> but we already knew that.
>
> Art
>
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
> -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 int
On 19-Sep-05, at 9:26 AM, Kirby Urner wrote:
> 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.
I thought I had written an example using PyGame, but I don't see it
now. Perhaps it was when I was
On 18-Sep-05, at 1:44 PM, Kirby Urner wrote:
> You'd have to be on py-dev or be reading the PEPs to get a sense of
> what's
> in the pipeline (maybe you are -- I'm not at the moment, but from
> time to
> time dive into the PEPs). I mentioned after Europython about how
> yield, and
> hence
> 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
- 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
> 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
- 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 do
> >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 th
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
In a message of Mon, 19 Sep 2005 12:21:28 +0200, Laura Creighton wrote:
I just want to mention that I like properties. I think they make the
code easier to read. I've read too much code where people who
wanted the behaviour of properties got out __getattr__ and did
it wrong. Or decided that so
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?
>
>K
> -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:
>
> >
>
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 compel
> Whatever the hell it is.
>
> Art
>
As you wish.
However I'm going to resist the temptation (won't be suckered into?)
restating the rationale(s).
Sometimes "persuading Arthur" is just too much work -- and to what end?
Besides, your version of Python doesn't have these features, so what's
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 18, 2005 7:45 PM
> To: 'Arthur'; edu-sig@python.org
> Subject: RE: [Edu-sig] quantum instance
>
> > > Apparently many programmers felt this lack, includi
> > 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
>
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 18, 2005 4:44 PM
> To: 'Arthur'; edu-sig@python.org
> Subject: RE: [Edu-sig] quantum instance
>
> > My other problem is this:
> >
> > Did somebod
> 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
> My other problem is this:
>
> Did somebody forgot to mention to me, pre-Python2.2, that the language was
> missing a fundamental construct for the proper configuration of the proper
> API framework?
Apparently many programmers felt this lack, including Guido, and added the
missing capability.
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 18, 2005 11:41 AM
> To: 'Arthur'; edu-sig@python.org
>
> I'm glad I'm not confined to using your version of Python.
As I said, so am my.
I have my confidence scale. But as I've said previously
> -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 configur
> 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.
> -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 - work
> If verb, define a method, and capture the key arguments in a clear API.
>
Note:
Sometimes a verb might not imply arguments. E.g. myheart.beat() makes sense
as a verb if it's supposed to simulate a beat.
A rule of thumb might be: if it's a verb, it makes sense to do it over and
over, e.g
> 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 pro
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 17, 2005 7:41 PM
> To: 'Arthur'; edu-sig@python.org
> Subject: RE: [Edu-sig] quantum instance
>
>
> Let's not continue until we figure out why this i
> 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 o
Me >
>> Would we have flatted the area method before properties, through the
>> __getattr__ mechanism. Were properties put into the language to make it
>> more convenient for us to do this kind of thing - *as a way of
>> encouraging this kind of pattern*. I think you - implicated or
>> explicit
> -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):
> >
> 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
> > 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/
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 purp
> -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 c
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> > If you want to see me as a confused student - you're welcome.
> >
> > Art
>
> 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 prope
> 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
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 sy
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
> Arthur wrote:
> >... But I still don't see the connection to XP programming, API design
> Do you truly not understand my position, or merely disagree with it?
>
Let's say I don
> -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
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 probab
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.p
> -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
Hi All,
This has been an interesting and enlightening discussion. I have a bit
of knowledge of VPython internals, so I thought I'd jump in here.
Arthur wrote:
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>>Behalf Of Dethe Elza
>>As Guido has said, proper
> -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 us
On 13-Sep-05, at 7:22 PM, Arthur wrote:
> My argument though is with you, not Guido. It is about use cases for
> existing features, not about the features themselves. And in the
> particular case of properties, it was only in going back to Guido's
> own
> use case illustration that I begin to
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
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 fo
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,
>
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
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 ar
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 "
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
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 "math
[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
co
>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 Pytho
Kirby Urner wrote:
>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.
>
>
Yes. From a bitmap perspective, anyway.
And certainly circles, even from a vector computer graphics point of
view are actua
Kirby Urner wrote:
>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 Democ
> 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 in
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
>
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 a
62 matches
Mail list logo
