Mailing List Archive: Python: Python

Clarity vs. code reuse/generality

1 2 3 4

View All

Index | Next | Previous | View Threaded

http://phr.cx at NOSPAM

Jul 4, 2009, 1:55 PM

Post #26 of 85 (833 views)
Permalink

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

Scott David Daniels <Scott.Daniels [at] Acm> writes:
> And I curse such uses, since I don't get to see the troublesome value,
> or why it is troublesome. In the above case, y = sqrt(x) at least
> raises ValueError('math domain error'), which is more information than
> you are providing.
>
> How about:
> if x >= 0: raise ValueError('x = %r not allowed (negative)?' % x)

Better still in these situations is to throw to pdb.
But yes, you can put a formatted string in a check message.
--
http://mail.python.org/mailman/listinfo/python-list

no.email at please

Jul 4, 2009, 2:10 PM

Post #27 of 85 (835 views)
Permalink

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

In <7x4otsux7f.fsf [at] ruckus> Paul Rubin <http://phr.cx [at] NOSPAM> writes:

>kj <no.email [at] please> writes:
>> sense = cmp(func(hi), func(lo))
>> assert sense != 0, "func is not strictly monotonic in [lo, hi]"

>bisection search usually just requires the function to be continuous
>and to have its value cross the target somewhere between the endpoints,
>not be monotonic.

Try the algorithm I posted with lo = -pi/4, hi = 2*pi, func = cos,
target = -1, and see what you get...

>> I regard the very special case of func(hi)==func(lo)==target as
>> pathological (analogous to the fact that a stopped watch is "exactly
>> right" twice a day), and not one I care to support.

>I do think you should support that case, under the "do 'nothing'
>gracefully" principle.

You keep missing the point that this is an *internal* *helper*
*convenience* function, meant to abstract away common logic from
a handful of places and thus eliminate some code repetition within
a module. It is *not* a library function intended to be called
from elsewhere. So talk of "supporting" anything is besides the
point. Any internal use of this function that applies it to a
non-strictly-monotonic function is, by assumption, an error.

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

no.email at please

Jul 4, 2009, 2:13 PM

Post #28 of 85 (833 views)
Permalink

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

In <7xzlbkti7z.fsf [at] ruckus> Paul Rubin <http://phr.cx [at] NOSPAM> writes:

>kj <no.email [at] please> writes:
>> This implies that code that uses *any* assert statement (other than
>> perhaps the trivial and meaningless ones like "assert True") is
>> liable to break, because whatever it is that these assert statements
>> are checking "on some occasions, ... would go unchecked, potentially
>> breaking your code."

>Yes, that implication is absolutely valid. The purpose of assert
>statements is to debug the code, by checking for conditions that are
>supposed to be impossible.

Precisely. As I've stated elsewhere, this is an internal helper
function, to be called only a few times under very well-specified
conditions. The assert statements checks that these conditions
are as intended. I.e. they are checks against the module writer's
programming errors.
--
http://mail.python.org/mailman/listinfo/python-list

no.email at please

Jul 4, 2009, 2:14 PM

Post #29 of 85 (833 views)
Permalink

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

In <mailman.2621.1246733010.8015.python-list [at] python> MRAB <python [at] mrabarnett> writes:

>Paul Rubin wrote:
>> kj <no.email [at] please> writes:
>>> This implies that code that uses *any* assert statement (other than
>>> perhaps the trivial and meaningless ones like "assert True") is
>>> liable to break, because whatever it is that these assert statements
>>> are checking "on some occasions, ... would go unchecked, potentially
>>> breaking your code."
>>
>> Yes, that implication is absolutely valid. The purpose of assert
>> statements is to debug the code, by checking for conditions that are
>> supposed to be impossible. Unless the program is broken (i.e. the
>> impossible happened), no assert statement should ever trigger.
>>
>Technically these are known as "invariants". An assertion will always be
>True if the program is bug-free, no matter what the user might throw at
>it; it's not the same as validation.

What *user* are you talking about??? I've stated a bazillion times
that this function is meant to be called only from within this
module.

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

sajmikins at gmail

Jul 4, 2009, 3:22 PM

Post #30 of 85 (830 views)
Permalink

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

On Jul 4, 12:30�pm, kj <no.em...@please.post> wrote:
> In <mailman.2611.1246721197.8015.python-l...@python.org> "Pablo Torres N." <tn.pa...@gmail.com> writes:
>
>
>
> >On Sat, Jul 4, 2009 at 10:05, kj<no.em...@please.post> wrote:
> >>>http://docs.python.org/reference/simple_stmts.html#grammar-token-asse...
> >tmt
> >>>"The current code generator emits no code for an assert statement when op=
> >timization is requested at compile time."
>
> >> Sorry, this doesn't say anything like "don't use assertions to test
> >> argument values". =C2=A0I'm aware of the fact that assertions are silence=
> >d
> >> under certain circumstances. =C2=A0But where does the principle 1. in
> >> your first reply come from? =C2=A0I've never seen it before, and would
> >> like to understand the reasoning behind it.
>
> >> kj
> >> --
> >>http://mail.python.org/mailman/listinfo/python-list
>
> >But...if no code is generated for assertions on some occasions, then the
> >parameters would go unchecked, potentially breaking your code in said
> >occasions.
>
> This implies that code that uses *any* assert statement (other than
> perhaps the trivial and meaningless ones like "assert True") is
> liable to break, because whatever it is that these assert statements
> are checking "on some occasions, ... would go unchecked, potentially
> breaking your code."
>
> I'm beginning to think that the original "precept" was simply "cargo
> cult," i.e. one of those rules that are parroted without being
> fully understood.
>
> As I wrote in my original post, the function I posted was an internal
> ("helper") function, not to be used outside of the file. �This fact
> was further (ahem) underscored by the leading underscore in the
> function's name. �Under these circumstances, the assert statements
> seem to me perfectly in keeping with the intended use for them.
>
> kj

Assertions are for you, the programmer, to check that your
understanding of the code is correct (or not, i.e. if the assertion
fails.)

It's unfortunately not uncommon to see code where the assert statement
is used as an integral part of the processing, or, in other words,
where running the code with '-O' will cause changes in the way the it
runs.

In the code you posted, the assert statements seem to be checking that
other code/algorithms aren't (will never) pass that function "out of
bounds" arguments. Perfectly valid IMO. Since it's an internal
helper function you can (should) know that client code will /always/
call it with valid values, the asserts simply make your intuition or
knowledge explicit in a way that will show up dramatically if you're
wrong about that (i.e. if there's some problem elsewhere in the code
feeding that function.)

Assertions should never fail, which is why you can (or should be able
to without breaking your code) remove them entirely and know that your
program will run identically. That's why folks are quick to jump on
cases where assertions are used as control-flow constructs. (In your
function, however, they aren't.)

In a sense, assertions /are/ meaningless, except to the programmer.

FWIW, you can use "if __debug__:" and put anything you like in the
statement suite and the whole if statement goes away when run with '-
O'. Sort of a "super-assert".

Regards,
~Simon
--
http://mail.python.org/mailman/listinfo/python-list

http://phr.cx at NOSPAM

Jul 4, 2009, 3:24 PM

Post #31 of 85 (834 views)
Permalink

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

kj <no.email [at] please> writes:
> >bisection search usually just requires the function to be continuous
> >and to have its value cross the target somewhere between the endpoints,
> >not be monotonic.
>
> Try the algorithm I posted with lo = -pi/4, hi = 2*pi, func = cos,
> target = -1, and see what you get...

Sorry, my comment was poorly phrase. Bisection search usually is
phrased in terms of solving f(x)=0 where f is continuous and if the
initial endpoints are a and b, then f(a) and f(b) have opposite sign.

> You keep missing the point that this is an *internal* *helper*
> *convenience* function, ... Any internal use of this function that
> applies it to a non-strictly-monotonic function is, by assumption,
> an error.

In that case there are better algorithms you can use. But didn't this
thread start out asking what version of the code was best suited for
presentation to students? In that case, the function's preconditions
should be stated explicitly and not be narrower than necessary.
--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Jul 4, 2009, 6:27 PM

Post #32 of 85 (831 views)
Permalink

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

On Sat, 04 Jul 2009 21:14:45 +0000, kj wrote:

>>Technically these are known as "invariants". An assertion will always be
>>True if the program is bug-free, no matter what the user might throw at
>>it; it's not the same as validation.
>
> What *user* are you talking about??? I've stated a bazillion times that
> this function is meant to be called only from within this module.

In that case, you would be the user, and like any user, you might
accidentally call the function with invalid data.

I believe this discussion started because you are presenting this as code
for novices. In that case, it is absolutely important that you start off
by teaching them the Right Way to do things. As a general rule, the Right
Way is to do an explicit test and raise rather than use assert.

In production code, "internal use only" code is a grey area where assert
is sometimes justified (although I'll point out that in practice, code
written for internal use only has a habit of being called by others). But
you're not writing production code, you're writing *teaching code*, where
even more important than code correctness is user education.

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

tn.pablo at gmail

Jul 4, 2009, 9:26 PM

Post #33 of 85 (837 views)
Permalink

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

On Sat, Jul 4, 2009 at 18:01, Dennis Lee Bieber<wlfraed [at] ix> wrote:
> Do you really want to inflict novices with the subtleties of when
> "assert" is a proper structure to use?

I'll second that. This very thread is proof that assertions are polemic, so
maybe you (kj) should just save your student's sanity and stick to good old
conditionals :-)

As for your initial question, I think, thirty four emails after, that yes, your
function is a bit too clever and you should sacrifice some generality in order
to make it more readable.

--
Pablo Torres N.
--
http://mail.python.org/mailman/listinfo/python-list

a0046088 at airmail

Jul 5, 2009, 11:20 AM

Post #34 of 85 (801 views)
Permalink

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

On Fri, 03 Jul 2009 14:34:58 GMT, Alan G Isaac <alan.isaac [at] gmail>
wrote:

>On 7/3/2009 10:05 AM kj apparently wrote:

=== 8< ===

>2.
>from scipy.optimize import bisect
>def _binary_search(lo, hi, func, target, epsilon):
> def f(x): return func(x) - target
> return bisect(f, lo, high, xtol=epsilon)
>
>3. If you don't want to use SciPy (why?), have them
>implement http://en.wikipedia.org/wiki/Bisection_method#Pseudo-code
>to produce their own `bisect` function.

Of course this isn't really pseudo-code, it's VB code with quite poor
comments:

'Bisection Method

'Start loop
Do While (abs(right - left) > 2*epsilon)

'Calculate midpoint of domain
midpoint = (right + left) / 2

'Find f(midpoint)
If ((f(left) * f(midpoint)) > 0) Then
'Throw away left half
left = midpoint
Else
'Throw away right half
right = midpoint
End If
Loop
Return (right + left) / 2

and even just throwing away the VB code and leaving the comments does
not give a good algorithm:

'Bisection Method

'Start loop

'Calculate midpoint of domain

'Find f(midpoint)

'Throw away left half

'Throw away right half

A much better approach to teaching introductory programming in any
language at almost any level is to incorporate some "top down problem
solving", including writing a method of solution (algorithm) in some
reasonably well-defined pseudo-code that can be easily elaborated and
translated into one's target language (and, peferably, some
reasonable-sized subset of related languages). This pseudo-code should
then become comments (or equivalent) for the students to convert to
real code, as in:

Algorithm bisect (f, left, right, epsilon):

# Bisection Method to find a root of a real continuous function f(x):
# Assume f(x) changes sign between f(left) and f(right) and
# we want a value not further than epsilon from a real root.
# Begin with the domain left...right.

# While the absolute value of (left - right) exceeds 2*epsilon:

# Calculate the midpoint, mid, of the domain.

# If the product of f(left) and f(mid) is positive:

# Set left to mid;

# Otherwise:

# Set right to mid.

# Return the midpoint of left...right.

===
And adapting this approach to kj's case is straightforward.

Of course, what consitutes a suitable vocabulary and syntax for an
algorithm pseudo-code language depends upon the target language(s),
the tastes of the instructor, and the point in the lesson or course.
My choice is for python+COBOL (as above) initially, soon incorporating
the usual arithmetic and relational operators (and how soon and how
many at once depends upon the level of the students: for an
introductory university/college course in Computer Science or
equivalent, where everyone should have a reasonable background in
mathemtics notation as a prerequisite, this should be very soon and
quite fast), arrays and subscripting, etc.

But if we were to write this algorithm or kj's in python-like
pseudo-code it would already *be* python codeor very close to
it--which is why we should teach intorductory programming in python.
Very soon students would be writing algorithms that required very
little elaboration to be programs.

But without including suitable problem solving and psudo-code
algorithm writing there will soon come a time or an example where
students are trying to think in code instead of in their natural
language and don't have the experience and repertoire to be able to do
that well.

I hope that's not too pedantic or AR?

wayne

>hth,
>Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list

dns4 at cornell

Jul 5, 2009, 8:53 PM

Post #35 of 85 (794 views)
Permalink

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

kj wrote:
> In <7x4otsux7f.fsf [at] ruckus> Paul Rubin <http://phr.cx [at] NOSPAM> writes:
>
>> kj <no.email [at] please> writes:
>>> sense = cmp(func(hi), func(lo))
>>> assert sense != 0, "func is not strictly monotonic in [lo, hi]"
>
>> bisection search usually just requires the function to be continuous
>> and to have its value cross the target somewhere between the endpoints,
>> not be monotonic.
>
> Try the algorithm I posted with lo = -pi/4, hi = 2*pi, func = cos,
> target = -1, and see what you get...
>
>>> I regard the very special case of func(hi)==func(lo)==target as
>>> pathological (analogous to the fact that a stopped watch is "exactly
>>> right" twice a day), and not one I care to support.
>
>> I do think you should support that case, under the "do 'nothing'
>> gracefully" principle.
>
> You keep missing the point that this is an *internal* *helper*
> *convenience* function, meant to abstract away common logic from
> a handful of places and thus eliminate some code repetition within
> a module. It is *not* a library function intended to be called
> from elsewhere. So talk of "supporting" anything is besides the
> point. Any internal use of this function that applies it to a
> non-strictly-monotonic function is, by assumption, an error.
>
> kj

First, let me say *I got the point*. I use asserts, but only in unit
testing where I want to test the result of some action for correctness.
In the course of programming product code, I personally don't think
they should ever be used exactly for the reasons everyone else is
pointing out. They can be disabled with the -O option and that changes
the program's behavior in ways that could break in production.

If you insist on teaching the assert statement, teach it in the context
of writing unit testing code. Its an extremely valuable skill.

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

martin at librador

Jul 6, 2009, 12:44 AM

Post #36 of 85 (794 views)
Permalink

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

On Fri, Jul 3, 2009 at 4:05 PM, 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.

In general, code clarity is more important than reusability.
Unfortunately, many novice programmers have the opposite impression. I
have seen too much convoluted code written by beginners who try to
make the code generic. Writing simple, clear, to-the-point code is
hard enough as it is, even when not aiming at making it reusable.

If in the future you see an opportunity to reuse the code, then and
only then is the time to make it generic.

YAGNI is a wonderful principle.

--
martin [at] librador
http://www.librador.com
--
http://mail.python.org/mailman/listinfo/python-list

andreengels at gmail

Jul 6, 2009, 12:51 AM

Post #37 of 85 (788 views)
Permalink

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

On Mon, Jul 6, 2009 at 9:44 AM, Martin Vilcans<martin [at] librador> wrote:
> On Fri, Jul 3, 2009 at 4:05 PM, 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.
>
> In general, code clarity is more important than reusability.
> Unfortunately, many novice programmers have the opposite impression. I
> have seen too much convoluted code written by beginners who try to
> make the code generic. Writing simple, clear, to-the-point code is
> hard enough as it is, even when not aiming at making it reusable.
>
> If in the future you see an opportunity to reuse the code, then and
> only then is the time to make it generic.

Not just that, when you actually get to that point, making simple and
clear code generic is often easier than making
complicated-and-supposedly-generic code that little bit more generic
that you need.

--
André Engels, andreengels [at] gmail
--
http://mail.python.org/mailman/listinfo/python-list

jeanmichel at sequans

Jul 6, 2009, 5:32 AM

Post #38 of 85 (794 views)
Permalink

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

kj wrote:
> I've rewritten it like this:
>
> sense = cmp(func(hi), func(lo))
> assert sense != 0, "func is not strictly monotonic in [lo, hi]"
>
> Thanks for your feedback!
>
> kj
>

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.

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

Scott.Daniels at Acm

Jul 6, 2009, 5:33 AM

Post #39 of 85 (795 views)
Permalink

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

Andre Engels wrote:
> On Mon, Jul 6, 2009 at 9:44 AM, Martin Vilcans<martin [at] librador> wrote:
>> On Fri, Jul 3, 2009 at 4:05 PM, 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.
>> In general, code clarity is more important than reusability.
>> Unfortunately, many novice programmers have the opposite impression. I
>> have seen too much convoluted code written by beginners who try to
>> make the code generic. Writing simple, clear, to-the-point code is
>> hard enough as it is, even when not aiming at making it reusable.
>>
>> If in the future you see an opportunity to reuse the code, then and
>> only then is the time to make it generic.
>
> Not just that, when you actually get to that point, making simple and
> clear code generic is often easier than making
> complicated-and-supposedly-generic code that little bit more generic
> that you need.

First, a quote which took me a bit to find:
Thomas William Körner paraphrasing Polya and Svego
in A Companion to Analysis:
Recalling that 'once is a trick, twice is a method,
thrice is a theorem, and four times a theory,' we
seek to codify this insight.

Let us apply this insight:
Suppose in writing code, we pretty much go with that.
A method is something you notice, a theorem is a function, and
a theory is a generalized function.

Even though we like DRY ("don't repeat yourself") as a maxim, let
it go the first time and wait until you see the pattern (a possible
function). I'd go with a function first, a pair of functions, and
only then look to abstracting the function.

--Scott David Daniels
Scott.Daniels [at] Acm
--
http://mail.python.org/mailman/listinfo/python-list

digitig at gmail

Jul 6, 2009, 8:43 AM

Post #40 of 85 (775 views)
Permalink

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

2009/7/4 kj <no.email [at] please>:

> Precisely. �As I've stated elsewhere, this is an internal helper
> function, to be called only a few times under very well-specified
> conditions. �The assert statements checks that these conditions
> are as intended. �I.e. they are checks against the module writer's
> programming errors.

Good for you. I'm convinced that you have used the assertion
appropriately, and the fact that so many here are unable to see that
looks to me like a good case for teaching the right use of assertions.
For what it's worth, I read assertions at the beginning of a procedure
as part of the specification of the procedure, and I use them there in
order to document the procedure. An assertion in that position is for
me a statement to the user of the procedure "it's your responsibility
to make sure that you never call this procedure in such a way as to
violate these conditions". They're part of a contract, as somebody
(maybe you) pointed out.

As somebody who works in the safety-critical domain, it's refreshing
to see somebody teaching students to think about the circumstances in
which a procedure can legitimately be called. The hostility you've
received to that idea is saddening, and indicative of why there's so
much buggy software out there.
--
Tim Rowe
--
http://mail.python.org/mailman/listinfo/python-list

jdnier at gmail

Jul 6, 2009, 11:52 AM

Post #41 of 85 (778 views)
Permalink

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

I remember in college taking an intro programming class (C++) where
the professor started us off writing a program to factor polynomials;
he probably also incorporated binary search into an assignment. But
people don't generally use Python to implement binary search or factor
polynomials so maybe you should start with a problem more germane to
typical novice users (and less algorithm-y). Wouldn't starting them
off with string processing or simple calculations be a practical way
to get comfortable with the language?

--David

On Jul 3, 9:05�am, kj <no.em...@please.post> 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.
>
> The context is the concept of a binary search. �In one of their
> homeworks, my students will have two occasions to use a binary
> search. �This seemed like a perfect opportunity to illustrate the
> idea of abstracting commonalities of code into a re-usable function.
> So I thought that I'd code a helper function, called _binary_search,
> that took five parameters: a lower limit, an upper limit, a
> one-parameter function, a target value, and a tolerance (epsilon).
> It returns the value of the parameter for which the value of the
> passed function is within the tolerance of the target value.
>
> 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...
>
> The implementation is still very simple, but maybe not very clear,
> particularly to programming novices (docstring omitted):
>
> def _binary_search(lo, hi, func, target, epsilon):
> � � assert lo < hi
> � � assert epsilon > 0
> � � sense = cmp(func(hi), func(lo))
> � � if sense == 0:
> � � � � return None
> � � target_plus = sense * target + epsilon
> � � target_minus = sense * target - epsilon
> � � while True:
> � � � � param = (lo + hi) * 0.5
> � � � � value = sense * func(param)
> � � � � if value > target_plus:
> � � � � � � hi = param
> � � � � elif value < target_minus:
> � � � � � � lo = param
> � � � � else:
> � � � � � � return param
>
> � � � � if lo == hi:
> � � � � � � return None
>
> My question is: is the business with sense and cmp too "clever"?
>
> 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...
>
> I'd love to know your opinions on this.
>
> TIA!
>
> kj

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

steve at REMOVE-THIS-cybersource

Jul 6, 2009, 6:01 PM

Post #42 of 85 (751 views)
Permalink

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

On Mon, 06 Jul 2009 14:32:10 +0200, Jean-Michel Pichavant wrote:

> kj wrote:
>> I've rewritten it like this:
>>
>> sense = cmp(func(hi), func(lo))
>> assert sense != 0, "func is not strictly monotonic in [lo, hi]"
>>
>> Thanks for your feedback!
>>
>> kj
>>
>>
> 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.

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

steve at REMOVE-THIS-cybersource

Jul 6, 2009, 6:16 PM

Post #43 of 85 (753 views)
Permalink

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

On Mon, 06 Jul 2009 16:43:43 +0100, Tim Rowe wrote:

> 2009/7/4 kj <no.email [at] please>:
>
>> Precisely. As I've stated elsewhere, this is an internal helper
>> function, to be called only a few times under very well-specified
>> conditions. The assert statements checks that these conditions are as
>> intended. I.e. they are checks against the module writer's programming
>> errors.
>
> Good for you. I'm convinced that you have used the assertion
> appropriately, and the fact that so many here are unable to see that
> looks to me like a good case for teaching the right use of assertions.
> For what it's worth, I read assertions at the beginning of a procedure
> as part of the specification of the procedure, and I use them there in
> order to document the procedure. An assertion in that position is for me
> a statement to the user of the procedure "it's your responsibility to
> make sure that you never call this procedure in such a way as to violate
> these conditions". They're part of a contract, as somebody (maybe you)
> pointed out.
>
> As somebody who works in the safety-critical domain, it's refreshing to
> see somebody teaching students to think about the circumstances in which
> a procedure can legitimately be called. The hostility you've received to
> that idea is saddening, and indicative of why there's so much buggy
> software out there.

LOL.

Maybe the reason for "so much buggy software" is that people
inappropriately use assert, thus changing the behaviour of code depending
on whether it is run with the -O flag or not.

I don't know what "hostility" you're seeing. The only hostility I'm
seeing is from the OP, which is bizarre considering that he asked for
advice and we gave it. What I see is a bunch of people concerned that the
OP is teaching novices a bad habit, namely, using assert for error
checking. He claims -- angrily and over and over again -- that in his
code, the assertions should never fail. Great. Good for him for knowing
when to use assert. But are the novices going to learn that lesson, or
will they simply learn "use assert for error checking"?

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

aahz at pythoncraft

Jul 6, 2009, 9:02 PM

Post #44 of 85 (750 views)
Permalink

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

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.
--
Aahz (aahz [at] pythoncraft) <*> http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha
--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Jul 6, 2009, 10:05 PM

Post #45 of 85 (746 views)
Permalink

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

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".

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

lie.1296 at gmail

Jul 6, 2009, 10:13 PM

Post #46 of 85 (746 views)
Permalink

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

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.

When people are fighting over things like `sense`, although sense may
not be strictly wrong dictionary-wise, it smells of something burning...
--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Jul 6, 2009, 10:57 PM

Post #47 of 85 (740 views)
Permalink

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

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. 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.

It's as simple as this: using `sense` as a variable name to record the
sense of a function is not a code smell, any more than using `flag` to
record a flag would be, or `sign` to record the sign of an object. If you
don't know the appropriate meanings of the words sense, flag or sign,
learn them, don't dumb down my language.

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

afriere at yahoo

Jul 7, 2009, 1:48 AM

Post #48 of 85 (733 views)
Permalink

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

On Jul 7, 3:05�pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

[snip]

> Sense is, if you like, a "signed direction".

Or to put it another way, in the graphical representation of a vector,
'direction' is the line, 'sense' is the arrowhead.
--
http://mail.python.org/mailman/listinfo/python-list

lie.1296 at gmail

Jul 7, 2009, 5:48 AM

Post #49 of 85 (742 views)
Permalink

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

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
computer, 2) to communicate with fellow programmer. The second point is
especially important if the code are written for pedantic purpose.
Teaching is largely one-way communication and often students that does
not understand about a slight point could not or would not communicate
their feelings because they think it is too silly. If the use of word is
criticized on a two-way communication channel (e.g. newsgroup), it
should raise a question of whether the word should be described first or
whether a synonym would be more suitable for the purpose. Most of these
do not apply on practical, non-pedantic purpose though, since in
non-pedantic settings you are expected to know and use the jargons
however (in)sensible they may be at first sight.

> It's as simple as this: using `sense` as a variable name to record the
> sense of a function is not a code smell, any more than using `flag` to
> record a flag would be, or `sign` to record the sign of an object.

Nobody said code smell... linguistic smell is more appropriate.

> If you
> don't know the appropriate meanings of the words sense, flag or sign,
> learn them, don't dumb down my language.
--
http://mail.python.org/mailman/listinfo/python-list

jeanmichel at sequans

Jul 7, 2009, 5:51 AM

Post #50 of 85 (741 views)
Permalink

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

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. 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.
>
> It's as simple as this: using `sense` as a variable name to record the
> sense of a function is not a code smell, any more than using `flag` to
> record a flag would be, or `sign` to record the sign of an object. If you
> don't know the appropriate meanings of the words sense, flag or sign,
> learn them, don't dumb down my language.
>
>

Can't we just calm down ? I'm really sorry my ignorance started this
thread, and my apologies go to Kj who's obviously more fluent in english
than me.
I've never used sense in that way before, nor I've seen used by others
until now. However Kj is right, and my dictionary seems wrong
(wordreference.com). I've searched through others dictionaries and find
out this is actually applicable to functions. My bad.

JM
--
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