classification
Title: Allow curly brace expansion
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.4
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Julian, akuchling, bochecha, eric.araujo, eric.smith, ezio.melotti, fdrake, kveretennicov, pitrou, python-dev, r.david.murray, ronaldoussoren, serhiy.storchaka, tim.golden, ysangkok
Priority: normal Keywords: patch

Created on 2010-08-13 08:36 by bochecha, last changed 2013-02-22 18:06 by Julian.

Files
File name Uploaded Description Edit
0001-Curly-brace-expansion-in-glob.patch bochecha, 2011-03-05 03:42 Curly brace expansion in glob
0002-Remove-unused-import.patch bochecha, 2011-03-05 03:44
Messages (52)
msg113750 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-08-13 08:36
The attached patch allows for shell curly braces with fnmatch.filter().

This makes the following possible:
>>> import fnmatch
>>> import os
>>>
>>> for file in os.listdir('.'):
...     if fnmatch.fnmatch(file, '*.{txt,csv}'):
...         print file
...
file.csv
file.txt
foo.txt

This is especially convenient with the glob module:
>>> import glob
>>> glob.glob('*.{txt,csv}')
['file.csv', 'file.txt', 'foo.txt']

Hopefully, this makes fnmatch match better the behavior that people expect from a shell-style pattern matcher.

Please note: I attached a patch that applies on the Python trunk, but only tested it on Python 2.5 on Windows. However, the fnmatch module doesn't seem to have changed substantially in between.
msg113751 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-08-13 08:41
> The attached patch allows for shell curly braces with fnmatch.filter().

Oops, I meant that it allows for curly braces in fnmatch.translate(), which makes it available in the whole fnmatch module.
msg113753 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-13 10:23
Thanks for the patch.

+            if j < n and pat[j] == '}':
+                j = j+1

I don't get what the purpose of these two lines is. Forbid empty patterns?

+            while i < n and pat[j] != '}':
+                j = j+1

You probably mean "while j < n" instead of "while i < n".
Regardless, it's simpler to use "j = pat.find('}', j)".

You should also add a test for unmatched braces. Currently:

$ ./python -c "import fnmatch; print(fnmatch.translate('{x'))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/fnmatch.py", line 129, in translate
    while i < n and pat[j] != '}':
IndexError: string index out of range
msg113756 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-13 12:05
Thanks for this suggestion and patch.

In general I think more tests would be good,  A test for {} would clarify what you are expecting there.
msg113758 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-13 12:34
In Bash, * and ? match only characters in existing files, but {a,b} always produces two filenames, even if the files don’t exist. Do we want to mimic this behavior in fnmatch?
msg113762 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-13 13:03
Ah, I had forgotten that detail, Éric.

No, it doesn't seem as if implementing braces as matchers is appropriate.  fnmatch is only implementing the shell file name globbing. Doing the equivalent of brace expansion would have to be done before applying globbing, to be consistent with the shell.  Which is too bad.

Unfortunately I think we should probably reject this, though it could be discussed on python-ideas to see if the idea can lead to something both consistent with the shell and useful.
msg113765 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-13 13:08
> Doing the equivalent of brace expansion would have to be done before
> applying globbing, to be consistent with the shell.

I don't get the "shell consistency" argument. First, there is no single definition of "the shell". Second, users of Python generally don't care what a shell would do, they simply want to achieve useful tasks (which filename matching is arguably part of).
msg113766 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-08-13 13:11
I'm not sure it has to be consistent with the shell to be useful, as long as the behavior is documented and we possibly add a note explaining the differences from the shell. But I agree that a discussion on python-ideas would be helpful.
msg113767 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-13 13:27
My view is that people using fnmatch/glob are expecting to get back the same list of files that they would if they ran 'echo <globpattern>' in the shell.  The major shells (sh, bash, zsh, csh) seem to be pretty consistent in this regard (though sh does less brace expansion than the others...but is almost always actually bash these days).

If you just wanted to provide a flexible way for people to match files, then instead of fnmatch/glob, we should have a function that walks down a directory tree applying a regular expression to the filenames it encounters and returning the rooted pathnames of the matches.  That function is easy enough to write using standard library facilities.  The special magic of fnmatch/glob is that it does a not-so-easy-to-get-right transformation of *shell* globbing rules into regular expressions behind the scenes.  That is, in my view its *purpose* is to be compatible with the "normal rules" for unix shell globbing.

