Mailing List Archive: Python: Python

Clarity vs. code reuse/generality

1 2 3 4

View All

Index | Next | Previous | View Threaded

robert.kern at gmail

Jul 10, 2009, 9:57 AM

Post #76 of 85 (559 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

On 2009-07-10 11:50, J. Cliff Dyer wrote:
> On Fri, 2009-07-10 at 02:57 +0000, Steven D'Aprano wrote:
>> On Fri, 10 Jul 2009 03:28:04 +0100, Nobody wrote:
>>
>>> On Thu, 09 Jul 2009 04:57:15 -0300, Gabriel Genellina wrote:
>>>
>>>> Nobody says you shouldn't check your data. Only that "assert" is not
>>>> the right way to do that.
>>> "assert" is not the right way to check your *inputs*. It's a perfectly
>>> reasonable way to check data which "should" be valid, as well as a way
>>> to document what variables are supposed to contain.
>> Where are those variables coming from?
>>
>> The distinction really boils down to this:
>>
>> * asserts should never fail. If there is any chance that an assertion
>> might fail outside of test suites, then don't use assert.
>>
>
> I'm no expert, but the more I read this thread, and the more I think on
> it, the more I believe that asserts don't really need to exist outside
> of test suites.

Actually, there is a good argument that one shouldn't use an assert statement in
test suites: code can have bugs that only show up under -O so you want to be
able to run your test suite under -O.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

jcd at sdf

Jul 10, 2009, 11:56 AM

Post #77 of 85 (558 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

On Fri, 2009-07-10 at 11:57 -0500, Robert Kern wrote:
> On 2009-07-10 11:50, J. Cliff Dyer wrote:
> > On Fri, 2009-07-10 at 02:57 +0000, Steven D'Aprano wrote:
> >> On Fri, 10 Jul 2009 03:28:04 +0100, Nobody wrote:
> >>
> >>> On Thu, 09 Jul 2009 04:57:15 -0300, Gabriel Genellina wrote:
> >>>
> >>>> Nobody says you shouldn't check your data. Only that "assert" is not
> >>>> the right way to do that.
> >>> "assert" is not the right way to check your *inputs*. It's a perfectly
> >>> reasonable way to check data which "should" be valid, as well as a way
> >>> to document what variables are supposed to contain.
> >> Where are those variables coming from?
> >>
> >> The distinction really boils down to this:
> >>
> >> * asserts should never fail. If there is any chance that an assertion
> >> might fail outside of test suites, then don't use assert.
> >>
> >
> > I'm no expert, but the more I read this thread, and the more I think on
> > it, the more I believe that asserts don't really need to exist outside
> > of test suites.
>
> Actually, there is a good argument that one shouldn't use an assert statement in
> test suites: code can have bugs that only show up under -O so you want to be
> able to run your test suite under -O.
>

That's an interesting point. Presumably TestCase.assert_() doesn't
suffer from this defect? Otherwise the entire unittest suite is
essentially broken by your argument. I suppose I should have said one
should only raise AssertionErrors in test suites. Practically speaking,
that's what a test suite is: The place where you assert what the code
does.

--
http://mail.python.org/mailman/listinfo/python-list

robert.kern at gmail

Jul 10, 2009, 12:02 PM

Post #78 of 85 (562 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

On 2009-07-10 13:56, J. Cliff Dyer wrote:
> On Fri, 2009-07-10 at 11:57 -0500, Robert Kern wrote:
>> On 2009-07-10 11:50, J. Cliff Dyer wrote:
>>> On Fri, 2009-07-10 at 02:57 +0000, Steven D'Aprano wrote:
>>>> On Fri, 10 Jul 2009 03:28:04 +0100, Nobody wrote:
>>>>
>>>>> On Thu, 09 Jul 2009 04:57:15 -0300, Gabriel Genellina wrote:
>>>>>
>>>>>> Nobody says you shouldn't check your data. Only that "assert" is not
>>>>>> the right way to do that.
>>>>> "assert" is not the right way to check your *inputs*. It's a perfectly
>>>>> reasonable way to check data which "should" be valid, as well as a way
>>>>> to document what variables are supposed to contain.
>>>> Where are those variables coming from?
>>>>
>>>> The distinction really boils down to this:
>>>>
>>>> * asserts should never fail. If there is any chance that an assertion
>>>> might fail outside of test suites, then don't use assert.
>>>>
>>> I'm no expert, but the more I read this thread, and the more I think on
>>> it, the more I believe that asserts don't really need to exist outside
>>> of test suites.
>> Actually, there is a good argument that one shouldn't use an assert statement in
>> test suites: code can have bugs that only show up under -O so you want to be
>> able to run your test suite under -O.
>>
>
> That's an interesting point. Presumably TestCase.assert_() doesn't
> suffer from this defect? Otherwise the entire unittest suite is
> essentially broken by your argument.

It explicitly raises AssertionErrors. It does not use the assert statement.

