the tests
Fabian
I'm back after a week of back-to-works frustration! :)
I checked the tests and deemed them in need of a rewrite.
Actually there are no tests in the sense that a the unittest framework
would be used, or any output be asserted against expectations. I will
rewrite the whole directory to that end, OK?
That raises the question what this "tracer" is. Is it only a
convenience that makes testing and checking process parameters
possible, or does it have any actual meaning for the CSP-runtime?
At last, I want to ask for better naming.
Though I don't understand much about CSP, it seems that you're both
(python-csp and PyCSP) rewrite some Java framework and reuse their bad
naming?
Anyways, names like "Alt" and the following "alting" verb is a good
example (look at the docs):
You explain it with a "select" - which to every programmer says what
it does. But it's called "alternate" which in a mathematical sense is
in general plain wrong.
So why not call it "select" instead?
Also I encountered "Par" and "Seq". Though it's terribly convenient to
write only three letters, it doesn't really say anything to newcomers.
At worst it even brings them on the wrong track, as Par has nothing to
do with Parity and Seq nothing with a sequence of numbers.
I'm always a fan of writing the whole word, so what about "Parallel"
and "Sequential"?
Bye, Fabian
snim2
> Hi,
>
> I'm back after a week of back-to-works frustration! :)
> I checked the tests and deemed them in need of a rewrite.
> Actually there are no tests in the sense that a the unittest framework
> would be used, or any output be asserted against expectations. I will
> rewrite the whole directory to that end, OK?
module is now in the tests/ directory, that's probably the best guide
so far on how to use unittest with python-csp.
> That raises the question what this "tracer" is. Is it only a
> convenience that makes testing and checking process parameters
> possible, or does it have any actual meaning for the CSP-runtime?
for now. It's essentially a debugger that will (eventually) output
useful information about your program, like a graph of your
processes / channels via graphviz, "traces" which are a CSP concept
and maybe a formal model of the code that can be used with the FDR2
model checker.
Certainly, the tracer will never be a replacement for unit testing!
> At last, I want to ask for better naming.
> Though I don't understand much about CSP, it seems that you're both
> (python-csp and PyCSP) rewrite some Java framework and reuse their bad
> naming?
> Anyways, names like "Alt" and the following "alting" verb is a good
> example (look at the docs):
> You explain it with a "select" - which to every programmer says what
> it does. But it's called "alternate" which in a mathematical sense is
> in general plain wrong.
> So why not call it "select" instead?
one of the next available channels for reading on, so you "alternate"
between ready channels. With Barriers (in the csp.guards module, I
think) you ask all the channels to become ready, read from them all,
then the writing processes proceed on with their computation. The idea
is that you use an Alt when you just want the next available bit of
data, you use Barriers when you need the data from all producer
processes in each iteration. The distinction is just in how you want
to split up your computation.
I agree the terminology is archaic and unhelpful (it's actually from
Hoare's work in the 70s/80s). Milner called the same concept "non-
deterministic choice". So, maybe Choice would be a better name?
> Also I encountered "Par" and "Seq". Though it's terribly convenient to
> write only three letters, it doesn't really say anything to newcomers.
> At worst it even brings them on the wrong track, as Par has nothing to
> do with Parity and Seq nothing with a sequence of numbers.
> I'm always a fan of writing the whole word, so what about "Parallel"
> and "Sequential"?
all nouns?
I'm up for a name change, but we need to be sure about it because it's
a big-bang change that, while small, will affect almost every file in
the repository (and possibly for PyCSP if / when we merge), so we
really want to do this only once if we can!
Many thanks,
Sarah
Stefan Schwarzer
On 2010-08-02 22:45, Fabian wrote:
> I checked the tests and deemed them in need of a rewrite.
> Actually there are no tests in the sense that a the unittest framework
> would be used, or any output be asserted against expectations. I will
> rewrite the whole directory to that end, OK?
There are several unittests (using the unittest module) in
http://code.google.com/p/python-csp/source/browse/test/test_builtins.py
I started to write this at the sprint at the EuroPython.
Fabian Kreutz and me had an e-mail discussion about testing
of the Python-CSP code after the sprint. I try to summarize
it here.
Strictly speaking, the current tests in test_builtins.py
aren't unit tests in the sense that they test just the code
in the builtins module in isolation. To actually test the
code, there's some infrastructure, e. g. constructing
channels and connecting them to the builtin etc. Another
approach would be to use mock tests which try to not use
code outside the unit (class, module etc.) which is to be
tested.
The current builtin tests are more like functional tests,
not unit tests in the strict sense. On the other hand, I
think going with functional tests here is reasonable because
writing appropriate mock code may be as error-prone as using
the given infrastructure (actual channels, parallel
execution and so on).
That said, at the moment I'm reluctant to do anything on the
code as I prefer to wait for details of the project merge
process to be worked out. I wouldn't like to write code only
to have it thrown away in the end. On the other hand I want
to emphasize that, in my opinion, throwing code away during
the merge is necessary and desirable if it benefits the
merged project and its users in the long run.
[Identifier names]
> Anyways, names like "Alt" and the following "alting" verb is a good
> example (look at the docs):
> You explain it with a "select" - which to every programmer says what
> it does. But it's called "alternate" which in a mathematical sense is
> in general plain wrong.
> So why not call it "select" instead?
>
> Also I encountered "Par" and "Seq". Though it's terribly convenient to
> write only three letters, it doesn't really say anything to newcomers.
> At worst it even brings them on the wrong track, as Par has nothing to
> do with Parity and Seq nothing with a sequence of numbers.
> I'm always a fan of writing the whole word, so what about "Parallel"
> and "Sequential"?
I think it depends on the "type" of users we have in mind in
the long run. Do we expect users to know about CSP theory
before letting them use the framework? Or do we rather
expect users who are "just" looking for a tool to solve
their concurrency problems? If the latter, more abstract
names in terms of concurrency (instead of specific
vocabulary from CSP research) are, I think, the way to go.
I agree with Fabian (Snovna) on using whole words, not
abbreviations. Complete words are clearer when reading code.
If someone feels a need to shorten the code, e. g. because
of several `Par`/`Parallel` calls in a row, s/he can still
write `Par = csp.Parallel` withing a function or method.
Stefan
Fabian
So I'm done for now. Please check the new testing branch.
Please! Somebody has to peer-review it.
Also, there are some problems.
a) The tests don't seem to work under Python3 for me.
It seems that the private attributes that os_thread accesses
(_Thread__args) are not available there.
b) I don't know how to prevent the StopIteration output in some
background thread/process
c) Some things don't seem to work. Doesn't the documentation say that
processes poison all channels, if one channel is poisened? That does
not happen!
I marked these cases with commented tests and a "TODO" print.
Anyways, have fun with them!
Bye, Fabian
Sarah Mount
> Moi!
>
> So I'm done for now. Please check the new testing branch.
>
> Please! Somebody has to peer-review it.
OK, I'll try to have a look over the next couple of days! Thanks for
your efforts.
> Also, there are some problems.
> a) The tests don't seem to work under Python3 for me.
> It seems that the private attributes that os_thread accesses
> (_Thread__args) are not available there.
Ah, this is to do with the way "private" methods are obfuscated in
Python. I'll take a look, but it comes from us needing to use
attributes that are private to Thread objects.
> b) I don't know how to prevent the StopIteration output in some
> background thread/process
Not sure I understand this but I'll look at the comments in the code.
> c) Some things don't seem to work. Doesn't the documentation say that
> processes poison all channels, if one channel is poisened? That does
> not happen!
OK, when a channel is poisoned, the next process reading / writing
with the channel will stop executing and poison every channel type in
its __dict__. When other processes read / write with those channels,
they will stop and do the same, so the "poison" will spread throughout
the network of processes. If some processes do not read / write with
their channels (or not for a long time) or similar you can sometimes
end up with either deadlocks or you might just find some processes
carry on and never receive a poison exception. Rune has a nice thing
in PyCSP that gets around some of these problems called "channel
retirement".
> I marked these cases with commented tests and a "TODO" print.
Brilliant, thanks!
Sarah
--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website: http://www.snim2.org/
twitter: @snim2