[docs] glob returns empty list with "[" character in the folder name (issue 8402)

[ezio.melotti at gmail.com]

http://bugs.python.org/review/8402/diff/6281/Doc/library/fnmatch.rst
File Doc/library/fnmatch.rst (right):

http://bugs.python.org/review/8402/diff/6281/Doc/library/fnmatch.rst#newcode76
Doc/library/fnmatch.rst:76: arbitrary literal string that may have
special characters in it.
On 2012/10/15 12:12:24, storchaka wrote:
> On 2012/10/15 11:21:37, ezio.melotti wrote:
> > This could mention what the special characters are.
> 
> The special characters exposed in the table above.

Given that there are only 3 special characters that gets escaped, I
think it's ok to mention them explicitly.

http://bugs.python.org/review/8402/diff/6281/Doc/library/fnmatch.rst#newcode86
Doc/library/fnmatch.rst:86: True
On 2012/10/15 12:12:24, storchaka wrote:
> On 2012/10/15 11:21:37, ezio.melotti wrote:
> > I'm not sure that showing the output is useful.  The *-[[] seems a
bit
> confusing
> > if you don't know how escaping works.
> 
> Is '.*\\.txt$' below less confusing? Well, I'll remove it. May be
worth to
> remove the entire "escape()" example?
> 
> > If you want to show it, it might be better to escape a pattern that
contains
> > '?'.
> 
> Unhappy non-escaped '?' matches literal '?'. We should use negative
example (not
> matching '?').
> 
> 'file_locked-[Converted].png' is a real file from Nuvola icon theme.
Can you
> give a good example with and without '?'?

FWIW on windows ? and * are not even allowed in file names, so indeed
'[' is probably the most commonly-found problematic character.

http://bugs.python.org/review/8402/diff/6281/Lib/test/test_fnmatch.py
File Lib/test/test_fnmatch.py (right):

http://bugs.python.org/review/8402/diff/6281/Lib/test/test_fnmatch.py#newcode53
Lib/test/test_fnmatch.py:53: check('abc', escape('a*'), False)
On 2012/10/15 12:12:24, storchaka wrote:
> On 2012/10/15 11:21:37, ezio.melotti wrote:
> > I would also check escape() directly, rather than doing it only
through
> check().
> >  Checking for invalid inputs is a good idea too.
> 
> What do you mean "invalid input"? Test already contains negative
matches. Any
> input for escape() is valid.

I meant non-strings.  I now tried and apparently the error returned by
re.sub is already good enough in that case.

http://bugs.python.org/review/8402/