> I suppose I should have said one
> should only raise AssertionErrors in test suites. Practically speaking,
> that's what a test suite is: The place where you assert what the code
> does.

Yup.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

ethan at stoneleaf

Jul 10, 2009, 3:11 PM

Post #79 of 85 (557 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

Steven D'Aprano wrote:
> On Mon, 06 Jul 2009 21:02:19 -0700, Aahz wrote:
>
>
>>In article <006e795f$0$9711$c3e8da3 [at] news>, Steven D'Aprano
>><steve [at] REMOVE-THIS-cybersource> wrote:
>>
>>>On Mon, 06 Jul 2009 14:32:10 +0200, Jean-Michel Pichavant wrote:
>>>
>>>>kj wrote:
>>>>
>>>>> sense = cmp(func(hi), func(lo))
>>>>> assert sense != 0, "func is not strictly monotonic in [lo, hi]"
>>>>
>>>>As already said before, unlike other languages, sense in english does
>>>>**not** mean direction. You should rewrite this part using a better
>>>>name. Wrong informations are far worse than no information at all.
>>>
>>>Absolutely.
>>>
>>
>>>From Webster's Dictionary:
>>
>>> 8. (Geom.) One of two opposite directions in which a line,
>>> surface, or volume, may be supposed to be described by the motion
>>> of a point, line, or surface.
>>> [1913 Webster]
>>>
>>>
>>>And from WordNet:
>>>
>>> 2: the meaning of a word or expression; the way in which a word
>>> or expression or situation can be interpreted
>>>
>>>Both meanings are relevant to the way KJ is using the word. Please take
>>>your own advice and stop giving wrong information. As a native English
>>>speaker, I had no difficulty understanding the meaning of "sense" in the
>>>sense intended by KJ.
>>
>>As another native English speaker, I agree with Jean-Michel; this is the
>>first time I've seen "sense" used to mean direction.
>
>
>
> Just goes to show you learn something new all the time.
>
> http://www.merriam-webster.com/dictionary/sense
>
> 7: one of two opposite directions especially of motion (as
> of a point, line, or surface)
>
>
> http://dictionary.reference.com/browse/sense
>
> 18. Mathematics. one of two opposite directions in which
> a vector may point.
>
>
>
> Paraphrasing the Collins Dictionary of Mathematics:
>
> The sense of a vector is the sign of the measure, contrasted with the
> magnitude. Thus the vectors AB and BA have the same direction but
> opposite sense. Sense is also used to distinguish clockwise and anti-
> clockwise.
>
> Sense is, if you like, a "signed direction". "Towards north" (say) as
> opposed to "along the north-south axis".
>

This also illustrates the importance of knowing your target audience. I
have also not seen "sense" used this way before, and from the placement
in the dictionaries I would venture to say it's not common usage outside
of mathematics and the sciences.

Of course, since kj is teaching biologists, odds are decent they know
what he's talking about.

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Jul 10, 2009, 9:01 PM

Post #80 of 85 (561 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

On Fri, 10 Jul 2009 12:27:25 -0400, Charles Yeomans wrote:

>> (3) assert is absolutely unsuitable for enforcing pre-conditions and
>> post-
>> conditions, unless such conditions are mere "guidelines", because
>> assert
>> can be switched off at runtime.
>
>
> Unless, of course, you want to switch off such checking at runtime, as
> you might when using a design-by-contract approach.

So is design-by-contract just another way of saying "let's hope the data
is valid, because if it's not, we're screwed"?

Perhaps Python should have a new statement, `assume`, used just like
`assert` except it never actually performs the test or raises an error.

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Jul 10, 2009, 10:04 PM

Post #81 of 85 (562 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

Steven D'Aprano wrote:
> On Fri, 10 Jul 2009 12:27:25 -0400, Charles Yeomans wrote:
>
>>> (3) assert is absolutely unsuitable for enforcing pre-conditions and
>>> post-
>>> conditions, unless such conditions are mere "guidelines", because
>>> assert
>>> can be switched off at runtime.
>>
>> Unless, of course, you want to switch off such checking at runtime, as
>> you might when using a design-by-contract approach.
>
> So is design-by-contract just another way of saying "let's hope the data
> is valid, because if it's not, we're screwed"?
>
> Perhaps Python should have a new statement, `assume`, used just like
> `assert` except it never actually performs the test or raises an error.

The manual says quite clearly

"The simple form, assert expression, is equivalent to
if __debug__:
if not expression: raise AssertionError"

It should be used when and only when one actually wants the double
condition check, and not as an abbreviation of the second conditional only.

tjr

--
http://mail.python.org/mailman/listinfo/python-list

digitig at gmail

Jul 11, 2009, 11:33 AM

Post #82 of 85 (559 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

2009/7/11 Steven D'Aprano <steve [at] remove-this-cybersource>:

> So is design-by-contract just another way of saying "let's hope the data
> is valid, because if it's not, we're screwed"?

