[Python-3000] A few small py3k wishes

[Ian Bicking]

Talin wrote:
> -- An easy way to make a case-insensitive, case-preserving
> dict that works with regular string keys.

Adam gave one possible implementation.  Another would be a keyed 
dictionary, e.g.,: KeyedDict(key=lambda s: s.lower()).  A keyed 
dictionary would internally call that function on keys to get the "true" 
key, but things like .keys() would return the keys that were passed in. 
  So a minimal implementation...

class KeyedDict(DictMixin):
     def __init__(self, key):
         self._data = {}
         self._key_func = key
     def __getitem__(self, key):
         return self._data[self._key_func(key)][1]
     def __setitem__(self, key, value):
         self._data[self._key_func(key)] = (key, value)
     def __delitem__(self, key):
         del self._data[self._key_func(key)]
     def keys(self):
         return [t[0] for t in self._data.values()]

> (Another one of my wild ideas was an "order by"
> clause for list comprehensions, but let's not go there.)

Yeah, I'd like that too.

> -- A simple way to import all modules in a directory
> (this would be used for plugins)

I think setuptools entry points (and other things that pkg_resources 
has) offer a better model for this.  It's not as light as just importing 
all modules; but it also works better ;)  I think any system 
sophisticated enough to use plugins should also start using proper 
packages with setup.py and all, not a directory of files.

> -- A mechanism whereby imported modules can import
> symbols from the module that imported them. (Specifically,
> I want to take a bunch of variables in my __main__ module
> and make them accessible to the imported module.)
> 
> -- The module class should have a method to iterate
> over child modules. Currently you can iterator through
> all of its attributes, but you have to filter out which ones
> are modules.

These also seem plugin-related, and I think there are other, better ways 
to handle these issues.  That's not to say it's obvious what those 
better ways are, but they are out there somewhere ;)

> -- A path-globbing function that supports regex-style
> captures.

I'm not sure what you'd propose; like (*).txt?

> -- A path-globbing function that supports the
> perforce-style syntax "..." (three dots) to mean "all descendants".
> So for example, "foo/.../*.cpp" matches any cpp files in
> foo or any of its subdirectories.

I think this would be best to implement as a separate module, and try it 
out.  I don't feel like the conventions here are well agreed upon; 
people agree on what simple file globbing looks like, but I don't really 
see any agreed upon conventions for things like this.  If you implement 
the same API as fnmatch and glob, then your richer globbing will be a 
mostly drop-in replacement.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org