So currently I'm about -0.5 on this feature.
msg113773 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-13 13:49
> My view is that people using fnmatch/glob are expecting to get back
> the same list of files that they would if they ran 'echo
> <globpattern>' in the shell.

But it's not the case since we currently don't process braces anyway.

> The major shells (sh, bash, zsh, csh) seem to be pretty consistent in
> this regard (though sh does less brace expansion than the others...but
> is almost always actually bash these days).

Excluding the 95% (or so) of Windows users, I suppose.

> The special magic of fnmatch/glob is that it does a
> not-so-easy-to-get-right transformation of *shell* globbing rules into
> regular expressions behind the scenes.  That is, in my view its
> *purpose* is to be compatible with the "normal rules" for unix shell
> globbing.

I've never thought that the purpose of glob or fnmatch was to reproduce
shell rules. It's simply a convenient primitive. Wildcard expansion
exists in lots of other software than Unix shells.
msg113787 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-13 15:37
Well, Windows supports * and ? globs, but not brace expansion, as far as I can tell (at least on XP, which is what I currently have access to).

In fact, I don't believe I've run into brace expansion anywhere except in the unix shell, whereas as you say * and ? globbing is fairly common, so that might be another reason *not* to add it :)

Unfortunately for that argument, Windows XP CMD doesn't appear to support [] globbing.

I'm not going to try block this if other people want it.  As you say, there is no real standard here to adhere to.
msg113789 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2010-08-13 15:46
I don't see any reason to turn this down except, perhaps, for keeping something simple. 

Certainly I don't believe that Windows users will be confused by the fact that there are wildcards other than "*" and "?". fnmatch already implements [] and [!] which are not supported on Windows.
msg113888 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-08-14 11:29
Wow, I certainly didn't expect to generate so much controversy. :-/

First of all, thanks for the comments on the patch Antoine and David.

> I don't get what the purpose of these two lines is. Forbid empty patterns?

I copy-pasted the handling of the '[' character in the same file, and adapted it. This test was to properly handle sequences like '[]]', and you are right, it has nothing to do in this patch, I just forgot to remove it.

> You probably mean "while j < n" instead of "while i < n".

Yes, that's a typo. :-/

> Regardless, it's simpler to use "j = pat.find('}', j)".

I know, I just thought I would try to remain consistent with the way the '[' char was handled.

> You should also add a test for unmatched braces. Currently:

I realised that after submitting the patch, yes. Actually, there are several other cases that I didn't properly handle, like a closing brace without a matching opening brace, or even nested braces (which are perfectly acceptable in the context of a shell like Bash).

I'm working on an improved patch that would correctly handle those cases (with much more unit tests!), I guess I just hit the submit button too quickly. :)

---

Now, about whether or not this is appropriate in fnmatch, I agree with David that if we want to remain really consistent with shell implementations, then fnmatch probably isn't the appropriate place to do so.

In this case, I guess the correct way to implement it would be to expand the braces and generate several patterns that would all be fed to different fnmatch calls?

Implementing it in fnmatch just seemed so convenient, replacing the braces with '(...|...)' constructs in a regex.

People seem to agree that a thread on python-ideas would be good to discuss this change, but this ticket already generated some discussion. Should I start the thread on the mailing-list anyway or is this ticket an appropriate forum for further discussion?
msg113897 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-14 13:45
python-idea is read by more people.
msg114115 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2010-08-17 13:08
I agree with Antoine that this would be useful functionality and that matching "the" shell is futile here.

A quick check on an old linux server: bash and ksh do brace expansion before expanding '*', but that csh does both at the same time.

That is, in a directory with foo.py and no .h files 'echo *.{py,h}' returns foo.py with csh and '*.h foo.py' with bash.

I'm +1 on matching the behavior of csh here.
msg114119 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2010-08-17 13:18
It's worth noting that the sh-like shells are far more widely used than the csh-like shells, so csh-like behavior may surprise more people.