Not at all. Design By Contract is about assigning responsibility for
checking. If you don't assign responsibility then a pile of things end
up getting checked over and over again, because everybody is assuming
responsibility, and some things don't get checked at all because
everyone assumes that somebody else is checking.

In DbC, the pre-condition on data coming in to a program from outside
will usually simply be "true" -- nothing at all is assumed about it.
But when you pass it from an input conditioning routine to a
processing routine, the input conditioning routine should be able to
make guarantees about what it passes, and the processing routine
should be able to assume that those guarantees are met without having
to check it again (after all, what was the conditioning routine there
for?). Assertions might be useful in testing (because they save having
to repeat the same set of test cases on absolutely every test run) and
they're certainly useful in documenting, but if they're any use at all
in the production run-time then there's something wrong with your
development and testing processes.

--
Tim Rowe
--
http://mail.python.org/mailman/listinfo/python-list

albert at spenarnc

Jul 16, 2009, 5:45 AM

Post #83 of 85 (499 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

In article <h2l36k$q5l$1 [at] reader1>, kj <no.email [at] please> wrote:
>
>
>I'm will be teaching a programming class to novices, and I've run
>into a clear conflict between two of the principles I'd like to
>teach: code clarity vs. code reuse. I'd love your opinion about
>it.
>
<SNIP>
>
>This seemed straightforward enough, until I realized that, to be
>useful to my students in their homework, this _binary_search function
>had to handle the case in which the passed function was monotonically
>decreasing in the specified interval...
>
<SNIP>
>
>Here's the rub: the code above is more general (hence more reusable)
>by virtue of this trick with the sense parameter, but it is also
>a bit harder to understand.
>
>This not an unusual situation. I find that the processing of
>abstracting out common logic often results in code that is harder
>to read, at least for the uninitiated...

Yes, of course. You're teaching, say, green belt programmers.
Good reusable code requires a fifth dan. You may not be up to it
yourself (no offense intended), let alone your students.

Writing a reusable binary search is a very different assignment
from being able to code/use it in a concrete example.

Their choice must be between *writing* a one-off binary search,
versus *using* a brilliantly code, brilliantly documented
binary search that has been given beforehand.

Even assuming the reusable code is perfect in all sense, reusing may
be more effort than writing from scratch.
Then *you* have to explain them about the benefits of reuse.
(The other benefits, of course.)

>
>I'd love to know your opinions on this.

You're welcome.

>kj

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert [at] sp&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--
http://mail.python.org/mailman/listinfo/python-list

albert at spenarnc

Jul 16, 2009, 6:15 AM

Post #84 of 85 (495 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

In article <mailman.2814.1247032175.8015.python-list [at] python>,
Dennis Lee Bieber <wlfraed [at] ix> wrote:
>On 07 Jul 2009 05:05:12 GMT, Steven D'Aprano
><steve [at] REMOVE-THIS-cybersource> declaimed the following in
>gmane.comp.python.general:
>
>> Paraphrasing the Collins Dictionary of Mathematics:
>>
>> opposite sense. Sense is also used to distinguish clockwise and anti-
>> clockwise.
>>
> Which, I believe, is the only usage I've encountered of it... In
>regards to quantum spin states in such things as Scientific American
>(though that magazine has either gone down hill in the last 30 years, or
>my expectations have gone up... Current issues read like the first years
>of Discover magazine)

I dropped my subscription when power was expressed in multiples
of US hair dryers. (I could calculate that back, and was appalled
by the energy wastage of US hair dryers. ;-) )

>--
> Wulfraed Dennis Lee Bieber KD6MOG

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert [at] sp&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--
http://mail.python.org/mailman/listinfo/python-list

albert at spenarnc

Jul 16, 2009, 6:19 AM

Post #85 of 85 (495 views)
Permalink

Re: Clarity vs. code reuse/generality [In reply to]

In article <CuH4m.3259$ze1.429 [at] news-server>,
Lie Ryan <lie.1296 [at] gmail> wrote:
>Steven D'Aprano wrote:
>> On Tue, 07 Jul 2009 05:13:28 +0000, Lie Ryan wrote:
>>
>>> When people are fighting over things like `sense`, although sense may
>>> not be strictly wrong dictionary-wise, it smells of something burning...
>>
>> That would be my patience.
>>
>> I can't believe the direction this discussion has taken.
>
>Me neither.
>
>> Anybody sensible
>> would be saying "Oh wow, I've just learned a new meaning to the word,
>> that's great, I'm now less ignorant than I was a minute ago". But oh no,
>> we mustn't use a standard meaning to a word, heaven forbid we disturb
>> people's ignorance by teaching them something new.
>
>A meaning of a word is meaningless if nobody apart the writer
>understands it. The purpose of code is 1) to communicate with the

Exactly. And the OP teaches to scientist. They know sense in that
meaning. Maybe you don't, but that is irrelevant.

<SNIP>

Groetjes Albert.

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert [at] sp&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--
http://mail.python.org/mailman/listinfo/python-list

1 2 3 4

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads