In the 2.7 docs, re.compile has this signature:

  re.compile(pattern[, flags])

From here it isn't clear what the default value of 'flags' is, to be able to write code like this:

  re.compile(pattern, re.I if options['ignore_case'] else <WHAT??>)

Of course, looking at the source shows immediately that the default flag value is 0 (which is kind-of implied by the flags being a bit-OR of flags, but not mentioned explicitly).

I saw that in the latest 3K docs, it is documented properly:

  re.compile(pattern, flags=0)

Naturally this applies to other methods of 're' that take 'flags'.

I hope I'm not missing something and this really is just a documentation issue. If no objections arise, I will commit a fix to the docs of 're' in 2.7

I don't think you are missing anything, but using ints instead of flags is discouraged (see #11957).  OTOH there's no re.NOFLAGS flag that can be used instead.

Two more things:
 1) Python 2 doc used to use the func(arg[, optional1[, optional2]]) notation, and with Python 3 we switched to func(arg, optional1=default1, optional2=default2).  The latter is also used in Python 2 now, and the [] are still there in Python 3 in some places;
 2) If you are going to fix it, you can probably backport the fix from py3k with "hg diff Doc/library/re.rst -c 106ee4eb5970";

Ezio,

"but using ints instead of flags is discouraged (see #11957).  OTOH there's no re.NOFLAGS flag that can be used instead."

Indeed, there's no re.NOFLAGS, and as I mentioned the 3k docs mention 0 as the default value, thus (in a way) encouraging passing the numeric value. 

Perhaps re.NOFLAGS should be added (at least in 3.3)? The docs can then be modified to specify it as the default value of 'flags' instead of 0.

Regarding backporting 106ee4eb5970 - it's probably a good thing to do but I wouldn't mix it with this issue.

+1 to backporting [flags=0].

New changeset 02e4d3ebbb02 by Eli Bendersky in branch '2.7':
Issue #12875: explicitly specify default value of the optional 'flags' argument to re.* functions. Closes #12875
http://hg.python.org/cpython/rev/02e4d3ebbb02

The documentation now shows::
    match(pattern, string[, flags=0])
Is it normal to have the brackets *and* the default value?

No, it's not.

Amaury & Georg,

Grepping through the docs disagrees with your claims ;-) Try to grep for "\=None\]" to see what I mean. There are tons of places where default values are placed inside the brackets. For example in http://docs.python.org/library/csv.html --> look at:

    sniff(sample[, delimiters=None])

or even:

    class csv.DictReader(csvfile[, fieldnames=None[, restkey=None[, restval=None[, dialect='excel'[, *args, **kwds]]]]])

That said, I have absolutely no objections to following an accepted convention. But what is it?

I looked around, and found the following in the documentation guide:

http://docs.python.org/dev/py3k/documenting/fromlatex.html

    There is no optional command. Just give function signatures 
    like they should appear in the output:

    .. function:: open(filename[, mode[, buffering]])

       Description.

This (taken from the 3.3 guide) mentions the 2.x guideline and doesn't mention default values.

So what should I do here? According to Ezio's earlier message, the new style (without brackets) is also being used in Python 2 now. I can do the switch for the 're' module, but can we first get the convention documented somewhere?

> but can we first get the convention documented somewhere?

+1
This was on my todo list, but feel free to open a new issue about it.

> Grepping through the docs disagrees with your claims 

That's because is not documented and not everyone is aware of the conventions and how/where they should be followed.

Ezio, what do you suggest to do regarding *this* issue?

I suggest removing the [].

Hmm, I've just notice that this [default=val] pattern already exists in the 're' docs in 2.7, for example:

  subn(repl, string[, count=0])

So my change was consistent within the documentation of this module.

No doubt, the conventions are currently a mess ;-)

I suggest to just convert the whole 're' RST page to the new 3.x convention (i.e. model it after the same RST in the default branch). Is this acceptable? If yes, I will submit a patch for review first.

I created #13386 about the conventions that should be followed in the doc.

Converting the whole page is fine with me.

I have converted the Doc/library/re.rst doc of 2.7 to follow the new convention of 3.x, patch attached.

This patch looks fine.

LGTM

New changeset 87ecfd5cd5d1 by Eli Bendersky in branch '2.7':
Normalize the keyword arguments documentation notation in re.rst. Closes issue #12875
http://hg.python.org/cpython/rev/87ecfd5cd5d1