From the sh-like shell perspective, the {...,...} syntax just isn't part of the globbing handling.
msg120082 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-10-31 20:47
I finally found the time to follow up on this issue, sorry for the absence of response.

The thread on Python-Ideas didn't really lead to a consensus (nor did it generate a lot of discussion).

Some wanted to see this in fnmatch, others in glob and others in shutils. Most thought glob was the appropriate place though, and this is also my opinion.

From the Python documentation, fnmatch is a « Unix filename pattern matching » while glob is a « Unix style pathname pattern expansion ».

This makes it clear to me that curly expansion has its place in glob, that would then use fnmatch to match the resulting list of expanded paths.

Here is a patch against the py3k branch.

The patch contains both the implementation, unit tests, and some changes to the documentation.

Note that could I only run the unit tests on Linux (Fedora 14 x86_64) which is the only system I have at hand.
msg122614 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-28 03:40
Latest patch looks good.
msg124422 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-12-21 08:44
Same patch, but rebased to the current trunk so it still applies.
msg124423 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-12-21 08:45
This is the right patch, sorry for all the mail spam. :-/
msg124459 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-21 21:30
Thanks for the research and the updated patch.  Unfortunately as a feature request this is going to have to wait for 3.3 since we missed the pre-beta window.
msg124461 - (view) Author: Mathieu Bridon (bochecha) * Date: 2010-12-21 21:42
> Thanks for the research and the updated patch.  Unfortunately as
> a feature request this is going to have to wait for 3.3 since we
> missed the pre-beta window.

Ok.

This is my first patch to Python, so I'm not sure what I should do to get this in.

Is keeping the patch in sync with the trunk enough? Is there something else, like some more formal process to follow?
msg124462 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-21 21:46
Nope, you've got it.

After the final release of Python 3.2, please post to the issue to remind us about it, and someone will commit the patch.  (For future Python releases we expect that the delays in our ability to commit feature patches will be much shorter, but this is the way it works right now.)
msg130098 - (view) Author: Mathieu Bridon (bochecha) * Date: 2011-03-05 03:42
So, now that Python 3.2 was released, here is a patch rebased on top of the py3k branch.
msg130099 - (view) Author: Mathieu Bridon (bochecha) * Date: 2011-03-05 03:44
The sys module is imported in glob but never used.

It's not related to this feature request but I saw it when implementing the patch, so here is a second patch removing the import.
msg130506 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-03-10 13:45
I removed the unused import (mostly as a simple test of mercurial, it's my first commit there).
msg131613 - (view) Author: Mathieu Bridon (bochecha) * Date: 2011-03-21 04:21
> "I removed the unused import (mostly as a simple test of mercurial, it's my first commit there)."

Does it mean that Python development is not being done in SVN, as the documentations state it?

My patches have all been based on the SVN py3k branch, please tell me if I must base them on something else instead.
msg131622 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-03-21 08:48
Yes, we recently switched to Mercurial. See http://docs.python.org/devguide/faq.html

You shouldn't need to change your patches just because of the switch from svn.
msg135558 - (view) Author: Mathieu Bridon (bochecha) * Date: 2011-05-09 02:53
Is anybody still reading this? :-/

Could somebody commit the patch, reject it, or tell me what else I need to do?
msg135587 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2011-05-09 13:32
I've just rebuilt on Windows against tip. test_glob is failing:

test test_glob failed -- Traceback (most recent call last):
  File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line 135, in test_glob_curly_braces
    os.path.join('a', 'bcd', 'efg')]))
  File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line 53, in assertSequencesEqual_noorder
    self.assertEqual(set(l1), set(l2))
AssertionError: Items in the first set but not the second:
'@test_2788_tmp_dir\\a/bcd\\efg'
'@test_2788_tmp_dir\\a/bcd\\EF'
Items in the second set but not the first:
'@test_2788_tmp_dir\\a\\bcd\\EF'
'@test_2788_tmp_dir\\a\\bcd\\efg'
msg135588 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-05-09 14:04
+        if sub.find(',') != -1:
Please use the 'in' operator here.
msg174712 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2012-11-03 22:17
Help is still needed to debug the failing test_glob.py on Windows.

