homepage

Logged In: YES 
user_id=261020
I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file. That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.
Your other point stunned me a bit. I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public. Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place. Looking at some other stdlib code, I see
that underscores would have been more conventional after all.
Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:
http://www.python.org/dev/summary/2004-07-16_2004年07月31日/#use-the-docs-to-know-what-the-public-api-is-people
e.g. from Tim Peters:
"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""
However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).
So, I guess I should:
1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.
2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run). However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed. So suggestions are welcome here on the
best course of action.
3. As you suggest, submit a patch to add an __all__ to
cookielib.