Re: Clarity vs. code reuse/generality

In article , Dennis Lee Bieber wrote: >On 07 Jul 2009 05:05:12 GMT, Steven D'Aprano > 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. >> >

Re: Clarity vs. code reuse/generality

In article , Lie Ryan wrote: >Steven D'Aprano wrote: >> On Tue, 07 Jul 2009 05:13:28 +, 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. >>

Re: Clarity vs. code reuse/generality

In article , kj 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. > > >This seemed straightforward enough, until I realized that, to

Re: Clarity vs. code reuse/generality

2009/7/11 Steven D'Aprano : > 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 ge

Re: Clarity vs. code reuse/generality

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

Re: Clarity vs. code reuse/generality

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 switc

Re: Clarity vs. code reuse/generality

Steven D'Aprano wrote: On Mon, 06 Jul 2009 21:02:19 -0700, Aahz wrote: In article <006e795f$0$9711$c3e8...@news.astraweb.com>, Steven D'Aprano 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, "fun

Re: Clarity vs. code reuse/generality

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 +, 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 Ge

Re: Clarity vs. code reuse/generality

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 +, 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: > >>> >

Re: Clarity vs. code reuse/generality

On 2009-07-10 11:50, J. Cliff Dyer wrote: On Fri, 2009-07-10 at 02:57 +, 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 wa

Re: Clarity vs. code reuse/generality

On Fri, 2009-07-10 at 02:57 +, 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. > > > > "a

Re: Clarity vs. code reuse/generality

On Jul 9, 2009, at 10:57 PM, 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 t

Re: Clarity vs. code reuse/generality

