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
-a-module) then I can
> use callables in the settings module and get them evaluated lazily which
> overcomes the recursion.
>
> Are there any gotcha's that need to be considered when using this instance
> as module approach? My trial implementation seems to work, but it's not
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
ere
> http://stackoverflow.com/questions/2447353/getattr-on-a-module) then I can
> use callables in the settings module and get them evaluated lazily which
> overcomes the recursion.
>
> Are there any gotcha's that need to be considered when using this instance
> as module approa
then I can use callables in the settings module and get them evaluated lazily
which overcomes the recursion.
Are there any gotcha's that need to be considered when using this instance as
module approach? My trial implementation seems to work, but it's not clear
exactly how a mo
