From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [Proposal] Source Blocks with Post-Extensions
Date: Tue, 23 Apr 2019 06:59:50 +1000 [thread overview]
Message-ID: <878sw1bvsp.fsf@gmail.com> (raw)
In-Reply-To: <CA+Yh0SQKnaGJyGGqOpZm8jamguGTCvmHLRdYZbu2GUDWZwYACQ@mail.gmail.com>
YMMV, but personally, I think the real problem here is combining your
tests with your definition. i.e. square = lambda x: x * x is your real
code block while the return line is really just part of
testing/debugging and should not be in your definition block.
Tests are very important, but I find they 'clutter' the code and make it
harder to read/think about the core functionality - especially after
leaving and returning some time later to worik on the core code.
My approach is to keep the code blocks as 'pure' as possible and put all
the tests in a separate section of the org file. It does make code test
coverage a bit more challenging because you don't have the two 'side by
side', but I find that is offset by the increased clarity with the main
code.
just an alternative view ....
Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
> For your convenience, I have attached this e-mail as an org-mode file.
>
> When I write several source blocks, which depend on one another, I tend to
> debug them one by one.
>
> So, I write this function and test it:
>
> #+NAME: square
> #+BEGIN_SRC python
> square = lambda x: x * x
> return square(5)
> #+END_SRC
>
> #+RESULTS: square
> : 25
>
> After I see that the test is successful, I write this client function:
>
> #+BEGIN_SRC python :noweb yes
> <<square>>
> return 5 + square(5)
> #+END_SRC
>
> #+RESULTS:
> : 25
>
> And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> So I find nothing better to do than to seperate the source block:
>
> #+NAME: square-1
> #+BEGIN_SRC python
> square = lambda x: x * x
> #+END_SRC
>
> And, by the way, there was no error/warning that I have just redefined
> ~<<square>>~,
> so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
> I think the org-mode team is aware of it, but anyway:
>
> - [ ] no error checking of the description of a code block.
>
> #+NAME: square-1-tester
> #+BEGIN_SRC python :noweb yes
> <<square-1>>
> return square(5)
> #+END_SRC
>
> #+RESULTS: square-1-tester
> : 25
>
> - [ ] For every such source block used for testing purposes, you have to
> repeat the inclusion statement and part of the name, which is cumbersome.
>
> A fair solution is maybe to extend the block like this:
>
> #+NAME: square-1
> #+BEGIN_SRC python
> square = lambda x: x * x
> #+END_SRC
> return square(5)
> #+END_SRC_TEST
>
> When I call this individually, the test part would run, but when I :noweb
> it in another block, the test part would be ommited.
>
> As an extension of this idea, it could be useful to have several test
> attachments like this, each producing its own result. Maybe, the TEST part
> could as well be ommited. Custom names are also an option:
>
> #+NAME: square-multiple
> #+BEGIN_SRC python
> square = lambda x: x * x
> #+END_SRC
> return square(5)
> #+END_SRC NAME: ext_1
> return square(10)
> #+END_SRC NAME: ext_2
>
> #+RESULTS: square-multiple-ext-1
> : 25
>
> #+RESULTS: square-multiple-ext-2
> : 100
>
> Overall, these techniques should reduce noise and increase usability.
--
Tim Cross
prev parent reply other threads:[~2019-04-22 21:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-22 9:00 [Proposal] Source Blocks with Post-Extensions Dmitrii Korobeinikov
2019-04-22 16:51 ` Berry, Charles
2019-04-22 17:15 ` Dmitrii Korobeinikov
2019-04-22 17:31 ` Berry, Charles
2019-04-24 19:05 ` Dmitrii Korobeinikov
2019-06-26 22:09 ` Martin Alsinet
2019-07-03 16:02 ` Dmitrii Korobeinikov
2019-07-26 12:02 ` Ken Mankoff
2019-07-26 12:58 ` Martin Alsinet
2019-07-26 15:18 ` Ken Mankoff
2019-07-26 15:52 ` Martin Alsinet
2019-04-22 20:59 ` Tim Cross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sw1bvsp.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).