I just tried this patch against 3.4trunk.  The first hunk of the glob.py patch doesn't apply because 'for name in glob1(None, basename): yield name' was changed to 'yield from glob1(None, basename)'.  The tests still pass w/ Ezio's suggested change to use (',' in sub).
msg174879 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-05 08:40
I've got a patch for this which applies cleanly to the 3.4 tip. I still need to sort out the Windows issues (which I don't think will be difficult; it looks like a test issue, not a code issue)
msg174880 - (view) Author: Mathieu Bridon (bochecha) * Date: 2012-11-05 08:48
I have to apologize for not following up on this patch. At first I had no time to go on pushing for it, and then (after a change of job), I completely forgot about it. :(

I guess rebasing the patch on the latest tip is not that useful if you already have done it Tim, and I don't have access to a Windows box to figure out the issue in the tests.

At this point is there anything else I can do to help getting it integrated?
msg174882 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-05 09:06
I'm planning to refactor the tests and the code very slightly. When I've
got a reworked patch I'll ping it back to you to ensure it matches your
intent. IIUC you're implementing comma-separated lists {abc,def} and
nested braces {a{b,c}d,efg} but not ranges {a..z}.
msg174883 - (view) Author: Mathieu Bridon (bochecha) * Date: 2012-11-05 09:11
> " IIUC you're implementing comma-separated lists {abc,def} and nested braces {a{b,c}d,efg} but not ranges {a..z}."

Exactly.

Although that's just because at the time I sent the patch, I didn't know about ranges in shells.

So I just implemented the part of curly brace expansion that I knew of and felt would be useful.

If ranges are an expected feature from shells, then it would probably be a worthwhile addition.
msg174916 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-05 15:27
Attached is a refactored version of Mathieu's patch which, when applied to tip, passes all tests.
msg174919 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-05 16:58
Something went wrong with that patch; it doesn't include all the changes to test_glob. I'll upload a newer patch later.
msg174938 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-05 20:30
Scratch that last comment: the patch does apply. I've tested it against Windows & Ubuntu. If no one comes in with any objections I'll commit it within the next day.
msg174963 - (view) Author: Roundup Robot (python-dev) Date: 2012-11-06 13:56
New changeset dafca4714298 by Tim Golden in branch 'default':
issue9584: Add {} list expansion to glob. Original patch by Mathieu Bridon
http://hg.python.org/cpython/rev/dafca4714298
msg174974 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-06 15:06
>>> glob.glob('*.ac')
['configure.ac']
>>> glob.glob('*.sub')
['config.sub']
>>> glob.glob('*.{sub,ac}')
['config.sub']

And since these changes are backward incompatible (and moreover, now it is impossible to glob for paths that contain braces), I would prefer a keyword to switch this option (off by default) or a separate function.  See "man glob" [1] for flag GLOB_BRACE.

[1] http://linux.die.net/man/3/glob
msg174978 - (view) Author: Mathieu Bridon (bochecha) * Date: 2012-11-06 15:12
>>> glob.glob('*.{sub,ac}')
['config.sub']

I'm surprised this broke, this is one of the behaviour I thought I had implemented in my original patch. :-/

> (and moreover, now it is impossible to glob for paths that contain braces)

I am absolutely sure this was working in my original submission, I had even added unit tests for it:
+        # test some edge cases where braces must not be expanded
+        eq(self.glob('c{}d'), [self.norm('c{}d')])
+        eq(self.glob('c{d{e,f}g'), map(self.norm, ['c{deg', 'c{dfg']))
+        eq(self.glob('c{d,e}{f}g'), map(self.norm, ['cd{f}g', 'ce{f}g']))
+        eq(self.glob('c{d,e}f}g'), map(self.norm, ['cdf}g', 'cef}g']))
msg174980 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-06 15:14
Must have been something I did. I'll revert the commit and re-test.
msg174984 - (view) Author: Roundup Robot (python-dev) Date: 2012-11-06 15:38
New changeset ec897bb38708 by Tim Golden in branch 'default':
Reversed changes from issue9584
http://hg.python.org/cpython/rev/ec897bb38708
msg174991 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-06 16:37
> I am absolutely sure this was working in my original submission, I had even added unit tests for it:

It can't be working in any implementation.

>>> os.makedirs('a{b,c}d/e')
>>> os.listdir('a{b,c}d')
['e']
>>> glob.glob('a{b,c}d/*')
[]

Was ['a{b,c}d/e'] in 3.3.
msg174995 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-06 16:51
Well even in the original [working] version, the scope of this change
was limited to glob.glob. os.listdir doesn't currently support any form
of expansion (at least not on Windows) and nor does os.makedirs. I don't
see any problem in restricting this change -- and any future extensions
-- to glob.glob whose purpose is precisely to return one or more files
matching a, possibly wildcard, pattern.
msg174996 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-06 17:00
I'm talking about glob.glob(), not about os.listdir(). Bakward incompatible features should be off by default.
msg174997 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-06 17:08
Sorry, I misunderstood the point you were making with the
os.listdir/makedirs examples. Fair point about backwards compatibility.
This may make this change untenable as no-one will want a series of
use_feature_xxx flags, one for each change we introduce to glob.glob.
Unless we throw in every known expansion / matching right now and have a
single use-extended-features flag.
msg175001 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-06 19:22
> This may make this change untenable as no-one will want a series of
> use_feature_xxx flags, one for each change we introduce to glob.glob.
> Unless we throw in every known expansion / matching right now and have a
> single use-extended-features flag.

This is another question.  glob.glob(pattern, glob.GLOB_XXX | glob.GLOB_YYY) looks not much shorter than glob.glob(pattern, use_xxx=True, use_yyy=True).  And not all features can be configured by only one bit.  See os.access() and os.utime() as examples for many options.  I hope that before 3.4 feature freeze we can change the interface, if needed.

I also believe that this feature may not be regarded as mature without any sort of escaping (which also should be off by default for compatibility).  And we need glob.escape() function for escaping arbitrary path.

Since it is quite a complicated function, we need more examples in the documentation, which show different corner cases, nesting  and interaction with wildcards.
msg175190 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-11-08 21:21
Given the backward compatibility concerns, and the fact that brace expansion and wildcard expansion are conceptually separate operations, perhaps what we should have a is a glob.expand_braces (or some such name) function?  (Note: I haven't looked at whether or not this would actually work as an API, I'm just throwing out an idea.)
msg175193 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-08 22:03
> Given the backward compatibility concerns, and the fact that brace expansion and wildcard expansion are conceptually separate operations, perhaps what we should have a is a glob.expand_braces (or some such name) function?

In this case it may be appropriate to place this function into shutil or string module.
msg175217 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-11-09 08:06
Given that this isn't going to go ahead in its current form, and will need wider discussion on python-dev, I'm unassigning myself and I've removed the flawed version of the patch which I'd posted.
History
Date User Action Args
2013-02-22 18:06:51Juliansetnosy: + Julian
2012-12-23 16:46:47ysangkoksetnosy: + ysangkok
2012-11-24 11:26:27serhiy.storchakasetstage: patch review ->
2012-11-09 08:06:50tim.goldensetassignee: tim.golden ->
messages: + msg175217
2012-11-09 08:02:41tim.goldensetfiles: - 0003-reworked-issue9584.patch
2012-11-08 22:03:30serhiy.storchakasetmessages: + msg175193
2012-11-08 21:21:28r.david.murraysetmessages: + msg175190
2012-11-06 19:22:35serhiy.storchakasetmessages: + msg175001
2012-11-06 17:08:14tim.goldensetmessages: + msg174997
2012-11-06 17:00:06serhiy.storchakasetmessages: + msg174996
2012-11-06 16:51:08tim.goldensetmessages: + msg174995
2012-11-06 16:37:01serhiy.storchakasetmessages: + msg174991
2012-11-06 15:38:22python-devsetmessages: + msg174984
2012-11-06 15:14:46tim.goldensetmessages: + msg174980
2012-11-06 15:12:52bochechasetmessages: + msg174978
2012-11-06 15:06:18serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg174974
2012-11-06 13:56:02python-devsetnosy: + python-dev
messages: + msg174963
2012-11-05 20:30:52tim.goldensetmessages: + msg174938
2012-11-05 16:58:05tim.goldensetmessages: + msg174919
2012-11-05 15:27:39tim.goldensetfiles: + 0003-reworked-issue9584.patch

messages: + msg174916
2012-11-05 09:11:55bochechasetmessages: + msg174883
2012-11-05 09:06:21tim.goldensetmessages: + msg174882
2012-11-05 08:48:23bochechasetmessages: + msg174880
2012-11-05 08:40:14tim.goldensetassignee: tim.golden
messages: + msg174879
2012-11-03 22:17:30akuchlingsetnosy: + akuchling
messages: + msg174712
2012-11-03 22:05:08akuchlingsetversions: + Python 3.4, - Python 3.3
2011-05-09 14:04:55ezio.melottisetnosy: + ezio.melotti
messages: + msg135588
2011-05-09 13:32:24tim.goldensetmessages: + msg135587
2011-05-09 02:53:10bochechasetmessages: + msg135558
2011-03-21 08:48:26eric.smithsetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg131622
2011-03-21 04:21:25bochechasetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg131613
2011-03-10 13:45:57eric.smithsetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg130506
2011-03-05 03:44:24bochechasetfiles: + 0002-Remove-unused-import.patch
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg130099
2011-03-05 03:43:00bochechasetfiles: - 0001-Curly-brace-expansion-in-glob.patch
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
2011-03-05 03:42:35bochechasetfiles: + 0001-Curly-brace-expansion-in-glob.patch
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg130098
2010-12-21 21:46:58r.david.murraysetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg124462
2010-12-21 21:42:25bochechasetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg124461
2010-12-21 21:30:00r.david.murraysetnosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg124459
versions: + Python 3.3, - Python 3.2
2010-12-21 08:45:36bochechasetfiles: + 0001-Curly-brace-expansion-in-glob.patch
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg124423
2010-12-21 08:44:57bochechasetfiles: - 0001-Curly-brace-expansion-in-glob.patch.old
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
2010-12-21 08:44:13bochechasetfiles: + 0001-Curly-brace-expansion-in-glob.patch.old
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
messages: + msg124422
2010-12-21 08:43:37bochechasetfiles: - 0001-Curly-brace-expansion-in-glob.patch
nosy: fdrake, ronaldoussoren, pitrou, eric.smith, tim.golden, kveretennicov, eric.araujo, r.david.murray, bochecha
2010-11-28 03:40:21eric.araujosetmessages: + msg122614
2010-10-31 20:47:39bochechasetfiles: - curly-fnmatch.patch
2010-10-31 20:47:15bochechasetfiles: + 0001-Curly-brace-expansion-in-glob.patch

messages: + msg120082
title: Allow curly braces in fnmatch -> Allow curly brace expansion
2010-09-27 20:39:42kveretennicovsetnosy: + kveretennicov
2010-08-17 20:26:02terry.reedysetresolution: rejected ->
stage: resolved -> patch review
2010-08-17 13:18:39fdrakesetnosy: + fdrake
messages: + msg114119
2010-08-17 13:08:23ronaldoussorensetnosy: + ronaldoussoren
messages: + msg114115
2010-08-14 13:45:52eric.araujosetmessages: + msg113897
2010-08-14 11:29:25bochechasetmessages: + msg113888
2010-08-13 15:46:06tim.goldensetnosy: + tim.golden
messages: + msg113789
2010-08-13 15:37:55r.david.murraysetmessages: + msg113787
2010-08-13 13:49:45pitrousetmessages: + msg113773
2010-08-13 13:27:29r.david.murraysetmessages: + msg113767
2010-08-13 13:11:23eric.smithsetnosy: + eric.smith
messages: + msg113766
2010-08-13 13:08:25pitrousetstatus: pending -> open

messages: + msg113765
2010-08-13 13:03:50r.david.murraysetstatus: open -> pending
resolution: rejected
messages: + msg113762

stage: patch review -> resolved
2010-08-13 12:34:23eric.araujosetnosy: + eric.araujo
messages: + msg113758
2010-08-13 12:05:54r.david.murraysetversions: + Python 3.2
nosy: + r.david.murray

messages: + msg113756

stage: patch review
2010-08-13 10:23:12pitrousetnosy: + pitrou
messages: + msg113753
2010-08-13 08:41:11bochechasetmessages: + msg113751
2010-08-13 08:36:51bochechacreate