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 package, 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!