From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: [Proposal] Source Blocks with Post-Extensions Date: Tue, 23 Apr 2019 06:59:50 +1000 Message-ID: <878sw1bvsp.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:44463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIgEI-0002SS-NO for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 17:11:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIg2f-0004z7-Mv for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 16:59:59 -0400 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]:43233) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hIg2e-0004xc-0g for emacs-orgmode@gnu.org; Mon, 22 Apr 2019 16:59:56 -0400 Received: by mail-pg1-x531.google.com with SMTP id z9so6396170pgu.10 for ; Mon, 22 Apr 2019 13:59:55 -0700 (PDT) Received: from tim-desktop (2001-44b8-31f2-bb00-fdca-40b4-50e0-877d.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:fdca:40b4:50e0:877d]) by smtp.gmail.com with ESMTPSA id i31sm17065641pgi.36.2019.04.22.13.59.52 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 Apr 2019 13:59:53 -0700 (PDT) In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org 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 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 > <> > 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 ~<>~. > 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 > ~<>~, > so, for the test-snippet below to work, I renamed it to ~<>~. > 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 > <> > 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