[Python-3000] A few small py3k wishes

[Talin]

Adam DePrince <adam.deprince <at> gmail.com> writes:

> One of my more recent abominations, my views PEP, would have addressed
> this nicely.  And so would ... 
> 
> class caselessdict( dict ):

Interesting approach. I'm not sure I like storing two copies of every
key thought.

> sorted( dict.items() )  

As I mentioned, I wasn't aware the relative comparisons worked
on tuples (in fact, the only place I can find a reference to it is
in the python performance tips page - but perhaps my Google
queries are ill-formed.)

> [x for x in sorted( l )] ??

How about:

   [x for x in l order (x.last_name, x.first_name)]

Again, that's *not* a suggestion, just a hypothetical example.

Anyway, the responses have been good - and I am sure you don't
want this thread to go on any longer :)

My only concern is this: Some of these issues may seem like newbie
questions to you folks, but I've been programming Python for over 5 years
now, I've read the various reference manuals many times, done Google
searches on all these issues, browsed the ASPN cookbooks (although
that may be partly due to the really bad search engine on ASPN), 
and yet failed to find an "obvious" way to do things. I will certainly use
some of the suggestions that have been provided in this thread, but at
the same time I feel that some of them are, well, rather tricky solutions
to what I feel should be common problems.

For example, the suggestion of testing each member of a module with
"is_module" is fine - except that a newbie programmer's first attempt to
write "is_module" is probably going to be "isinstance( value, module )"
which won't work because the word "module" isn't bound to a type.
At which point, they will have to go digging through the library docs to
figure out where the standard types live, or if there's some other way
to determine if an object is a module or not.

Similarly, the need to understand how to construct the current module's
path is concise, but it still requires a deeper understanding of how
modules and packages are loaded -- I mean, what would be wrong
with every module having an __abspath__ attribute or something?

The same is true for the problem of a "plugins" dir containing modules
to import. Yes, its only 3 lines of code to list the directory and import
each file - but coming up with those exact 3 lines (in particular, getting
the arguments to __import__ correct) is trickier than it looks, especially
when you are trying not to hard-code the module name. What I came
up with is this, which is probably incorrect:

# Import all parsers
dirname = os.path.dirname( __file__ )
for name in os.listdir( dirname ):
    if fnmatch.fnmatch( name, "*.py" ) and name != "__init__.py":
        mod = __import__( "%s.%s" % ( __name__, os.path.splitext( name )[ 0 ] ) )

Perhaps the answer is better docs? For example, there's a number of
docs on the package / module loading mechanism, but they all seem
like pieces of an incomplete puzzle to me.

-- Talin