Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #33566 > unrolled thread

re.search when used within an if/else fails

Back to article view | Back to comp.lang.python

Contents

  re.search when used within an if/else fails Kevin T <kevinintx@gmail.com> - 2012-11-19 15:43 -0800
    Re: re.search when used within an if/else fails MRAB <python@mrabarnett.plus.com> - 2012-11-20 01:21 +0000
    Re: re.search when used within an if/else fails Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-20 01:24 +0000
      Re: re.search when used within an if/else fails Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-20 01:29 +0000
        Re: re.search when used within an if/else fails Kevin T <kevinintx@gmail.com> - 2012-11-20 11:09 -0800
          Re: re.search when used within an if/else fails Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-20 12:37 -0700
            Re: re.search when used within an if/else fails Kevin T <kevinintx@gmail.com> - 2012-11-21 08:41 -0800
              Re: re.search when used within an if/else fails Chris Angelico <rosuav@gmail.com> - 2012-11-22 16:00 +1100
                Re: re.search when used within an if/else fails Kevin T <kevinintx@gmail.com> - 2012-11-28 11:39 -0800
                  Re: Re: re.search when used within an if/else fails Evan Driscoll <driscoll@cs.wisc.edu> - 2012-11-28 14:08 -0600
                    Re: re.search when used within an if/else fails Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-28 21:39 +0000
                      Re: re.search when used within an if/else fails Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-28 19:20 -0500
                        Re: re.search when used within an if/else fails Duncan Booth <duncan.booth@invalid.invalid> - 2012-11-29 09:34 +0000
                      Re: re.search when used within an if/else fails Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-29 13:38 -0500
                      RE: re.search when used within an if/else fails "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-29 22:57 +0000
                      RE: re.search when used within an if/else fails "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-29 22:53 +0000
                Re: re.search when used within an if/else fails Kevin T <kevinintx@gmail.com> - 2012-11-28 11:39 -0800
                  Re: re.search when used within an if/else fails Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-28 20:50 +0000
          Re: re.search when used within an if/else fails Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-20 12:39 -0700

#33566 — re.search when used within an if/else fails

python version 2.4.3, yes i know that it is old.  getting the sysadmin to update the OS requires a first born.

with the following code..
                for signal in register['signals'] :

351                   sigName = signal['functionName']
352                   if re.search( "rsrvd", sigName ) == None :
353                      print sigName
354                      newVal = "%s%s" % ( '1'*signal['bits'] , newVal ) #prepend 0's
355                   if re.search( "rsrvd", sigName ) != None :
356                      print sigName
357                      newVal = "%s%s" % ( '0'*signal['bits'], newVal )

regardless of how i code line 352, i can not EVER use an else clause with it.  if i use an else clause, the else will NEVER get executed...

has any one experienced anything like this behavior?  any suggestions?  the above code works but... why should i have to code it like this?

kevin

[toc] | [next] | [standalone]

#33575

On 2012-11-19 23:43, Kevin T wrote:
> python version 2.4.3, yes i know that it is old.  getting the sysadmin to update the OS requires a first born.
>
> with the following code..
>                  for signal in register['signals'] :
>
> 351                   sigName = signal['functionName']
> 352                   if re.search( "rsrvd", sigName ) == None :
> 353                      print sigName
> 354                      newVal = "%s%s" % ( '1'*signal['bits'] , newVal ) #prepend 0's
> 355                   if re.search( "rsrvd", sigName ) != None :
> 356                      print sigName
> 357                      newVal = "%s%s" % ( '0'*signal['bits'], newVal )
>
> regardless of how i code line 352, i can not EVER use an else clause with it.  if i use an else clause, the else will NEVER get executed...
>
> has any one experienced anything like this behavior?  any suggestions?  the above code works but... why should i have to code it like this?
>
Have you checked the indentation? There may be a mixture of tabs and spaces.

A couple of points:

1. You should be using "is None" and "is not None" instead of "== None" 
and "!= None".

