Update. I released 0.9 which makes the global namespace look like this: >>> y(globals()) --- __builtins__: !!python/module:__builtin__ '' __doc__: Welcome to pyplay. Type h() for help. __name__: __main__ __package__: null h: !!python/name:__main__.h '' os: !!python/module:os '' re: !!python/module:re '' sys: !!python/module:sys '' y: !!python/name:__main__.y ''
It was easier said than done. I had to delete os and sys before importing the module list, otherwise they would look available even if the user requested them to not be. Also the h() command prints __version__ which I deleted, so I had to make sure and capture references to the locals() first. I feel like I'm getting a decent intro to Python. :) One thing I still can't do is specify my name in unicode as 'Ingy döt Net'. I've gotten 2/3rds of the way through the toolchain. I got `setup.py register` to work, and I reported a bug to github regarding utf-8 in README.rst formatting (which they have now fixed), but `setup.py upload` is still failing. Maybe you guys can help me debug this at the seapig meeting. Cheers, Ingy On Tue, Mar 30, 2010 at 1:01 PM, Ingy dot Net <[email protected]> wrote: > On Tue, Mar 30, 2010 at 12:44 AM, Gary Bernhardt <[email protected] > > wrote: > >> On Mon, Mar 29, 2010 at 8:34 PM, Ingy dot Net <[email protected]> wrote: >> > >> > Thanks. Actually it does pollute the global namespace a bit, with the >> key >> >> Ahh, this is a different issue. Before, we were talking about not >> polluting, but what you're really talking about here is total control. >> For that, you want to define __all__ in your module. It's a list of >> strings; only those strings will be visible from the outside. >> > > Thanks. > > I think __all__ only affects what happens when you `from foo import *`. > pyplay is a little bit weird because you don't typically import it. It is > really just run as a PYTHONSTARTUP script by the 'pyplay' bin script. So > using `__all__ = []` doesn't help me towards the goal of keeping the > globals() dict clean. In fact, it actually "adds" __all__ to my globals! The > only thing I can do is move everything inside the PyPlay class. > > I realize that this is all just silly conjecture and not very important... > but if I wanted to push it... what could I do to make pyplay startup be as > close to plain python startup as possible, while still adding the pyplay > helpers? If I start python I get: > > >>> globals() > {'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', > '__doc__': None} > > > If I start pyplay I get: > > >>> globals() > {'__builtins__': <module '__builtin__' (built-in)>, 'h': <function h at > 0x6317b0>, 'PyPlay': <class __main__.PyPlay at 0x630810>, '__package__': > None, 'sys': <module 'sys' (built-in)>, 're': <module 're' from > '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.pyc'>, > 'y': <function y at 0x631870>, '__name__': '__main__', '__version__': '0.8', > 'os': <module 'os' from > '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc'>, > '__doc__': 'The ``pyplay.py`` module supports the ``pyplay`` command line > utility.\n'} > > > So let's see... > > I'm fine with the standard: __builtins__, __name__ and __doc__ > > I want the pyplay additions: h, y, os, sys and re > > I guess I'm ok with the PyPlay module in globals, but it's not useful to > the user. The only other thing to get rid of is __version__. I think I'll > need 'del' to get rid of those... > > However, I've found that, in general, anything useful to the module >> might be useful to the outside, and you probably should just expose >> it. Why not just expose main, for example? What if I want to wrap >> PyPlay, doing some sort of magic and then calling your main function? >> Seems reasonable to me! >> > > It's not like 'main' is gone. It's just not exported. Correct me if I'm > wrong, but I think you can still access everything in a module when __all__ > is set to []. Right? > > > >> >> The only time I use __all__ is when I'm writing a top-level API module >> and simplicity is very important – in my Expecter Gadget library, for >> example. >> >> > I want to learn unittest since it is core. Now I can tell people to run >> > 'python setup.py test' or simply 'make test' and it will always do the >> right >> > thing. >> >> Make? We don't use that around here! ;) (Well, except for building >> Python itself...) I still suspect that there's a much easier way to >> make "setup.py test" work, although I'm not motivated to find out what >> it is. My projects always have a "runtests.py" file (e.g., [1]) that >> invokes nose, because I like to configure things like test naming. > > > :) Make is just for my own typing sanity. My Makefile simply proxies all > its targets to setup.py. I really just want all these things to work: > > setup.py build > setup.py test > setup.py install > > >> > PS. It turned out the setup.py only ran the first test, if I had >> multiple >> > tests. That is because unittest calls sys.exit!! That seems evil to me. >> I >> > was overjoyed to find out I could work around this with even more evil. >> I >> > added this to my setup.py: >> > def exit(code): >> > pass >> > sys.exit = exit >> > :-D >> >> OH GOD KILL IT WITH FIRE! >> > > XD > > Ingy > > >> >> [1] http://bitbucket.org/garybernhardt/dingus/src/tip/runtests.py >> >> -- >> Gary >> http://blog.extracheese.org >> > >
