Bryan> We could define the __or__ method for RegExFlags, but really,
Bryan> or-ing together integer flags is old habit from low-level
Bryan> languages. Really we should pass a set of flags.
Good idea. Added to the Python3.0Suggestions wiki page:
http://wiki.python.org/moin/Pytho
Roy Smith wrote:
> LOL, and you'll be LOL too when you see the problem :-)
>
> You can't give the re.I flag to reCompiled.match(). You have to give
> it to re.compile(). The second argument to reCompiled.match() is the
> position where to start searching. I'm guessing re.I is defined as 2,
> wh
In article <[EMAIL PROTECTED]>,
Roy Smith <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Sam Pointon" <[EMAIL PROTECTED]> wrote:
>
> > Would this particular inconsistency be candidate for change in Py3k?
> > Seems to me the pos and endpos arguments are redundant with slicing,
>
In article <[EMAIL PROTECTED]>,
"Sam Pointon" <[EMAIL PROTECTED]> wrote:
> Would this particular inconsistency be candidate for change in Py3k?
> Seems to me the pos and endpos arguments are redundant with slicing,
> and the re.match function would benefit from having the same arguments
> as patt
On 3 Jan 2006 02:20:52 -0800, Sam Pointon <[EMAIL PROTECTED]> wrote:
> Would this particular inconsistency be candidate for change in Py3k?
> Seems to me the pos and endpos arguments are redundant with slicing,
Being able to specify the start and end indices for a search is
important when working
Would this particular inconsistency be candidate for change in Py3k?
Seems to me the pos and endpos arguments are redundant with slicing,
and the re.match function would benefit from having the same arguments
as pattern.match. Of course, this is a backwards-incompatible change;
that's why I suggest
> mike klaas <[EMAIL PROTECTED]> writes:
> Thanks guys, that is probably the most ridiculous mistake I've made in
> years
I was taken too :-). This is quite embarassing, considering that I remember
reading a big thread in python devel list about this a while back!
Ganesan
--
Ganesan Rajag
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Thanks guys, that is probably the most ridiculous mistake I've made in
> years
>
> -Mike
If that's the more ridiculous you can come up with, you're not trying hard
enough. I've done much worse.
--
http://mail.python.org/mailman/list
Thanks guys, that is probably the most ridiculous mistake I've made in
years
-Mike
--
http://mail.python.org/mailman/listinfo/python-list
> mike klaas <[EMAIL PROTECTED]> writes:
> In [48]: import re
> In [49]: reStr = r"([a-z]+)://"
> In [51]: against = "http://www.hello.com";
> In [53]: re.match(reStr, against).groups()
> Out[53]: ('http',)
> In [54]: re.match(reStr, against, re.I).groups()
> Out[54]: ('http',)
> In [55]: reCo
<[EMAIL PROTECTED]> wrote:
>
>Hello,
>
>Has anyone has issue with compiled re's vis-a-vis the re.I (ignore
>case) flag? I can't make sense of this compiled re producing a
>different match when given the flag, odd both in it's difference from
>the uncompiled regex (as I thought the uncompiled api w
On 2 Jan 2006 21:00:53 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Has anyone has issue with compiled re's vis-a-vis the re.I (ignore
> case) flag? I can't make sense of this compiled re producing a
> different match when given the flag, odd both in it's difference from
> the uncompile
Hello,
Has anyone has issue with compiled re's vis-a-vis the re.I (ignore
case) flag? I can't make sense of this compiled re producing a
different match when given the flag, odd both in it's difference from
the uncompiled regex (as I thought the uncompiled api was a wrapper
around a compile-and-
13 matches
Mail list logo
