[IPython-dev] [nbconvert] Reining in the number of constructor arguments
Sat Dec 1 14:18:35 CST 2012
I should mention one other reason we need to use the
Configurable/Application framework. nbcovert will eventually be
integrated into the notebook web application, which itself uses all of
that technology for configuration.
On Sat, Dec 1, 2012 at 12:12 PM, Brian Granger <email@example.com> wrote:
> Thomas makes a very good point:
> If the nbcovert code is getting complex enough that these issues are
> coming up, then there is no question about what we should do. We
> should handle it exactly like we do everywhere else in the IPython
> code base. The top level converter classes should inherit from
> Configurable and the command line programs should be implemented as
> Applications. All of the config file stuff and command line options
> will then be handled automatically. This approach allows the
> converters to be configured in numerous ways:
> * Command ilne
> * Passing kwargs to the classes.
> * Setting attributes
> * Config files
> Is there any reason we wouldn't do this?
> On Sat, Dec 1, 2012 at 3:26 AM, Thomas Kluyver <firstname.lastname@example.org> wrote:
>> On 1 December 2012 00:34, David Warde-Farley <email@example.com>
>>> It seems like the right place for this code would be in a class method
>>> attached to each
>>> Converter class. Then nbconvert.py could iterate over the classes it
>>> knows about and
>>> call cls.cli_argument_parser(), and add that to the global one.
>> Have a look at the Configurable/Application framework we use in the main
>> IPython codebase - I think this should be flexible enough to use in
>> nbconvert as well.
>> IPython-dev mailing list
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> firstname.lastname@example.org and email@example.com
Brian E. Granger
Cal Poly State University, San Luis Obispo
firstname.lastname@example.org and email@example.com
More information about the IPython-dev