Ben Finney wrote:
>
> Not that I want to pick on you; I just don't want something wrong
> labelled as "proper" to go unchallenged in the archives :-)
Oh gawd :-P
I swear I have it right in the actual file! heh.
Copy and paste something that's compiled kids, copy and paste.
--
http://mail.pytho
Gordon Airporte <[EMAIL PROTECTED]> writes:
> The actual code uses the proper 'if foo in line or if bar in line:'
> form.
>>> line = "spam eggs ham"
>>> foo = "spam"
>>> bar = "sausage"
>>> if foo in line or if bar in line:
File "", line 1
if foo in line or if bar in
Gordon Airporte wrote:
> Yes, that's pseudo code even though I didn't really mean it that way
> when I typed it. The actual code uses the proper 'if foo in line or if
> bar in line:' form.
>
One 'if' too many.
/W
--
http://mail.python.org/mailman/listinfo/python-list
Miles wrote:
> On 7/24/07, Gordon Airporte <[EMAIL PROTECTED]> wrote:
>> I did already find that it speeds things up to pre-test a line like
>>
>> if 'bets' or 'calls' or 'raises' in line:
>> run the appropriate re's
>
> Be careful: unless this is just pseudocode, this Python doesn't do
>
Gordon Airporte <[EMAIL PROTECTED]> writes:
> I did already find that it speeds things up to pre-test a line like
>
> if 'bets' or 'calls' or 'raises' in line:
> run the appropriate re's
>
> which isn't very pretty at all
Nor does it work the way you might suppose:
>>> line = "foo ca
En Wed, 25 Jul 2007 00:02:51 -0300, Gordon Airporte <[EMAIL PROTECTED]>
escribió:
> Gabriel Genellina wrote:
>
>> As is often the case, a regular expression is NOT the right tool to use
>> in this case.
>
> Very interesting, thank you. I think 'pattern matching' and I
> automatically think 'regu
On 7/24/07, Gordon Airporte <[EMAIL PROTECTED]> wrote:
> I did already find that it speeds things up to pre-test a line like
>
> if 'bets' or 'calls' or 'raises' in line:
> run the appropriate re's
Be careful: unless this is just pseudocode, this Python doesn't do
what you think it does; i
Gabriel Genellina wrote:
> As is often the case, a regular expression is NOT the right tool to use
> in this case.
>
> --Gabriel Genellina
Very interesting, thank you. I think 'pattern matching' and I
automatically think 'regular expressions'.
I did already find that it speeds things up to pre
En Tue, 24 Jul 2007 00:23:46 -0300, Gordon Airporte <[EMAIL PROTECTED]>
escribió:
> [EMAIL PROTECTED] wrote:
>> if your search is not overly complicated, i think regexp is not
>> needed. if you want, you can post a sample what you want to search,
>> and some sample input.
>
> I'm afraid it's pre
[EMAIL PROTECTED] wrote:
> if your search is not overly complicated, i think regexp is not
> needed. if you want, you can post a sample what you want to search,
> and some sample input.
I'm afraid it's pretty complicated :-). I'm doing analysis of hand
histories that online poker sites leave for
On Jul 19, 12:52 pm, Gordon Airporte <[EMAIL PROTECTED]> wrote:
> I have some code which relies on running each line of a file through a
> large number of regexes which may or may not apply. For each pattern I
> want to match I've been writing
>
> gotit = mypattern.findall(line)
> if gotit:
>
[EMAIL PROTECTED] wrote:
> Have you read and understood what MULTILINE means in the manual
> section on re syntax?
>
> Essentially, you can make a single pattern which tests a match against
> each line.
>
> -- Michael Dillon
No, I have not looked into this - thank you. RE's are hard enough to g
On 19 Jul, 05:52, Gordon Airporte <[EMAIL PROTECTED]> wrote:
> I have some code which relies on running each line of a file through a
> large number of regexes which may or may not apply.
Have you read and understood what MULTILINE means in the manual
section on re syntax?
Essentially, you can ma
On 7/19/07, Gordon Airporte <[EMAIL PROTECTED]> wrote:
I have some code which relies on running each line of a file through a
large number of regexes which may or may not apply. For each pattern I
want to match I've been writing
gotit = mypattern.findall(line)
Try to use iterator function f
On Jul 18, 6:52 pm, Gordon Airporte <[EMAIL PROTECTED]> wrote:
> ...
> I've also been assuming that using the re functions that create match
> objects is slower/heavier than dealing with the simple list returned by
> findall(). I've profiled it and these matches are the biggest part of
> the runni
I have some code which relies on running each line of a file through a
large number of regexes which may or may not apply. For each pattern I
want to match I've been writing
gotit = mypattern.findall(line)
if gotit:
gotit = gotit[0]
...do whatever else...
This seems kind of clun
16 matches
Mail list logo