2. You don't need to use regex. Use "rsrvd" in sigName and "rsrvd" not 
in sigName.

[toc] | [prev] | [next] | [standalone]

#33576

On Mon, 19 Nov 2012 15:43:10 -0800, Kevin T wrote:

> python version 2.4.3, yes i know that it is old.  getting the sysadmin
> to update the OS requires a first born.
> 
> with the following code..
>                 for signal in register['signals'] :
> 
> 351                   sigName = signal['functionName'] 352              
>     if re.search( "rsrvd", sigName ) == None : 353                     
> print sigName 354                      newVal = "%s%s" % (
> '1'*signal['bits'] , newVal ) #prepend 0's 355                   if
> re.search( "rsrvd", sigName ) != None : 356                      print
> sigName 357                      newVal = "%s%s" % ( '0'*signal['bits'],
> newVal )


Your code is mangled to the point of unreadability. 

Please resend, and make sure you send it as PLAIN TEXT and not as HTML 
("rich text"), since many mail programs feel that they are allowed to 
arbitrarily rewrap HTML text however they like.

Preferably simplify your example to the simplest example that we can run:

http://sscce.org/

Being able to run it means you shouldn't put line numbers on the left. If 
you must draw our attention to a specific line, use a comment. This isn't 
1975 and we're not programming in BASIC.

# BAD don't do this:
350  do_this(x)
351  do_that(y, z)
352  if something:
353      do_something_else(x, y, z)


# GOOD do this:
do_this(x)
do_that(y, z)
if something:   # LINE 352
    do_something_else(x, y, z)




> regardless of how i code line 352, i can not EVER use an else clause
> with it.  if i use an else clause, the else will NEVER get executed...

The code you show doesn't actually have an `else` clause, which might 
explain why it doesn't get executed.

By the way, you should not write "if something == None", always use "if 
something is None" or "is not None". Technically, there are some 
exceptions but if you have to ask what they are, you don't need to know 
*wink*



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#33577

On Tue, 20 Nov 2012 01:24:54 +0000, Steven D'Aprano wrote:

> Your code is mangled to the point of unreadability.

Ah, never mind, that's *my* fault, not yours. Or rather, my news reader 
software. Sorry about the noise.

The rest of my post still stands:


- simplify your example to the simplest example that we can run
  http://sscce.org/

- don't put line numbers at the start of lines

- your code doesn't have an else clause

- use "if something is None", not == None.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#33646

On Monday, November 19, 2012 7:29:20 PM UTC-6, Steven D'Aprano wrote:
> On Tue, 20 Nov 2012 01:24:54 +0000, Steven D'Aprano wrote:
> 
> 
> 
> - use "if something is None", not == None.
> 
> 
> Steven

i will not include line #'s in the future, point taken
i will change ==/!= to is/is not as most people pointed out.

there is no else because it doesn't work.

i used eclipse in debug mode and a command line execution of the code, both behave the same way

#if re.search( "rsrvd", sigName ) :   #version a
#if re.search( "rsrvd", sigName ) == None :   #version b
if re.search( "rsrvd", sigName ) is None :   #version bb
   print sigName 
   newVal = "%s%s" % ('1'*signal['bits'] , newVal ) 
#else:                                 #version c
if re.search( "rsrvd", sigName ) != None :   #version d
   print sigName 
   newVal = "%s%s" % ( '0'*signal['bits'],> newVal ) 

i can use either version a/b the else clause (version c) will not execute.
fortunately,  with version bb, the else clause will execute!!  

thanks for the input all..

kevin

Now if i change

[toc] | [prev] | [next] | [standalone]

#33649

On Tue, Nov 20, 2012 at 12:09 PM, Kevin T <kevinintx@gmail.com> wrote:
> #if re.search( "rsrvd", sigName ) :   #version a
> #if re.search( "rsrvd", sigName ) == None :   #version b
> if re.search( "rsrvd", sigName ) is None :   #version bb
>    print sigName
>    newVal = "%s%s" % ('1'*signal['bits'] , newVal )
> #else:                                 #version c
> if re.search( "rsrvd", sigName ) != None :   #version d
>    print sigName
>    newVal = "%s%s" % ( '0'*signal['bits'],> newVal )
>
> i can use either version a/b the else clause (version c) will not execute.
> fortunately,  with version bb, the else clause will execute!!

