On 20/06/2015 08:24, Steven D'Aprano wrote:
On Fri, 19 Jun 2015 07:29 pm, Robin Becker wrote:
I'm trying to overcome a recursive import issue in reportlab.
..
I'm afraid I don't understand what you are trying to say here. Why can't the
user just set up "such a default" e.g. canvas_ba
On Fri, 19 Jun 2015 07:29 pm, Robin Becker wrote:
> I'm trying to overcome a recursive import issue in reportlab.
>
> Module reportlab.rl_config uses various sources (eg ~/.reportlab_settings)
> to initialize various defaults eg canvas_basefontname. If a user wants to
> utilize reportlab to set u
Robin Becker writes:
> I'm trying to overcome a recursive import issue in reportlab.
> ... sketched solution ...
In the "zope" project, the same problem was approached in a slightly different
way -- see the product "zope.deferredimport". It allows to defer
an actual import for an imported name u
Robin Becker writes:
> For the specific case of the canvas_basefontname I don't actually need
> to do anything specific since it is just a string
The configuration values should be nothing but immutable values:
strings, integers, booleans. Possibly collections of those.
You seem to be implying
On 19/06/2015 11:23, Peter Otten wrote:
Robin Becker wrote:
.
Do I understand this correctly? You got bitten by a complex setup and now
you are hoping to improve the situation by making it even more complex?
How about reordering initialisation in such a way that the user defaults are
Robin Becker wrote:
> I'm trying to overcome a recursive import issue in reportlab.
>
> Module reportlab.rl_config uses various sources (eg ~/.reportlab_settings)
> to initialize various defaults eg canvas_basefontname. If a user wants to
> utilize reportlab to set up such a default, it's not pos
