Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #36072

Re: Can't seem to start on this

From Kene Meniru <Kene.Meniru@illom.org>
Subject Re: Can't seem to start on this
Followup-To gmane.comp.python.general
Date 2013-01-03 12:36 -0500
Organization illom.org
References (1 earlier) <20130103082031.73a5b842@dilbert> <kc439t$ehn$1@ger.gmane.org> <20130103093015.2b46908f@dilbert> <kc46bk$9bj$1@ger.gmane.org> <20130103121632.6af0a3e4@dilbert>
Newsgroups comp.lang.python
Message-ID <mailman.50.1357234625.2939.python-list@python.org> (permalink)

Followups directed to: gmane.comp.python.general

Show all headers | View raw


D'Arcy J.M. Cain wrote:

> That works too.  It's just that you had users writing Python code but
> assumed that a three line subclass was beyond them.  Not requiring them
> to write any Python code is a better option than the first one (global
> variables) that you proposed.  That's all I am trying to say.
> 

I understand.

>> program behaves or perhaps a building component. In that case any of
>> the other modules can be updated instead of "A". Actually "A" will
>> not be part of the packaged program.
> 
> Or "A" becomes the script that parses the config file and runs the
> other code.
> 

Yes. To be more precise, later I will create "A_Interface" to provide the 
user with an interface for creating the contents of "A". "A_Interface" will 
then parse "A", calling "B" as required to create the artifact. I had wanted 
to jump into "A_Interface" using something like urwid or PyQt but it makes 
sense to work with "A" directly for now.

Thanks for taking the time to understand.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Can't seem to start on this Kene Meniru <Kene.Meniru@illom.org> - 2013-01-03 12:36 -0500

csiph-web