Don't run presubmit checks on python276_bin.

Don't run presubmit checks on python276_bin.

Actually, don't run presubmit checks on anything starting with
python and ending with _bin.

BUG=326975
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=240316

[Daniel Bratell, 2013-12-10 13:37:57]

Found the python directory hardcoded in another file as well. Now it seems to be
working better.

[Isaac (away), 2013-12-11 19:05:15]

https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py
File PRESUBMIT.py (right):

https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py#newcode18
PRESUBMIT.py:18: r'^python.*_bin[\/\\].+',
multiple .*'s considered harmful.  is this always a number?  if so lets use \d*,
else you could use [^_]* or [0-9a-z]*

Actually I'm not even sure the trailing .+'s are needed but we can leave them

[Daniel Bratell, 2013-12-12 08:20:56]

On 2013/12/11 19:05:15, Isaac wrote:
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py
> File PRESUBMIT.py (right):
> 
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py#newcode18
> PRESUBMIT.py:18: r'^python.*_bin[\/\\].+',
> \d*,

The line below used [0-9] so I used the same for consistency.

[Daniel Bratell, 2013-12-12 08:20:57]

On 2013/12/11 19:05:15, Isaac wrote:
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py
> File PRESUBMIT.py (right):
> 
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py#newcode18
> PRESUBMIT.py:18: r'^python.*_bin[\/\\].+',
> \d*,

The line below used [0-9] so I used the same for consistency.

[Daniel Bratell, 2013-12-12 08:21:57]

https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py
File PRESUBMIT.py (right):

https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py#newcode18
PRESUBMIT.py:18: r'^python.*_bin[\/\\].+',
On 2013/12/11 19:05:15, Isaac wrote:
> multiple .*'s considered harmful.  is this always a number?  if so lets use
\d*,
> else you could use [^_]* or [0-9a-z]*
> 
> Actually I'm not even sure the trailing .+'s are needed but we can leave them

I don't know anything except that people obviously forget to update this
whenever they update the python version. Maybe it will always be a number. Maybe
it won't. I choose to not just change 275 to 276 to avoid the same problem
happening again next time.

And while multiple branching points (like .*) could cause fun O(n^2) or worse
behaviour that only happens if you have a pretty naive regexp engine with a
simple backtracker, no optimizations and highly redundant, and carefully crafted
input so I wouldn't worry about it. (It's fun the things you learn by working on
a web browser for a while. ).

But I'll change it to \d and we can discuss regexp engines over a beer some
time. :-)

[Isaac (away), 2013-12-12 09:26:53]

lgtm, but I'm not an OWNER for depot_tools.

On 2013/12/12 08:21:57, Daniel Bratell wrote:
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py
> File PRESUBMIT.py (right):
> 
> https://codereview.chromium.org/111643002/diff/1/PRESUBMIT.py#newcode18
> PRESUBMIT.py:18: r'^python.*_bin[\/\\].+',
> On 2013/12/11 19:05:15, Isaac wrote:
> > multiple .*'s considered harmful.  is this always a number?  if so lets use
> \d*,
> > else you could use [^_]* or [0-9a-z]*
> > 
> > Actually I'm not even sure the trailing .+'s are needed but we can leave
them
> 
> I don't know anything except that people obviously forget to update this
> whenever they update the python version. Maybe it will always be a number.
Maybe
> it won't. I choose to not just change 275 to 276 to avoid the same problem
> happening again next time.
> 
> And while multiple branching points (like .*) could cause fun O(n^2) or worse
> behaviour that only happens if you have a pretty naive regexp engine with a
> simple backtracker, no optimizations and highly redundant, and carefully
crafted
> input so I wouldn't worry about it. (It's fun the things you learn by working
on
> a web browser for a while. ).

Thanks.  Patchset 1 was worst case O(n) because only the new wildcard will
backtrack, but agree we're unlikely to encounter long non-matching strings that
begin with 'python'.

While python regex is worst-case exponential, I've seen slow downs in this
codebase from a linear backtrack: re.match('.*pattern', very_large_string)

> 
> But I'll change it to \d and we can discuss regexp engines over a beer some
> time. :-)

Ping me if you're in SF :-)

[M-A Ruel, 2013-12-12 14:11:39]

lgtm

[commit-bot: I haz the power, 2013-12-12 14:11:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bratell@opera.com/111643002/20001

[commit-bot: I haz the power, 2013-12-12 14:13:46]

Change committed as 240316