There must be some other difference in your testing.  I don't have
Python 2.4 available, but I tried your version a in both Python 2.3
and 2.5 using made-up values for sigName, and the else clause is
executed in both.

[toc] | [prev] | [next] | [standalone]

#33747

On Nov 20, 1:37 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 12:09 PM, Kevin T <kevini...@gmail.com> wrote:
> > #if re.search( "rsrvd", sigName ) :   #version a
> > #if re.search( "rsrvd", sigName ) == None :   #version b
> > if re.search( "rsrvd", sigName ) is None :   #version bb
> >    print sigName
> >    newVal = "%s%s" % ('1'*signal['bits'] , newVal )
> > #else:                                 #version c
> > if re.search( "rsrvd", sigName ) != None :   #version d
> >    print sigName
> >    newVal = "%s%s" % ( '0'*signal['bits'],> newVal )
>
> > i can use either version a/b the else clause (version c) will not execute.
> > fortunately,  with version bb, the else clause will execute!!
>
> There must be some other difference in your testing.  I don't have
> Python 2.4 available, but I tried your version a in both Python 2.3
> and 2.5 using made-up values for sigName, and the else clause is
> executed in both.

I went back and tried version a again, blam it is/does work now ?!?!?
I am not sure what changed but version a was the original code that
wouldn't work.  All the examples i had read, showed version a as a
working version.  I spent significant time trying version a with
parens, spacing changes, different regex values to no avail.  hence
the creation of all the other versions.

thanks for your help.

[toc] | [prev] | [next] | [standalone]

#33785

On Thu, Nov 22, 2012 at 3:41 AM, Kevin T <kevinintx@gmail.com> wrote:
> I went back and tried version a again, blam it is/does work now ?!?!?
> I am not sure what changed but version a was the original code that
> wouldn't work.  All the examples i had read, showed version a as a
> working version.  I spent significant time trying version a with
> parens, spacing changes, different regex values to no avail.  hence
> the creation of all the other versions.

