On Sat, 2010-03-06 at 08:41 +1030, David Gowers wrote:
> >>> On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
> > I agree with Joao S. O. Bueno and disagree with David Bowers.
>
> Well, I'm glad you don't disagree with me, but who is that?
>
Sorry I mangled your name. BTW David Bowers is a famous
environmentalist, Sierra Club etc. Mr. Gowers was a pharmacist in the
movie "Its a Wonderful Life." He boxed Jimmy Stewart up the side of the
head, like you did me. Just kidding.
> >
> > Its better to make plugins meet the normal expectations of Python
> > programmers (you can import any Python file to use pieces of it) than to
> > add new conventions and directories for shared Python plugin code.
> > Simpler is better?
>
> The normal expectations of Python programmers are that the main loop
> will be guarded.
Granted.
> This is exactly the thing that allows you to import otherwise
> executable modules;
> without it, no guarantees can be made that the code you are importing
> will not interfere with global state in a way which causes your plugin
> to crash. You can depend on a specific version of a plugin which has
> known behaviour; In that case you prevent the user from upgrading that
> plugin, and you rely on knowledge of the internals of that plugin,
> which is very likely to get you into trouble if you ever need to
> upgrade it.
>
> The same principle applies to python scripts that are unguarded:
> importing them will, at the least, have significant side effects.
> Often they are entirely incapable of being cooperative.
>
> Hence, it's not practical to import a plugin module unless it
> specifically indicates that it is fit to be imported (by guarding the
> main loop)
But Gimp shouldn't protect programmers from themselves. If they import
a plugin that is not fit, or create dependencies on versions, let them.
>
> >
> > Often, authors don't plan their code will be useful to others. It's
> > just serendipity. If authors don't plan to share code and put it in
> > these new directories, it thwarts serendipitous reuse and
> > experimentation.
> >
> > It is inconsistent for a duplicate call to register() to be harmless
> > with a warning while a duplicate call to main() is fatal.
>
> Currently, the latter is serving the function of preventing the
> previously mentioned possibility of side effects of importing a plugin
> in this way.
>
> If there is another way of preventing that problem, then we could look
> at removing that aspect of main() calls.
> Otherwise, we absolutely must not.
>
> >
> > Also, new conventions and directories does not solve my wish to call
> > pydoc on plugins (which is not very important. I hope to download a
> > prototype Inspect plugin to gimp registry soon.) But it illustrates
> > that you can't always anticipate what people will want to do.
>
> I wanted to do that too.
> Just because you want to do something, doesn't mean it's wise to do so.
>
> Calling pydoc on unguarded python modules is just as unpredictable as
> importing unguarded python modules. Why? Because the way it gets the
> documentation is by first importing the module in question.
> Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or
> gimpfu, etc..) modules mean that even if they are in the module search
> path, pydoc's attempt at importing them will fail (because the gimp
> and gimpfu,etc.. modules are only available to Python scripts that are
> being run by GIMP).Changing the mechanics of main() would not effect
> that.
>
> If you don't believe that, it's easy to check; set PYTHON_PATH to your
> plugins directory (full, absolute path like
> /home/llkk/.gimp-2.7/plugins), start Python, and try to import one of
> those plugins as a module.
>
> David
My Inspect plugin IS run by Gimp. Thus importing pydoc and invoking it
on plugins DOES work, as far as I can tell by my limited testing, with
the patch to Pygimp that I have proposed.
Also, you CAN invoke pydoc on the pygimp modules from an Inspect plugin
run by Gimp. It turns out not to be really useful, since the existing
documentation for pygimp is rather good.
IF you can't invoke pydoc on the command line on a plugin, it's not
because it can't find the pygimp modules (because you can set the path
so it will) but for the reason you described: they need Gimp running. I
really haven't tested it.
But this does seem to work: start Gimp, open the Python console, import
pydoc, and call pydoc.render_doc('gimp'). I believe this works even
without the patch under discussion. But pydoc.render_doc('colorxhtml')
crashes pyconsole lacking the patch under discussion.
My brain hurts.
Lloyd
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
