Re: pythonx patch - :pyx command

[Andy Kittner]

On Sat, Jun 01, 2013 at 05:44:17AM +0200, Marc Weber wrote:

j And third, you must not use the same code as :pyfile. It is already

bad that somebody may think that creating large file sourced using
:pyfile is a good idea: it is never a good idea because file executed
via :pyfile is executed as a part of __main__ package polluting global
scope.

Maybe you want it. Its what plugins do: define interfaces for others?

I 100% agree with ZyX on this one.

Yes plugins may define reusable interfaces, but there's no reason to pollute the global namespace with them

I have never used :pyfile and would suggest anybody against it.

With autoloading *.py files using the same code you run into the same
issue.

So, what would you do instead?
plugins/*.vim files also pollute global space, it depends on the user
how he/she uses it.

Essentially what we want is a way to automatically import some module and call a boostrap method on it so it can set up mappings, autocommands, etc. Nothing more, nothing less.

"Namespaces are one honking great idea -- let's do more of those!"

Python is not vim, just because vim plugins all share one namespace it doesn't make sense for python plugins to behave the same. In fact this would go against the python zen:

I don't think this forum is the right place to write up about this.
I think the :h if_pyth.txt is  - or an official wiki.

Well once a solution is implemented we should document how it works and what the "best practices" are in if_pyth.txt, but hashing out how a solution should look like should happen here on the mailing list.

Even with the latter fixed I would only put some necessary initialization into 
such files thus
b) I would merge this at the same time with merging `sys.path`
addition once it is implemented.

I've thought about this again and I think plugins can do this themselves
as needed, eg using __FILE__ constant easily.

ZyX: Can you explain once gain how you'd prevent plugins from polluting
global scope while letting plugins author to define their own stuff?

Should we run such code:

 
http://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path

 import imp
 imp.load_source('module.name', '/path/to/file.py')

This would mean that contents in path/to/file.py would be local to
module module.name

But then we have to think about how to allow sharing - eg privde a
module vim_shared whichs sole purpose is to share a global dictionary?

Yuk! No! If I want to reuse another module I import it, there is no need to stuff everything into one module which would also force everyone to use DamnLongPrefixes as a poor man's namespace...

A clean solutions establishes a connection between vims runtimepath and
the pythons sys.path (the import hook proposed in the other thread seems
like a reasonable idea for this) and then defines a way to automatically
run a bootstrapping function.


Regards,
Andy
--
The Unknown surrounds us at any given moment.  That is where we seek knowledge.

 -- MOTHER SUPERIOR RAQUELLA BERTO-ANIRUL:  Oratory Against Fear

The latter could even be a file in plugins/, maybe using .vimpy or some such as file extension to avoid backwards compatibility problems.

pgptuaPS4GnwT.pgp
Description: PGP signature