This is why the Short, Self-Contained, Correct Example is so
important. See http://sscce.org/ for some info on that. I often find
myself stuck, begin typing up a post to some appropriate mailing list,
and while coalescing the problem into its smallest possible form, end
up finding the cause directly. More often than not, I end up
discarding the message unsent (though sometimes, I end up submitting a
patch to the language/library maintainers, eg improving the docs so
it's more visible next time). In any case, if you can copy and paste
the exact code and error, it's a lot easier for us to replicate your
problem.

ChrisA

[toc] | [prev] | [next] | [standalone]

#34030

I agree. Being relatively new to python, i was not sure of quirks so i posted the original code.  

I did find the real issue, as I found another loop that was not being executed properly.

It turns out that if the indent started with spaces and ended with tabs, neither eclipse or command line execution would complain.  where as if the indent begins with tabs and has spaces in the middle the tools will complain of indentation issues.

i have found that the vi plugin for python is the culprit here.  when the plugin does block indentation, the result is indents that begin with spaces.  if i disable the vi plugin and use the regular eclipse editor these issues go away.

with other languages i always expand tabs to spaces.  the vi plugin does do this properly.  if i change all indents to be spaces only will python behave?  i inherited a good deal of the code that i am using, which is tab based.

thanks kevin


On Wednesday, November 21, 2012 11:00:50 PM UTC-6, Chris Angelico wrote:
> On Thu, Nov 22, 2012 at 3:41 AM, Kevin T  wrote:
> 
> > I went back and tried version a again, blam it is/does work now ?!?!?
> 

> 
> 
> This is why the Short, Self-Contained, Correct Example is so
> 
> important. See http://sscce.org/ for some info on that. I often find
> 

[toc] | [prev] | [next] | [standalone]

#34032

[Multipart message — attachments visible in raw view] — view raw

On 11/28/2012 01:57 PM, Ian Kelly wrote:
> Yes, it's best to use either tabs-only or spaces-only.  Quoting from PEP
> 8 on the subject:
> 
>     Never mix tabs and spaces.
> 
>     The most popular way of indenting Python is with spaces only. The
>     second-most popular way is with tabs only. Code indented with a
>     mixture of tabs and spaces should be converted to using spaces
>     exclusively. When invoking the Python command line interpreter with
>     the -t option, it issues warnings about code that illegally mixes
>     tabs and spaces. When using -tt these warnings become errors. These
>     options are highly recommended!
> 
>     For new projects, spaces-only are strongly recommended over tabs.
>     Most editors have features that make this easy to do.
> 
> 
> I thought the prohibition against mixing tabs and spaces was made more
> strict in Python 3, but I can't find any reference to that now. 
> Probably I was mistaken.

I'm only entering this thread now so I'm not really in context, but
you're correct; in Python 3, -tt is set by default, which makes illegal
mixing an error.

However, not all mixing is illegal: what it means by "code that
illegally mixes tabs and spaces" is "code whose interpretation differs
depending upon the interpretation of the tab width". While I'm not going
to go test it, I think that if you, say, indent from the first to the
second level with tabs (consistently), indent from the second to third
level with spaces (consistently), and indent from the third to fourth
level with tabs (consistently), it should not complain. Or perhaps I
should say "it should complain that you're a bad person and should feel
bad, but it won't." :-) (In fact, you could indent one block at the
second level with tabs and another with spaces.)

Evan

[toc] | [prev] | [next] | [standalone]

#34038

On Wed, 28 Nov 2012 14:08:15 -0600, Evan Driscoll wrote:

> I'm only entering this thread now so I'm not really in context, but
> you're correct; in Python 3, -tt is set by default, which makes illegal
> mixing an error.
> 
> However, not all mixing is illegal: what it means by "code that
> illegally mixes tabs and spaces" is "code whose interpretation differs
> depending upon the interpretation of the tab width". While I'm not going
> to go test it, I think that if you, say, indent from the first to the
> second level with tabs (consistently), indent from the second to third
> level with spaces (consistently), and indent from the third to fourth
> level with tabs (consistently), it should not complain. 

Correct, which disappoints me. Testing with Python 3:

py> if True:
...     if True: # tab
...         pass  # tab, then four spaces
...
py>

I would prefer that the "pass" line would fail with an illegal indent, 
but it does not. But at least the following fails cleanly:


py> if True:
...     if True: # tab
...         pass  # tab, then four spaces
...         pass  # two spaces, tab, four spaces
  File "<stdin>", line 4
    pass  # two spaces, tab, four spaces
                                       ^
TabError: inconsistent use of tabs and spaces in indentation


> Or perhaps I
> should say "it should complain that you're a bad person and should feel
> bad, but it won't." :-) (In fact, you could indent one block at the
> second level with tabs and another with spaces.)

I don't mind different blocks using different indentation. You have 
always been able to do this:


py> if True:
...         pass  # eight spaces
...
py> if True:
...   pass  # two spaces
...
py>

If you don't like that, don't do it! Consistent indentation globally per 
file is a matter for coding conventions. However, I think that within a 
single block, Python should enforce "all tabs" or "all spaces".

Perhaps it would be nice if Python honoured a directive setting indent 
style to spaces or indents, as it honours source code encoding lines:

# -*- indent: <mode> -*-

Where <mode> could be one of:

space[s]	Only accept spaces in indentation
tab[s]		Only accept tabs in indentation
mixed		Accept "mixed" tabs and spaces, but only if consistent

with mixed the default for backward compatibility.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#34044

