Unary and binary operators in csp/builtins.py
Stefan Schwarzer
I'd like to go through builtins.py and replace statements
like
Plus = _applybinop(operator.__add__,
"""Writes out the addition of two input events.
""")
with
Plus = _applybinop(operator.add,
"Writes out the sum of two input events.")
Reasoning:
- operator.add means the same as operator.__add__ but is
shorter and easier to read.
- Making the docstring a one-line string gets rid of the
""") things at the starts of a line. This aids
readability. Omitting a line break from a short docstring
is consistent with PEP 257 ("Docstring conventions").
Have I missed something or can I go ahead?
Stefan
snim2
wrote:
>
> I'd like to go through builtins.py and replace statements
> like
>
> Plus = _applybinop(operator.__add__,
> """Writes out the addition of two input events.
> """)
>
> with
>
> Plus = _applybinop(operator.add,
> "Writes out the sum of two input events.")
>
>
Thanks,
Sarah
Stefan Schwarzer
Done. :) I tried some other formatting approaches to
make the definitions even easier to read. I also found
some things which seem a bit suspicious to me. Please
have a look at the comments.
Stefan
snim2
> Hi Sarah,
>
> On 2010-07-27 23:10, snim2 wrote:
>
> > On Jul 27, 9:37 pm, Stefan Schwarzer <sschwar...@sschwarzer.net>
> > wrote:
> > Sounds extremely sensible -- go for it!
>
> Done. :) I tried some other formatting approaches to
> make the definitions even easier to read. I also found
> some things which seem a bit suspicious to me. Please
> have a look at the comments.
>
different implementations of the library, I'll go through the other
comments separately.
Sarah
Fabian
Stefan also "temporarily" renamed _applybinop and the unary one with
"binop" and "unop", but afterwards deletes the renaming.
Why not leave them with the better name? For sure somebody else wants
to use these convenience methods, so let's rather export them.
BTW, what is the reason for deleting modules from the namespace?
Like an "del os" in the very end?
Same for deleting these temporary aliases that Stefan used.
What would be the benefit of these delete statements??
Bye, Fabian
Stefan Schwarzer
On 2010-08-06 20:26, Fabian wrote:
> Stefan also "temporarily" renamed _applybinop and the unary one with
> "binop" and "unop", but afterwards deletes the renaming.
> Why not leave them with the better name? For sure somebody else wants
> to use these convenience methods, so let's rather export them.
As `_applybinop` and `_applyunop` were marked as "private"
by their leading underscores I didn't want to add any new
public interface. If the purpose of the "renaming" hadn't
been to shorten the names to enable a nicer layout I would
have prefixed them with an underscore as well. Because I
didn't, I removed the names instead.
_If_ we want to make the functions part of the official API,
we should use unabbreviated names. In that case, should the
functions' API be changed in any way? In my opinion, the
function to wrap and the docstring (in this order) seem an
intuitive interface to me.
> BTW, what is the reason for deleting modules from the namespace?
> Like an "del os" in the very end?
As far as I'm concerned this can go. Deleting module names
is rather uncommon, even though in case of less well-known
modules it might confuse newcomers to the language a bit if
they look at the imported module's (i. e. `csp.builtins`)
dictionary. But at the latest a `help(csp.builtins.os)`
should show what it is. :)
> Same for deleting these temporary aliases that Stefan used.
> What would be the benefit of these delete statements??
See above.
Stefan
Sarah Mount
> Hi Fabian,
>
> On 2010-08-06 20:26, Fabian wrote:
>> Stefan also "temporarily" renamed _applybinop and the unary one with
>> "binop" and "unop", but afterwards deletes the renaming.
>> Why not leave them with the better name? For sure somebody else wants
>> to use these convenience methods, so let's rather export them.
>
> As `_applybinop` and `_applyunop` were marked as "private"
> by their leading underscores I didn't want to add any new
> public interface. If the purpose of the "renaming" hadn't
> been to shorten the names to enable a nicer layout I would
> have prefixed them with an underscore as well. Because I
> didn't, I removed the names instead.
>
> _If_ we want to make the functions part of the official API,
> we should use unabbreviated names. In that case, should the
> functions' API be changed in any way? In my opinion, the
> function to wrap and the docstring (in this order) seem an
> intuitive interface to me.
OK, but the idea of the builtins originally, was that we would wrap
every Python operator so the user didn't have to, so the user would
never need the __applybinop function themselves. A process builder
that takes a function and creates a process out of it in the way you
describe might well be very useful, it might be sensible to have a
bunch of these sorts of things for different ways to combine processes
together.
>> BTW, what is the reason for deleting modules from the namespace?
>> Like an "del os" in the very end?
>
> As far as I'm concerned this can go. Deleting module names
> is rather uncommon, even though in case of less well-known
> modules it might confuse newcomers to the language a bit if
> they look at the imported module's (i. e. `csp.builtins`)
> dictionary. But at the latest a `help(csp.builtins.os)`
> should show what it is. :)
I think originally it was just because we had the same modules being
imported all over the place and with "from csp.csp import *" you end
up importing a lot of names. That was before we used __all__ properly
though, so as you say the del statements can probably go.
Thanks,
Sarah
--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website: http://www.snim2.org/
twitter: @snim2
Fabian
> OK, but the idea of the builtins originally, was that we would wrap
> every Python operator so the user didn't have to, so the user would
b) As we discussed already during the sprint days: these mini-
processes that are based on a single operator might be good for
tutorials and examples, but any real world case would most likely want
to put some more code into one process. Lambda might be very
convenient for this.
So instead of providing a lot of stuff, because the user might need
it, we rather enable her to easily customize her own.
Didn't we already talk about putting all those operator processes into
some other module?
I already separated most of the builtin tests that concern operators
into their own test class.
Bye, Fabian
Sarah Mount
> Moi!
>
>> OK, but the idea of the builtins originally, was that we would wrap
>> every Python operator so the user didn't have to, so the user would
>
> a) I disagree with this approach in general.
:)
> b) As we discussed already during the sprint days: these mini-
> processes that are based on a single operator might be good for
> tutorials and examples, but any real world case would most likely want
> to put some more code into one process. Lambda might be very
> convenient for this.
Yes, but for turning bigger functions into processes there's always
the @process decorator. That said, I'm all in favour of having
different ways of building different sorts of processes if it's
useful.
> So instead of providing a lot of stuff, because the user might need
> it, we rather enable her to easily customize her own.
>
> Didn't we already talk about putting all those operator processes into
> some other module?
We did. I've added the csp/dsp.py module which contains some other
basic processes. I'm not really sure how best to divide things up at
the moment, but it will be done.
> I already separated most of the builtin tests that concern operators
> into their own test class.
>
Thanks!
Sarah
--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website: http://www.snim2.org/
twitter: @snim2
This email, together with any attachment, is for the exclusive and
confidential use of the addressee(s) and may contain legally
privileged information. Any use, disclosure or reproduction without
the sender's explicit consent is unauthorised and may be unlawful.
Any e-mail including its content and any attachments may be monitored
and used by The University of Wolverhampton for reasons of security
and for monitoring internal compliance with the University's policy on
internet use. E-mail blocking software may also be used. The
University cannot guarantee that this message or any attachment is
virus free or has not been intercepted and amended.
If you believe you have received this message in error please notify
the sender by email, telephone or fax and destroy the message and any
copies.
Stefan Schwarzer
On 2010-08-08 01:38, Sarah Mount wrote:
> On 7 August 2010 19:46, Fabian <fabian...@gmail.com> wrote:
>> b) As we discussed already during the sprint days: these mini-
>> processes that are based on a single operator might be good for
>> tutorials and examples, but any real world case would most likely want
>> to put some more code into one process. Lambda might be very
>> convenient for this.
Sarah mentioned building block systems like Simulink as an
application which might use such small units.
> Yes, but for turning bigger functions into processes there's always
> the @process decorator. That said, I'm all in favour of having
> different ways of building different sorts of processes if it's
> useful.
I think the approach suggested by Fabian covers some ground
between the "builtins" as we have them currently and bigger
functions wrapped with the `process` decorator.
Without these unaryop/binaryop wrappers (or whatever they
may be called in the future ;-) ) a user of Python-CSP has
to code the logic which values to take from which channels
and to emit to explicitly. So having the unaryop/binaryop
wrappers makes it simpler to "CSPize" all functions that
have one or two inputs and one output.
>> Didn't we already talk about putting all those operator processes into
>> some other module?
>
> We did. I've added the csp/dsp.py module which contains some other
> basic processes. I'm not really sure how best to divide things up at
> the moment, but it will be done.
>
>> I already separated most of the builtin tests that concern operators
>> into their own test class.
In my opinion we should merge the dsp.py and builtins.py
modules. As you, Sarah, say, a distinction between both is
difficult. And I found the term "builtins" for such a module
always confusing anyway. :) I mean, what does "builtins"
refer to? Aren't all the APIs in Python-CSP "built in" the
framework?
Hm, I think the general wrappers don't belong in a module
named `dsp.py` because they're too general to be tied to
DSP applications. I think they don't belong in a module
names `builtins.py` either (see above). ;-)
Stefan
Stefan Schwarzer
On 2010-08-08 08:45, Stefan Schwarzer wrote:
> In my opinion we should merge the dsp.py and builtins.py
> modules. As you, Sarah, say, a distinction between both is
> difficult. And I found the term "builtins" for such a module
> always confusing anyway. :) I mean, what does "builtins"
> refer to? Aren't all the APIs in Python-CSP "built in" the
> framework?
I just came across a previous post by Sarah that "builtins"
was referring to counterparts to Python's builtins. Seems I
had forgotten this paragraph. :)
I think aiming at wrapping all of Python's builtins overdoes
it a bit. Maybe it's really better (as I understood Fabian)
to just provide the unaryop/binaryop functions and leave out
the "builtins" (in the sense of reflecting Python's
builtins) altogether.
Stefan