Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Subject: Re: Splitting of string at an interval
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Roy Smith <roy@panix.com>
In-Reply-To: <CAJ6cK1aWX3cPxFaHgqd=YJAJSmbA3b+mj4TYuEiW0cUCBtiabA@mail.gmail.com>
Date: Mon, 8 Apr 2013 11:37:28 -0400
Content-Transfer-Encoding: quoted-printable
References: <e66efa13-c35d-4169-b3cc-3617d3d6a8c7@googlegroups.com> <5161e996$0$29995$c3e8da3$5496439d@news.astraweb.com> <mailman.263.1365390121.3114.python-list@python.org> <roy-024D82.09215608042013@news.panix.com> <CAJ6cK1aWX3cPxFaHgqd=YJAJSmbA3b+mj4TYuEiW0cUCBtiabA@mail.gmail.com>
To: Arnaud Delobelle <arnodel@gmail.com>
Cc: Python <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.293.1365435457.3114.python-list@python.org>
Lines: 47
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:43081


On Apr 8, 2013, at 11:10 AM, Arnaud Delobelle wrote:

> On 8 April 2013 14:21, Roy Smith <roy@panix.com> wrote:
>=20
>> For a while, I was rabidly(*) into TDD (Test Driven Development).  =
The
>> cycle I was using was, "Write a specification of a behavior, write a
>> (failing) test for that behavior, then write the least possible =
amount
>> of code to make the test pass.  Lather, Rinse, Repeat, Ship"
>>=20
>> The "least possible" part is important.  It makes sure the cycles =
stay
>> short (ideally, just a few minutes), and that you don't write any =
code
>> for which you don't have tests.
>=20
> The least amount of code is often also not the best in terms of time
> or space complexity.  Does this mean you have to write tests for time
> and space complexity as well?  That's interesting, but I don't know of
> tools to help do that (time complexity seems easy enough, but space
> complexity seems tougher to me).


If space and time complexity are important, then you need to write a =
test for those things.  If you have no test for them, then it's not =
important and you shouldn't worry about it.  At least according to the =
TDD catechism :-)

=46rom a somewhat less radical point of view, the first thing you want =
to do is get the code to produce correct results.  Once you've got that =
(and a fully comprehensive test suite to prove it), then you can move on =
to making it more efficient, and your test suite serves as protection =
against behavior regressions.

And, yes, I agree that testing for time and space complexity are not =
trivial, because making accurate, repeatable, and isolated measurements =
of those things is often surprisingly complicated.  I can't help point =
out, however, that if your initial implementation is to have your code =
return a constant, it's pretty likely to be an optimum solution in both =
time and space :-)

---
Roy Smith
roy@panix.com