On 28 Nov 2012 21:39:03 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> On Wed, 28 Nov 2012 14:08:15 -0600, Evan Driscoll wrote:
> 
> > to go test it, I think that if you, say, indent from the first to the
> > second level with tabs (consistently), indent from the second to third
> > level with spaces (consistently), and indent from the third to fourth
> > level with tabs (consistently), it should not complain. 
> 
> Correct, which disappoints me. Testing with Python 3:
> 
> py> if True:
> ...     if True: # tab
> ...         pass  # tab, then four spaces
> ...
> py>
> 
> I would prefer that the "pass" line would fail with an illegal indent, 
> but it does not. But at least the following fails cleanly:
> 
> 
> py> if True:
> ...     if True: # tab
> ...         pass  # tab, then four spaces
> ...         pass  # two spaces, tab, four spaces
>   File "<stdin>", line 4
>     pass  # two spaces, tab, four spaces
>                                        ^
> TabError: inconsistent use of tabs and spaces in indentation
>

	Unless there has been a major change in the parser... (I still don't
have Python 3.x installed)

	I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
8...

	So the first is 8+4 => 12 spaces, the second is 2+8+4 => 14 spaces.

	Does 2 + <tab> + 2 vs 4 + <tab> vs <tab> + 4 succeed? That would
confirm the treatment. 

	The main concern with mixed tab and spaces, as I recall, was due to
having /editors/ and /terminals/ configured to show <tab> as a four
space (or anything other than an eight space) increment; so visually
four spaces and one <tab> might look the same... One user might have the
editor showing 4-space indents on <tab> but entering text using 4 spaces
on input -- which now is mis-aligned if the source file HAD <tab> in it.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#34058

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

>      Unless there has been a major change in the parser... (I still don't
> have Python 3.x installed)
> 
>      I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
> 8...
> 

Certainly in Python 2.7 that's not the case: the tab expands to the next 
multiple of 8 spaces.

>>> if 1:
...     print "yes" # space + tab
...         print "no" # eight spaces
...
yes
no

If tab expanded to exactly 8 spaces the leading space would have forced an 
indentation error, but it didn't.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#34074

On Wed, 28 Nov 2012 17:36:35 -0700, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following in gmane.comp.python.general:

> >
> >         I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
> > 8...
> >
> 
> Next multiple of 8 is correct, according to the docs:
>
	Okay, smarter than I thought...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#34079

Ramit Prasad wrote:
> 
> Dennis Lee Bieber wrote:
> >
> > 	Unless there has been a major change in the parser... (I still don't
> > have Python 3.x installed)
> >
> > 	I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
> > 8...
> 
> A tab is *one* character. Your *editor* may show tabs visually
> "expanded" or convert them to spaces. This is entirely editor dependent.
> My current (python) editor, does expands tabs to the next *multiple* of 4.
> It helps keep code aligned, and I have no need for 4 hard spaced tabs
> without regards to alignment (yet). I have had editors that did 4 hard
> spaced tabs, so it might be a developer/application preference.
> 
> >>> with open(r'c:\ramit\mix_tab_space.txt')as f:
> ...     d = f.read()
> ...
> >>> print repr(d)
> '\tblah\n    test\n\t'
> >>> print d[0] + 'goo'
> 	goo
> >>> print repr(d[0] + 'goo')
> '\tgoo'

Apologies, I missed that it was talking about the parser
and not editor/file. Please disregard my previous post. 


~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#34081

Dennis Lee Bieber wrote:
> 
> 	Unless there has been a major change in the parser... (I still don't
> have Python 3.x installed)
> 
> 	I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
> 8...

A tab is *one* character. Your *editor* may show tabs visually 
"expanded" or convert them to spaces. This is entirely editor dependent. 
My current (python) editor, does expands tabs to the next *multiple* of 4. 
It helps keep code aligned, and I have no need for 4 hard spaced tabs 
without regards to alignment (yet). I have had editors that did 4 hard 
spaced tabs, so it might be a developer/application preference.

