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 on
the fly is
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 on
the
-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 the
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 Scott
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, the
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
-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-sig
