Monday, February 12, 2018¶
Improve the Lino Developers Guide¶
I did a series of changes to make the Lino Developers Guide more readable for beginners. As usual this also caused some internal optimizations.
I started to optimize the internal API about table handles, layouts and layout handles.
>>> import lino >>> lino.startup('lino_book.projects.team.settings.doctests') >>> from lino.api.doctest import * >>> AllTickets = rt.models.tickets.AllTickets
>>> cols = AllTickets.get_handle().get_columns() >>> lh = AllTickets.get_list_layout() >>> lh <lino.core.layouts.LayoutHandle object at ...> >>> lh.layout <lino.core.layouts.ColumnsLayout object at ...> >>> lh.main <GridElement main in lino.core.layouts.ColumnsLayout on lino_xl.lib.tickets.ui.AllTickets>
Tonis wrote the
get_detail_elems() of an actor:
>>> list(AllTickets.get_detail_elems()) [<Panel general_1 in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>, <Panel more in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>]
I wrote a method
get_detail_layout() which returns the layout
handle itself. Maybe that’s easier to use:
>>> lh = AllTickets.get_detail_layout() >>> lh <lino.core.layouts.LayoutHandle object at ...> >>> lh.layout <lino_noi.lib.tickets.models.TicketDetail object at ...> >>> lh.main <TabPanel main in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets> >>> list(lh.main.elements) [<Panel general_1 in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>, <Panel more in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>]
lino_book.projects.events is the only use case (in
The Lino Book, one other case is in Lino Welfare) for dynamic table
handles. The project was unused and ratherbroken. Now it is usable
with runserver and has a test suite which covers that special use of a
table with a meth:get_handle_name method.
But all this is –as usual– not finished. Tomorrow I will maybe continue.
Sphinx 1.7.0 is out¶
Except maybe for a SphinxWarning
Inline interpreted text or
phrase reference start-string without end-string". I had to
tolerate_sphinx_warnings to True in order
to see where it comes from. It was in the docstring for
lino.core.fields.ForeignKey(). I worked around this by removing
the link to Django docs there. It is possible that Sphinx autosummary
has a modified behaviour when extracting the first sentence of the
docstring. But another possible explanation is that I changed this
docstring recently. No need to investigate AFAICS.
Is POD ready for python 3 ?¶
.. literalinclude:: 0212/0212.py
The output document created with our version of appypod says:
Error while evaluating expression "I". 'int' object is not iterable if escape: result.dumpContent(res) File "/appypod/appy/pod/buffers.py", line 196, in dumpContent nsText=self.env.namespaces[self.env.NS_TEXT]) File "/appypod/appy/xml/__init__.py", line 65, in escapeXml for c in s: TypeError: 'int' object is not iterable
This seems to show that appy-python-3 was not ready for Python 3 when I forked it some months ago.
Now I updated my copy of that repository:
(py27) luc@doll:~/repositories/appy-python-3$ svn update Updating '.': A trunk/ui/navigate.py U trunk/ui/utils.py U trunk/ui/css.py U trunk/http/client.py U trunk/model/fields/group.py U trunk/model/fields/__init__.py U trunk/model/fields/search.py U trunk/model/fields/string.py U trunk/model/fields/calendar.py U trunk/model/fields/workflow.py U trunk/model/fields/ref.py U trunk/model/fields/action.py U trunk/model/fields/date.py U trunk/model/fields/file.py U trunk/model/fields/computed.py U trunk/model/fields/pod.py U trunk/utils/path.py U trunk/xml/__init__.py U trunk/pod/renderer.py U trunk/pod/converter.py U trunk/pod/doc_importers.py U trunk/pod/styles_manager.py U trunk/pod/xhtml2odt.py U trunk/px/parser.py U trunk/px/__init__.py Updated to revision 123.
So Gaetan continues developing in appy-python-3 but refuses to
setup.py file so that normal people can use the
package. Furthermore I have no idea whether he saw my fixes for the
trivial errors I added to his code after the fork. Oh my God, this
situation makes no sense! I want to help Gaetan to make appy work
under Python 3, I don’t want to fork it definitively! Gaetan, let’s
meet and collaborate!