>>> with open(r'c:\ramit\mix_tab_space.txt')as f:
...     d = f.read()
...
>>> print repr(d)
'\tblah\n    test\n\t'
>>> print d[0] + 'goo'
	goo
>>> print repr(d[0] + 'goo')
'\tgoo'

> 
> 	So the first is 8+4 => 12 spaces, the second is 2+8+4 => 14 spaces.
> 
> 	Does 2 + <tab> + 2 vs 4 + <tab> vs <tab> + 4 succeed? That would
> confirm the treatment.
> 
> 	The main concern with mixed tab and spaces, as I recall, was due to
> having /editors/ and /terminals/ configured to show <tab> as a four
> space (or anything other than an eight space) increment; so visually
> four spaces and one <tab> might look the same... One user might have the
> editor showing 4-space indents on <tab> but entering text using 4 spaces
> on input -- which now is mis-aligned if the source file HAD <tab> in it.


~Ramit



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#34031

I agree. Being relatively new to python, i was not sure of quirks so i posted the original code.  

I did find the real issue, as I found another loop that was not being executed properly.

It turns out that if the indent started with spaces and ended with tabs, neither eclipse or command line execution would complain.  where as if the indent begins with tabs and has spaces in the middle the tools will complain of indentation issues.

i have found that the vi plugin for python is the culprit here.  when the plugin does block indentation, the result is indents that begin with spaces.  if i disable the vi plugin and use the regular eclipse editor these issues go away.

with other languages i always expand tabs to spaces.  the vi plugin does do this properly.  if i change all indents to be spaces only will python behave?  i inherited a good deal of the code that i am using, which is tab based.

thanks kevin


On Wednesday, November 21, 2012 11:00:50 PM UTC-6, Chris Angelico wrote:
> On Thu, Nov 22, 2012 at 3:41 AM, Kevin T  wrote:
> 
> > I went back and tried version a again, blam it is/does work now ?!?!?
> 

> 
> 
> This is why the Short, Self-Contained, Correct Example is so
> 
> important. See http://sscce.org/ for some info on that. I often find
> 

[toc] | [prev] | [next] | [standalone]

#34033

On Wed, 28 Nov 2012 11:39:48 -0800, Kevin T wrote:

> with other languages i always expand tabs to spaces.  the vi plugin does
> do this properly.  if i change all indents to be spaces only will python
> behave?  i inherited a good deal of the code that i am using, which is
> tab based.

Python will behave correctly if you use all spaces, or all tabs, for 
indents. If you mix spaces and tabs, anything can happen.

For this reason, Python 3 is more strict and will raise an explicit error 
when it detects mixed spaces/tabs in an indent.

See also the tabnanny tool provided with Python:

[steve@ando ~]$ python -m tabnanny
Usage: /usr/local/lib/python2.7/tabnanny.py [-v] file_or_directory ...



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#33650

On Tue, Nov 20, 2012 at 12:37 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 12:09 PM, Kevin T <kevinintx@gmail.com> wrote:
>> #if re.search( "rsrvd", sigName ) :   #version a
>> #if re.search( "rsrvd", sigName ) == None :   #version b
>> if re.search( "rsrvd", sigName ) is None :   #version bb
>>    print sigName
>>    newVal = "%s%s" % ('1'*signal['bits'] , newVal )
>> #else:                                 #version c
>> if re.search( "rsrvd", sigName ) != None :   #version d
>>    print sigName
>>    newVal = "%s%s" % ( '0'*signal['bits'],> newVal )
>>
>> i can use either version a/b the else clause (version c) will not execute.
>> fortunately,  with version bb, the else clause will execute!!
>
> There must be some other difference in your testing.  I don't have
> Python 2.4 available, but I tried your version a in both Python 2.3
> and 2.5 using made-up values for sigName, and the else clause is
> executed in both.

It should be noted, however, that version a is the logical *inverse*
of both b and bb.  With version a, you're testing for the logical
truth of the re.search result; it will be true if it is *not* None.
With the other two you are testing that the result *is* None.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web