Re: Testing dynamic languages
In article <641a30b8-c659-4212-9f31-b9eb401ad...@r37g2000yqn.googlegroups.com>, barisa wrote: >On Apr 4, 9:57=A0pm, bearophileh...@lycos.com wrote: > >> that. Don't fight the language. Use doctests). My other suggestion is >> to read code coming from 5+ Python programs written by other >> (different) people. You will see how to use Python. >> bearophile > >Is there some online repository for such code? Start with Lib/ in the source ;-) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz -- http://mail.python.org/mailman/listinfo/python-list
RE: Testing dynamic languages
Plenty. Try github.com for starters. -Original Message- From: python-list-bounces+nick=stinemates@python.org [mailto:python-list-bounces+nick=stinemates@python.org] On Behalf Of barisa Sent: Sunday, April 05, 2009 10:22 AM To: python-list@python.org Subject: Re: Testing dynamic languages On Apr 4, 9:57 pm, bearophileh...@lycos.com wrote: > that. Don't fight the language. Use doctests). My other suggestion is > to read code coming from 5+ Python programs written by other > (different) people. You will see how to use Python. > > Bye, > bearophile Is there some online repository for such code? :) Regards Begginer -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Apr 4, 9:57 pm, bearophileh...@lycos.com wrote: > that. Don't fight the language. Use doctests). My other suggestion is > to read code coming from 5+ Python programs written by other > (different) people. You will see how to use Python. > > Bye, > bearophile Is there some online repository for such code? :) Regards Begginer -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
grkunt...:
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
Others have already given you most of the answers (summary: don't do
that. Don't fight the language. Use doctests). My other suggestion is
to read code coming from 5+ Python programs written by other
(different) people. You will see how to use Python.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
This may be obvious but, clearly there are (at least) two general types of errors: those caused by data external to the program and those caused by bugs in the program. For all inputs coming into the program from outside, such as user inputs and data coming over a network, the inputs must be completely checked -- always assume that they will be incorrect and are intended to crash your code -- be pleasantly surprised when they are not :-). Check for all bad inputs. If the data are from inside the program, the assumption may be that they are good and if not, it was a bug. I suppose you can write unit tests on each routine to see that the methods that routine calls are with valid arguments (using mocks). I actually tried this in a Java program using JMockit; it was tedious, but it did catch a few "potential" bugs. I would love to say that I ALWAYS remember the input and output condition of every subroutine I write, but I just finished a new feature for a company project that involved 100+ routines and classes and I admit that I don't always remember which ones can return null and which always return empty arrays, for example, even though I try to write JavaDocs at the top of each routine. By mocking these routines, I can check that the caller always handles each case gracefully. -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Sat, 2009-04-04 at 06:37 -0700, grkunt...@gmail.com wrote:
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
At some point you should wrap it in a try/except block - but only at the
point where you want the exception to be handled. That will normally be
quite far up, and you'll just let the exception travel back up to that
point.
for example, in a web server type of thing you might have something
vaguely like
def main:
for request in request_itter:
try:
headers = request.get_headers()
dispatch = get_dispatch_fn(headers)
response = dispatch(response)
except:
send_500()
You probably then don't need to catch any exceptions in the get_headers,
or actual processing methods (unless you are writing to sql or
something, when you might want to wrap all statements in a try block,
and then put a "ROLLBACK;" query in the except block (and then raise the
caught exception so it goes back the the block above)
>
> Is this the experience that Python programmer (of large projects) see?
> Do you also write unit tests to confirm that the methods actually
> check for and catch "bad" parameter types? If I am writing small one-
> off scripts, I wouldn't worry about it, but if I am writing a large
> system that must have 99+% uptime without constant monitoring, this
> really should be verified.
I write large applications with a target of 99.9% uptime, and I don't
find it a problem. occasionally I have to check parameters, but that's
not very often
>
> Up for discussion...
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Sat, 04 Apr 2009 07:37:44 -0700, grkuntzmd wrote:
> I am a Java developer. There, I said it :-).
>
> When I am writing code, I can rely on the compiler to confirm that
> any methods I write will be called with parameters of the "right"
> type. I do not need to test that parameter #1 really is a String
> before I call some method on it that only works on Strings.
>
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
>
> Is this the experience that Python programmer (of large projects) see?
> Do you also write unit tests to confirm that the methods actually
> check for and catch "bad" parameter types? If I am writing small one-
> off scripts, I wouldn't worry about it, but if I am writing a large
> system that must have 99+% uptime without constant monitoring, this
> really should be verified.
>
> Up for discussion...
Uhm.
I write large bodies of code for living ... not in Python, unfortunately.
I usually divide my code in two classes wrt sanity checks : inner code and
boundary code. Boundary code gets paranoic checks on everything:
arguments, consistency etc ... also with static typing : an 'int'
parameter declaration in C/C++ make sure that your function gets an
integer, but ensure nothing in the way of minimum and maximum value, so
before using it - say - as an array index, it is better to check
that. Inner code gets less checks, based on the assumptions that inputs
have been properly checked by the boundary functions.
This method is not without risks - an architectural change can move a
function from an inner zone to a boundary zone, and I may forget to
'fortify' the function. However, this is a guideline that served me well.
Beside that there is another guideline I apply to languages like java and
python - programs in these languages do not 'crash' ... they throw
exceptions. Now, supposing to add an input check : what are you
going to do if you find bad data? In the answer is - as often the case -
throw an exception, then maybe the check is not worth much ...
There are exceptions to this guideline, as always, like if you want to
generate a more meaningful exception, but this is another guideline I
tend to follow. And this means that my level of checking in python is
much lower than in - say - C++. And I don't worry too much about argument
types, more about external inputs with the right 'semantic'.
The one coding behaviour that dynamic types forced me to change, is that
now I tend to build programs more incrementally, because catching typos
error and logic errors at the same time on a large body of code can be
frustrating and not very productive ... but I find myself to use now the
same approach also when I code in statically typed languages : a bit
slower at beginning, but tend to procuce more reliable results .
Ciao
FB
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Apr 4, 11:17 am, Emmanuel Surleau wrote: > On Saturday 04 April 2009 15:37:44 grkunt...@gmail.com wrote: > > > I am a Java developer. There, I said it :-). Don't worry. I also do terrible things to support my family... -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
andrew cooke wrote: > if you are going to do that, stay with java. seriously - i too, am a java > developer about half the time, and you can make java pretty dynamic if you > try hard enough. look at exploiting aspects and functional programming > libraries, for example. also, of course, scala. andrew -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Saturday 04 April 2009 15:37:44 grkunt...@gmail.com wrote:
> I am a Java developer. There, I said it :-).
>
> When I am writing code, I can rely on the compiler to confirm that
> any methods I write will be called with parameters of the "right"
> type. I do not need to test that parameter #1 really is a String
> before I call some method on it that only works on Strings.
>
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
Well, it depends on what you're trying to do, really. You do *not* want to
check parameters in every function. If you are designing a library, it is
strongly advised to document what kind of parameters your functions
expect. Otherwise, if your program will handle arbitrary input, you should
check its format and reject it if it's invalid.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
grkunt...@gmail.com wrote:
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
>
> Is this the experience that Python programmer (of large projects) see?
> Do you also write unit tests to confirm that the methods actually
> check for and catch "bad" parameter types? If I am writing small one-
> off scripts, I wouldn't worry about it, but if I am writing a large
> system that must have 99+% uptime without constant monitoring, this
> really should be verified.
if you are going to do that, stay with java. seriously - i too, am a java
developer about half the time, and you can make java pretty dynamic if you
try hard enough. look at exploiting aspects and functional programming
libraries, for example.
the standard solution to what you describe (which is itself a standard
problem with dynamic languages) is unit testing. proponents of dynamic
languages argue that you need to do testing anyway for its other
advantages. proponents of statically typed languages argue that you need
to write more. the best solution is probably to use a better language
(like ocaml or even haskell) (and i am only half joking).
asserting types isn't really going to work once you start exploiting just
what python can do (although look at abstract base classes - abcs - which
make things easier).
personally, i find that i write slightly more tests in python than java
and that my python code is, to be honest, slightly less reliable. i also
add type assertions at critical points when refactoring (but otherwise
not).
so in summary:
- yes it's an issue
- solve it with more unit testing, not type assertions
- use the right tool for the job (which might be java)
all the above just my experience. i tend to use java for the server side
and python for getting data into the database, so each plays to its
strengths.
andrew
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
grkunt...@gmail.com wrote:
If I am writing in Python, since it is dynamically, but strongly
typed, I really should check that each parameter is of the expected
type, or at least can respond to the method I plan on calling ("duck"
typing). Every call should be wrapped in a try/except statement to
prevent the method (and program) from crashing when my method is
called with an integer instead of the expected string.
Logically speaking, you only need one try/except at the very top of the
program if you only want to catch these things, but that would be a
really, really, really bad advice.
I wonder if it wouldn't be better to design the program in such a way
that the original input is handled in a way that it doesn't conflict
with what you want to do with.
m2c
--
mph
--
http://mail.python.org/mailman/listinfo/python-list
