Op Sunday 3 May 2015 12:21 CEST schreef Mark Lawrence:
>> That looks very promising. But I use the test to verify the
>> correctness and show the performance. Is that also possible? Or
>> should I split those out.
>>
>
> Get it working correctly and if it's fast enough for your needs then
> job do
On 03/05/2015 10:49, Cecil Westerhof wrote:
Op Sunday 3 May 2015 10:45 CEST schreef Peter Otten:
Cecil Westerhof wrote:
Another question. Is it acceptable to have it in the module itself,
or should I put it in something like test_.py? The code for
testing is bigger as the code for the impleme
Op Sunday 3 May 2015 10:45 CEST schreef Peter Otten:
> Cecil Westerhof wrote:
>
>> Another question. Is it acceptable to have it in the module itself,
>> or should I put it in something like test_.py? The code for
>> testing is bigger as the code for the implementation, so I am
>> leaning to putti
Terry Reedy wrote:
> On 5/2/2015 6:29 PM, Cecil Westerhof wrote:
>
>> At the moment I define the test functionality in the following way:
>
> Any automated testing is better than none. For idlelib, I use unittest.
> For an individual project with specialized needs, I use a custom test
> frame
Peter Otten <__pete...@web.de> writes:
> Be aware that there is also doctest which scans docstrings for text
> resembling interactive Python sessions. Doctests are both tests and
> usage examples, so I think it's good to put a few of these into the
> module.
Yes, it's definitely a good idea to pu
Cecil Westerhof wrote:
> Another question. Is it acceptable to have it in the module itself, or
> should I put it in something like test_.py? The code for
> testing is bigger as the code for the implementation, so I am leaning
> to putting it in a separate file.
Definitely use an established test
On 03/05/2015 08:36, Cecil Westerhof wrote:
Thanks for the tips. For most I have to read a ‘little’ first, so I
will not implement them immediately.
Another question. Is it acceptable to have it in the module itself, or
should I put it in something like test_.py? The code for
testing is bigger a
Op Sunday 3 May 2015 00:29 CEST schreef Cecil Westerhof:
> Still on my journey to learn Python.
>
> At the moment I define the test functionality in the following way:
> if __name__ == '__main__':
> keywords= [
> 'all',
> 'factorial',
> 'fibonacci',
> 'happy',
> 'lucky',
> ]
> keywords_msg
Paul Rubin writes:
> Cecil Westerhof writes:
>
> > action = options[0][0]
> > if action == '--all': ...
>
> Yecch, use an option parsing library for that, whichever one is
> currently fashionable. I think optparse is deprecated now but I still
> use it because I'm used
Cecil Westerhof writes:
> Still on my journey to learn Python.
>
> At the moment I define the test functionality in the following way:
> action = options[0][0]
> if action == '--all': ...
Yecch, use an option parsing library for that, whichever one is
currently fashiona
On 5/2/2015 6:29 PM, Cecil Westerhof wrote:
At the moment I define the test functionality in the following way:
Any automated testing is better than none. For idlelib, I use unittest.
For an individual project with specialized needs, I use a custom test
framework tuned to those needs.
On 02/05/2015 23:29, Cecil Westerhof wrote:
Still on my journey to learn Python.
At the moment I define the test functionality in the following way:
if __name__ == '__main__':
keywords= [
'all',
'factorial',
'fibonacci',
'
12 matches
Mail list logo
