> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
> > If I am not violating the Uniform Access Principal how do we express on
> what
> > basis I am not?
>
> This to me has to do with the set of calls in your API.
Yes but accor
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
> My strongest reaction has
> to do with your wish to deny me the ability to make another choice
If that is a reference to my opinion about the visibility of the built-in
propert
Arthur wrote:
> I have a line segment - defined as the segment connecting 2 points. The
> interface allows the points to be picked and moved.
>
> The line segment has a length. I choose line.getLength() as my API
> Am I - in fact - violating the Uniform Access Principal.
> If I am, am I v
>In my MVC example, the Viewer expected a 'shape' object to support a
>specific API: verts and edges needed to be available as attributes.
Let me try to practice better what I think I am preaching and follow your
lead in making the discussion more concrete and less theoretical.
I have a line
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> "Information hiding" means sparing me the details. In an open source
> world,
> I might be able to see those details if I really cared about them. In the
> case of a private bank, fat chance.
Yes, we are at the core
> Separating these matters in an educational setting is more than
> problematic.
>
> Art
In an educational setting, I use analogies.
Think of interacting with a waiter in a restaurant. Your expectation is you
name the foods and drinks you want, and after a period of time, those items
arrive a
> -Original Message-
> From: Laura Creighton [mailto:[EMAIL PROTECTED]
>
> My guess is that you think that properties violate 'Explicit is better
> than implicit.'
Not exactly.
More like I think that it encourages "theory", and I appreciate Python as
a-a-theoretical.
The counter argum
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
>
> > Kirby seems comfortable in the Meyerist camp.
> >
>
> I think you might be reading something too sinister into "information
> hiding" and are therefore against it.
I did put a ;) after my comment on information hi
> -Original Message-
> From: Laura Creighton [mailto:[EMAIL PROTECTED]
> One nice thing about overwriting __getattr__ and __setattr__ is
> that when you are done you have something that fairly shrieks
> 'black magic here'. Properties look innocuous. Some people go quite
> nuts with the
In a message of Fri, 26 Aug 2005 18:24:33 EDT, Arthur writes:
>And am hoping he is quite wrong in the assessment that "information hiding"
>is a base requirement for information science. ;)
He is quite correct, but 'hiddenness' is not an infinite human good,
such as health. It is quite possible
> Kirby seems comfortable in the Meyerist camp.
>
I think you might be reading something too sinister into "information
hiding" and are therefore against it.
The brutal real world truth is the client wants an API that works today, but
will complain if it doesn't deliver tomorrow, even if specs s
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
>
> This is close to what I meant. I dislike properties that don't behave
> as if they were attributes.
Not exactly sure what that means.
Seems there is a lot to this topic.
Kirby Urner wrote:
>>So I find that rejecting it as naïve is fundamentally unresponsive.
>>Art
>
> However in this case I don't think your views were rejected as naïve. On
> the contrary, your views permeated a sophisticated discussion of use cases,
> and design patterns more generally (s'been a
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> I *enjoy* your exotic other-worldliness.
Other than what, I'm wondering ;)
Art
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-si
Hi Andre --
If you scroll back, you'll see I was specifying a triangle object in which
sides a,b,c were passed to a constructor, *and* could be respecified on the
fly, thereby changing the triangle. A validator made sure the proposed
triangle was legal (triangle inequality not violated). Other
Disclaimer: I haven't followed this thread as closely as I should.
Picking up on a few words from the discussion
(namely "triangle" and "properties").
When I think of a real life triangle, I can describe it
in terms of various "properties", such as: the length of
each of its three sides, its area
> So I don't feel as off topic or off base as perhaps I should.
>
> Apologies.
>
> Art
I don't feel you've been off topic or off base at all in this thread (nor
really that much in general). The considerations you have about properties
were worth raising.
My point is I don't think your contrib
> So I find that rejecting it as naïve is fundamentally unresponsive.
>
> Art
>
However in this case I don't think your views were rejected as naïve. On
the contrary, your views permeated a sophisticated discussion of use cases,
and design patterns more generally (s'been a rich thread) plus Sco
> -Original Message-
> From: Arthur [mailto:[EMAIL PROTECTED]
>
> So I find that rejecting it as naïve is fundamentally unresponsive.
Just to add -
I would feel my approach - no question - more misplaced most other places.
But think Guido's ability to retain a sense of naivety in th
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> You're welcome to your opinions. Sometimes you whine when it seems your
> opinions are taken for what they're worth though, which *sometimes* (not
> all
> the time) ain't much in my book.
We are in agreement. That is precisely when I whine.
Bu
> >I think use cases were described, and demonstrated, in which the property
> >feature made sense, e.g. we wanted an attributes-based API into our
> >triangle object, but sometimes the results were computed on the fly.
>
> And I notice that without the use of properties, that which is computed o
> Here's some code, which as yet doesn't actually make use of VPython -- but
> that's where it's going.
>
And here's where it (the code) went.
Very minimal, at this point but enough to get VPython actually doing
something with the triangle.
A student could start with this code and start add
> I might be a dead horse who is dead wrong, but the issue about how
> properties fit into Python is certainly not straightforward in the least,
> and responding as if it were is grossly unfair - to the question raised.
>
> Art
I think use cases were described, and demonstrated, in which the prop
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:edu-sig-
> [EMAIL PROTECTED] On Behalf Of Chuck Allison
> Sent: Tuesday, August 23, 2005 6:19 PM
> To: Kirby Urner
> Cc: edu-sig@python.org
> Subject: Re: [Edu-sig] Design patterns
>
> Hello Kirby,
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
> Arthur wrote:
> > ... more to my point is the fact that I don't expect my programming
> language
> > to solve the problem of decoupling my API from my code. Because I don't
> >
Chuck Allison wrote:
> My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html.
>
One thing I've always wanted to see if the class is small enough:
Groups shuffling other group's previous layers, and providing
feedback (but not grades) to the original group. It is
always
Arthur wrote:
> ... more to my point is the fact that I don't expect my programming language
> to solve the problem of decoupling my API from my code. Because I don't
> expect it to be a solvable problem.
I don't know if I'm beating a dead horse, but I don't claim properties
solves the problem of
Urner
>> Cc: 'Arthur'; 'Scott David Daniels'; edu-sig@python.org
>> Subject: Re[2]: [Edu-sig] Design patterns
>>
>> Hello Kirby,
>>
>> Since this discussion has swerved a little, I'd like to pose a query.
>> I've been using
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> They're not here to whine about not being mere "math notations" as if that
> would be an improvement.
That's one way to attempt to characterize my point - or Graham's point, for
that matter.
Except that it of course
> In his mind, (and I think in yours as well) computer languages are more
> like mathematical notation than a form of technology. And as such,
> evolution is slower - not at the pace of the changes in the underlying
> technology.
However I'm sometimes in the mood to not draw this line between
> -Original Message-
> From: Chuck Allison [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 22, 2005 12:43 PM
> To: Kirby Urner
> Cc: 'Arthur'; 'Scott David Daniels'; edu-sig@python.org
> Subject: Re[2]: [Edu-sig] Design patterns
>
> Hello Kir
- Original Message -
From: Scott David Daniels <[EMAIL PROTECTED]>
> If I wait until I have actual users, I can get
> real statistics on how the use the API. We decouple our work this
> way.
But in my look of it, properties are a "solution" to one of a nearly infinite
set
of these k
Chuck Allison wrote:
> Since this discussion has swerved a little, I'd like to pose a query.
> I've been using patterns since 1995 and am teaching a course starting
> Wednesday (a full semester course) on Design Patterns using the Heads
> First book. My query: do you have any ideas you might proffe
Arthur wrote:
> If I am understanding "properties" mostly correctly, and in fact their
> reason for being is to allow for a fundamental midstream redesign of a
> program without alteration of that program's API, I am thinking something to
> the effect that it is only possible to do the impossible i
>> I guess.
>>
>> Though I can't say I find there to be much consensus out there about what
>> language features truly make for robust software development from group
>> or community efforts.
>There's a long history of coders seeking consensus, but not arriving at any
>set in stone answers (no
Hello Kirby,
Since this discussion has swerved a little, I'd like to pose a query.
I've been using patterns since 1995 and am teaching a course starting
Wednesday (a full semester course) on Design Patterns using the Heads
First book. My query: do you have any ideas you might proffer for
programmi
> I guess.
>
> Though I can't say I find there to be much consensus out there about what
> language features truly make for robust software development from group or
> community efforts.
There's a long history of coders seeking consensus, but not arriving at any
set in stone answers (no carve
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
>
> A lot of these lessons about robust software development come from group
> or
> community efforts. Some aspects of Python maybe don't much excite you
> because you're primarily a solo coder (as am I much of the time)
> Why do I find this unsatisfying?
>
I think part of the picture is you're coding for yourself i.e. your APIs are
used internally by your own code. Refactoring *everything* is always a
possibility.
Suppose you'd already published a Triangle class API and then discovered you
needed more dynamism
> Though when we add another dimension, all tetras are projectively
> equivalent. Part of why I can't adjust to a focus on a tetra that happens
> to be regular in some way.
>
> Art
>
Well, another way of putting it is: all tetrahedra are the same regular
one, except not because of viewpoints.
Arthur wrote:
>
> As an API matter, I find myself liking the clue that "()" provides as to
> whether one is accessing something designed be determined dynamically.
In general I agree with that sentiment.
> I find myself leaning towards the option of making the use of properties go
> away in Py
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
>
> Good point about all triangles being equivalent given projection. In
> nailing down the angles, we've inadvertently defined a fourth vertex: the
> point of view. Given we're talking four vertices, we should maybe r
> PyGeo has a Triangle object, inherited from the Plane object. It exists
> mostly for drawing purposes, as the portion of the plane enclosed by the
> infinite lines connecting any 3 points. Since all Triangles are
> projectively equivalent, in the context of PyGeo there is little to be
> gained
> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> A weakness in the above design: we only check for violations of triangle
> inequality in the constructor, yet allow changes to a,b,c through the API.
Among my list of unsupportable theories is one to the effect that an
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
>
> I'd propose two reasons why properties are so successful.
>
> The first explanation comes from eXtreme Programming. One big goal of
> XP is to stop wasting time doing "big de
Scott:
> def writeprop(viewvar):
> '''decorator makes a property from access and a write method'''
> def view(self):
> return getattr(self, viewvar)
> def buildprop(writemethod):
> return property(view, writemethod)
> return buildprop
>
Pretty fancy Scott and
Arthur wrote:
>>What beyond sugar for leaving off a "()" when trying to retrieve a value
>>from a method are we accomplishing by using properties? I have tended to
>>look at properties mostly an accommodation to those coming from other
>>languages which have something similar, but never as somethi
Hi Arthur --
Yes, decorator syntax isn't designed to integrate with properties quite the
same way.
All a decorator does is run the subsequently defined function f2 through the
f1 in @f1, rebinding f2 to the returned output of f1. E.g. 'f2 = f1(f2)'
and '@f1; def f2(): pass' amount to the same
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Arthur
>
> What beyond sugar for leaving off a "()" when trying to retrieve a value
> from a method are we accomplishing by using properties? I have tended to
> look at properties mostly an accommoda
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott David Daniels
>
> Here's how to do the angles in 2.4 w/ properties:
>
>
> @property
> def A(self):
> return math.acos((-self.a**2 + self.b**2 + self.c**2)
>
> Now you can do:
>
> t = Triangle(3,4,5)
> t.c, math.degrees(t.C)
> t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C)
> t.b = t.c = 3
> t.c, math.degrees(t.C)
> t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C)
>
> This takes advantage of the fact that
Kirby Urner wrote:
> I’ve been thinking that a good way to introduce program design might involve
> objects of type Triangle, i.e. instances of the Triangle class.
> Anyway, here's a design question: do we want to compute the angles and
> store them as properties at the time of construction, i.e.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Kirby Urner
> Sent: Friday, August 19, 2005 8:30 PM
> To: edu-sig@python.org
> Subject: [Edu-sig] Design patterns
>
> Anyway, here's a design question: do we want to c
I’ve been thinking that a good way to introduce program design might involve
objects of type Triangle, i.e. instances of the Triangle class.
>>> mytri = Triangle(3,4,5)
>>> mytri.area
6.0
>>> mytri.C
90.0
Now isn’t it true that 3 sides uniquely determine a triangle *except* some
triangles have ha
54 matches
Mail list logo