2009/7/9 kj : > Thanks for the encouragement. [snip] > into code.  And by this I mean not only assumptions about the > correctness of their code (the typical scope of assertions), but > also, more broadly, assumptions about the data that they are dealing > with (which often comes from external s

Re: Clarity vs. code reuse/generality

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"

Re: Clarity vs. code reuse/generality

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

Re: Clarity vs. code reuse/generality

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

Re: Clarity vs. code reuse/generality

kj wrote: My scientific code is jam-packed with assertions. I can't count the number of times that one such lowly assertion saved me from a silent but potentially disastrous bug. Now imagine that asserts had been disabled for that run... The issue is not "should you validate your inputs", t

Re: Clarity vs. code reuse/generality

En Wed, 08 Jul 2009 23:19:25 -0300, kj escribió: In Tim Rowe writes: 2009/7/4 kj : Precisely. =A0As I've stated elsewhere, this is an internal helper function, to be called only a few times under very well-specified conditions. =A0The assert statements checks that these conditions are

Re: Clarity vs. code reuse/generality

In Tim Rowe writes: >2009/7/4 kj : >> Precisely. =A0As I've stated elsewhere, this is an internal helper >> function, to be called only a few times under very well-specified >> conditions. =A0The assert statements checks that these conditions >> are as intended. =A0I.e. they are checks against

Re: Clarity vs. code reuse/generality

In Scott David Daniels writes: >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 >

Re: Clarity vs. code reuse/generality

In Martin Vilcans writes: >On Fri, Jul 3, 2009 at 4:05 PM, kj 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. =A0I'd love your opinion about >> it. >In general,

Re: Clarity vs. code reuse/generality

2009/7/7 Steven D'Aprano : > 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've done my share of code review and process audits, and assertions seem *far* to

Re: Clarity vs. code reuse/generality

On Jul 8, 2:24 am, Paul Rubin wrote: > pdpi writes: > >     while abs(func(guess) - target) > epsilon: > >         guess = (lo + hi) / 2. > >         if sense * func(guess) > sense * target: > >             hi = guess > >         elif sense * func(guess) < sense * ta

Re: Clarity vs. code reuse/generality

En Tue, 07 Jul 2009 09:51:10 -0300, Jean-Michel Pichavant escribió: 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 actua

Re: Clarity vs. code reuse/generality

pdpi writes: > while abs(func(guess) - target) > epsilon: > guess = (lo + hi) / 2. > if sense * func(guess) > sense * target: > hi = guess > elif sense * func(guess) < sense * target: > lo = guess > elif lo == hi: > return Non

Re: Clarity vs. code reuse/generality

On Jul 7, 8:04 pm, Dave Angel wrote: > And of course your clarified function will fail if the func is > monotonically decreasing. yeah, I eventually realized that and corrected it... And the assert()/ cmp() confusion too. I blame lack of sleep. The whole sign/sense thing left a really bad taste

Re: Clarity vs. code reuse/generality

pdpi wrote: On Jul 7, 2:16 am, Steven D'Aprano wrote: On Mon, 06 Jul 2009 16:43:43 +0100, Tim Rowe wrote: 2009/7/4 kj : 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 sta

Re: Clarity vs. code reuse/generality

On Jul 7, 7:31 pm, pdpi wrote: > On Jul 7, 7:06 pm, Paul Rubin wrote: > > > pdpi writes: > > > Personally, I think the code is an unreadable mess, but that's mostly > > > because of all the micro optimizations, not the generality of it. > > > Here's my unoptimized,

Re: Clarity vs. code reuse/generality

On Jul 7, 7:06 pm, Paul Rubin wrote: > pdpi writes: > > Personally, I think the code is an unreadable mess, but that's mostly > > because of all the micro optimizations, not the generality of it. > > Here's my unoptimized, but still equally generic, version: > > That

Re: Clarity vs. code reuse/generality

On Jul 7, 7:26 pm, Andre Engels wrote: > On Tue, Jul 7, 2009 at 8:01 PM, pdpi wrote: > > He asserts: > >    assert lo < hi > > but then compares: > >    sense = cmp(func(hi), func(lo)) > > > sense can't ever be anything other than 1. > > It can - there is no necessity that func is monotonically in

Re: Clarity vs. code reuse/generality

On Tue, Jul 7, 2009 at 8:01 PM, pdpi wrote: > He asserts: >    assert lo < hi > but then compares: >    sense = cmp(func(hi), func(lo)) > > sense can't ever be anything other than 1. It can - there is no necessity that func is monotonically increasing. -- André Engels, andreeng...@gmail.com --

Re: Clarity vs. code reuse/generality

pdpi writes: > Personally, I think the code is an unreadable mess, but that's mostly > because of all the micro optimizations, not the generality of it. > Here's my unoptimized, but still equally generic, version: That version doesn't use "sense" inside the binary search, i.e. it relies on the fu

Re: Clarity vs. code reuse/generality

On Jul 7, 2:16 am, Steven D'Aprano wrote: > On Mon, 06 Jul 2009 16:43:43 +0100, Tim Rowe wrote: > > 2009/7/4 kj : > > >> 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 c

Re: Clarity vs. code reuse/generality

On Tue, Jul 7, 2009 at 8:51 AM, Jean-Michel Pichavant wrote: > Steven D'Aprano wrote: >> >> On Tue, 07 Jul 2009 05:13:28 +, Lie Ryan wrote: >> >> >>> >>> When people are fighting over things like `sense`, although sense may >>> not be strictly wrong dictionary-wise, it smells of something burni

Re: Clarity vs. code reuse/generality

In article , Jean-Michel Pichavant wrote: > >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 i

Re: Clarity vs. code reuse/generality

Steven D'Aprano wrote: > On Tue, 07 Jul 2009 05:13:28 +, 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 thi

Re: Clarity vs. code reuse/generality

Steven D'Aprano wrote: On Tue, 07 Jul 2009 05:13:28 +, 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 disc

Re: Clarity vs. code reuse/generality

On Jul 7, 3:05 pm, Steven D'Aprano 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

Re: Clarity vs. code reuse/generality

On Tue, 07 Jul 2009 05:13:28 +, 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 sensi

Re: Clarity vs. code reuse/generality

Aahz wrote: > In article <006e795f$0$9711$c3e8...@news.astraweb.com>, > Steven D'Aprano 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

Re: Clarity vs. code reuse/generality

On Mon, 06 Jul 2009 21:02:19 -0700, Aahz wrote: > In article <006e795f$0$9711$c3e8...@news.astraweb.com>, Steven D'Aprano > 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 n

Re: Clarity vs. code reuse/generality

In article <006e795f$0$9711$c3e8...@news.astraweb.com>, Steven D'Aprano 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 b

Re: Clarity vs. code reuse/generality

On Mon, 06 Jul 2009 16:43:43 +0100, Tim Rowe wrote: > 2009/7/4 kj : > >> 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.

Re: Clarity vs. code reuse/generality

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 befo

Re: Clarity vs. code reuse/generality

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 y

Re: Clarity vs. code reuse/generality

2009/7/4 kj : > 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

Re: Clarity vs. code reuse/generality

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 th

Re: Clarity vs. code reuse/generality

Andre Engels wrote: On Mon, Jul 6, 2009 at 9:44 AM, Martin Vilcans wrote: On Fri, Jul 3, 2009 at 4:05 PM, kj 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 you

Re: Clarity vs. code reuse/generality

On Mon, Jul 6, 2009 at 9:44 AM, Martin Vilcans wrote: > On Fri, Jul 3, 2009 at 4:05 PM, kj 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 abo

Re: Clarity vs. code reuse/generality

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

Re: Clarity vs. code reuse/generality

kj wrote: > In <7x4otsux7f@ruckus.brouhaha.com> Paul Rubin > writes: > >> kj 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

Re: Clarity vs. code reuse/generality

On Fri, 03 Jul 2009 14:34:58 GMT, Alan G Isaac 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 yo

Re: Clarity vs. code reuse/generality

On Sat, Jul 4, 2009 at 18:01, Dennis Lee Bieber 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 san

Re: Clarity vs. code reuse/generality

On Sat, 04 Jul 2009 21:14:45 +, 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 bazilli

Re: Clarity vs. code reuse/generality

kj 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,

Re: Clarity vs. code reuse/generality

On Jul 4, 12:30 pm, kj wrote: > In "Pablo Torres N." > writes: > > > > >On Sat, Jul 4, 2009 at 10:05, kj 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 r

Re: Clarity vs. code reuse/generality

In MRAB writes: >Paul Rubin wrote: >> kj 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 occasi

Re: Clarity vs. code reuse/generality

In <7xzlbkti7z@ruckus.brouhaha.com> Paul Rubin writes: >kj 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 as

Re: Clarity vs. code reuse/generality

In <7x4otsux7f@ruckus.brouhaha.com> Paul Rubin writes: >kj 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

Re: Clarity vs. code reuse/generality

Scott David Daniels 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:

Re: Clarity vs. code reuse/generality

Paul Rubin wrote: Invalid input data is not considered impossible and doesn't imply a broken program, so assert statements are not the appropriate way to check for it. I like to use a function like def check(condition, msg="data error"): if not condition: raise ValueError, msg ...

Re: Clarity vs. code reuse/generality

On 7/4/2009 12:30 PM kj apparently wrote: > 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. Adopting such a view is of course an alternative to attempting to understand, but perhaps less usef

Re: Clarity vs. code reuse/generality

Paul Rubin wrote: kj 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, potentia

Re: Clarity vs. code reuse/generality

kj 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 > breakin

Re: Clarity vs. code reuse/generality

kj 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. > I regard the ver

Re: Clarity vs. code reuse/generality

In "Pablo Torres N." writes: >On Sat, Jul 4, 2009 at 10:05, kj wrote: >>>http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_s= >tmt >>>"The current code generator emits no code for an assert statement when op= >timization is requested at compile time." >> >> Sorry, this doe

Re: Clarity vs. code reuse/generality

On Sat, Jul 4, 2009 at 10:05, kj wrote: >>http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_stmt >>"The current code generator emits no code for an assert statement when >>optimization is requested at compile time." > > Sorry, this doesn't say anything like "don't use asserti

Re: Clarity vs. code reuse/generality

In Alan G Isaac writes: >> In Alan G Isaac >> writes: >>> 1. Don't use assertions to test argument values! >On 7/3/2009 12:19 PM kj apparently wrote: >> Out of curiosity, where does this come from? >http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_stmt >"The curre

Re: Clarity vs. code reuse/generality

In <7xk52p4tgg@ruckus.brouhaha.com> Paul Rubin writes: >kj writes: >> sense = cmp(func(hi), func(lo)) >> if sense == 0: >> return None >> target_plus = sense * target + epsilon >> target_minus = sense * target - epsilon >> ... >The

Re: Clarity vs. code reuse/generality

On Fri, Jul 3, 2009 at 09:05, kj wrote: > 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

Re: Clarity vs. code reuse/generality

Steven D'Aprano wrote: On Fri, 03 Jul 2009 16:19:22 +, kj wrote: In Alan G Isaac writes: 1. Don't use assertions to test argument values! Out of curiosity, where does this come from? Assertions are disabled when you run Python with the -O (optimise) flag. If you rely on assertions t

Re: Clarity vs. code reuse/generality

On Jul 3, 2009, at 2:03 PM, Steven D'Aprano wrote: On Fri, 03 Jul 2009 16:19:22 +, kj wrote: In Alan G Isaac writes: 1. Don't use assertions to test argument values! Out of curiosity, where does this come from? Assertions are disabled when you run Python with the -O (optimise) f

Re: Clarity vs. code reuse/generality

On Fri, 03 Jul 2009 16:19:22 +, kj wrote: > In Alan G Isaac > writes: > >>1. Don't use assertions to test argument values! > > Out of curiosity, where does this come from? Assertions are disabled when you run Python with the -O (optimise) flag. If you rely on assertions to verify data, t

Re: Clarity vs. code reuse/generality

> In Alan G Isaac > writes: >> 1. Don't use assertions to test argument values! On 7/3/2009 12:19 PM kj apparently wrote: > Out of curiosity, where does this come from? http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_stmt "The current code generator emits no code for

Re: Clarity vs. code reuse/generality

kj writes: > sense = cmp(func(hi), func(lo)) > if sense == 0: > return None > target_plus = sense * target + epsilon > target_minus = sense * target - epsilon > ... The code looks confusing to me and in some sense incorrect. Suppose func(hi)==func(lo)==target. In thi

Re: Clarity vs. code reuse/generality

In a...@pythoncraft.com (Aahz) writes: >First of all, cmp() is gone in Python 3, unfortunately, so I'd avoid >using it. Good to know. >Second, assuming I understand your code correctly, I'd change >"sense" to "direction" or "order". Thanks, kj -- http://mail.python.org/mailman/listinfo/pyth

Re: Clarity vs. code reuse/generality

In Alan G Isaac writes: >1. Don't use assertions to test argument values! Out of curiosity, where does this come from? Thanks, kj -- http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

kj 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. Sometimes when the decision between clarity and generality becomes too hard; you

Re: Clarity vs. code reuse/generality

kj 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. [...] sense = cmp(func(hi), func(lo)) if sense == 0: return None M

Re: Clarity vs. code reuse/generality

kj a écrit : 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 - others already commented on this code) Here's the rub: the code above is

Re: Clarity vs. code reuse/generality

On 3 Lug, 16:05, kj 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. They are both important principles, but clarity is usually more important because short code that

Re: Clarity vs. code reuse/generality

In article , kj wrote: > >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... > >def _binary_search(l

Re: Clarity vs. code reuse/generality

On 7/3/2009 10:05 AM kj apparently wrote: > 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-usab

Re: Clarity vs. code reuse/generality

On Fri, 03 Jul 2009 14:05:08 +, kj wrote: > ... I find that the processing of > abstracting out common logic often results in code that is harder to > read ... Yes. There is often a conflict between increasing abstraction and ease of understanding. [...] > The implementation is still very

Clarity vs. code reuse/generality

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