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 alreadybad 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
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.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.
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:
"Namespaces are one honking great idea -- let's do more of those!"
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.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.
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...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?
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.The latter could even be a file in plugins/, maybe using .vimpy or some such as file extension to avoid backwards compatibility problems.
Regards, Andy -- The Unknown surrounds us at any given moment. That is where we seek knowledge. -- MOTHER SUPERIOR RAQUELLA BERTO-ANIRUL: Oratory Against Fear
pgptuaPS4GnwT.pgp
Description: PGP signature