New to Python

s = f.readline()
if 'mystring' in s: print 'foundit'
if 'mystring' not in s: print 'not found'
if 'mystring' in s:
print 'processing'

this generates output:
not found
processing

so, it doesn't find the substring, but goes into processing code anyway.

This is using IronPython

In <14Cdnb6rubmdUOzWnZ2dnUVZ_gadnZ2d@posted.grandecom > "Quin" <quindennis@grandecom.net> writes:

> s = f.readline()
> if 'mystring' in s: print 'foundit'
> if 'mystring' not in s: print 'not found'
> if 'mystring' in s:
> print 'processing'

> this generates output:
> not found
> processing

> so, it doesn't find the substring, but goes into processing code anyway.

I got this output when f contained 'mystring':

foundit
processing

And this output when f did not contain 'mystring':

notfound

I have no idea why it would have worked otherwise for you. When you posted
your question, did you type the code by hand? Perhaps you made a mistake.

--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

Quin wrote:
> s = f.readline()
> if 'mystring' in s: print 'foundit'
> if 'mystring' not in s: print 'not found'
> if 'mystring' in s:
> print 'processing'
>
> this generates output:
> not found
> processing
>
> so, it doesn't find the substring, but goes into processing code anyway.
>
> This is using IronPython
The code you povided works as expected.

Copy paste the exact code

JM

Quin wrote:
> s = f.readline()
> if 'mystring' in s: print 'foundit'
> if 'mystring' not in s: print 'not found'
> if 'mystring' in s:
> print 'processing'
>
> this generates output:
> not found
> processing
>
> so, it doesn't find the substring, but goes into processing code anyway.
>
> This is using IronPython

As others have already said, this _does_ work properly.

But a minor rearrangement is simpler, and IMHO clearer:

if 'mystring' not in s:
print 'not found'
else:
print 'foundit'
print 'processing'

-=- Larry -=-

Thanks guys, I'm thinking it's a problem with IronPython. I'm switching to
PyScripter and will test tomorrow.

"Larry Hudson" <orgnut@yahoo.com> wrote in message
news:ybmdnRFZZ_3nvu_WnZ2dnUVZ_hGdnZ2d@giganews.com ...
> Quin wrote:
>> s = f.readline()
>> if 'mystring' in s: print 'foundit'
>> if 'mystring' not in s: print 'not found'
>> if 'mystring' in s:
>> print 'processing'
>>
>> this generates output:
>> not found
>> processing
>>
>> so, it doesn't find the substring, but goes into processing code anyway.
>>
>> This is using IronPython
>
> As others have already said, this _does_ work properly.
>
> But a minor rearrangement is simpler, and IMHO clearer:
>
> if 'mystring' not in s:
> print 'not found'
> else:
> print 'foundit'
> print 'processing'
>
> -=- Larry -=-

Larry Hudson wrote:
> But a minor rearrangement is simpler, and IMHO clearer:
>
> if 'mystring' not in s:
> print 'not found'
> else:
> print 'foundit'
> print 'processing'

I've always vacillated on whether that would better be written as
Larry does, or as

if 'mystring' in s
print 'foundit'
print 'processing'
else:
print 'not found'

removing the "not" from the condition. I admit I choose one over
the other based on some gut-feeling aesthetic that I can't really
nail down. I think one of my major influencing factors revolves
around the negative "not" portion having one or two lines and the
positive portion having a large block of code. If the
code-blocks are more equal in size, I tend to use "if
{positive}", but if the negative "not" section is only 1-2 lines,
I tend to do as Larry writes and make it harder to miss by using
"if {negative}". Otherwise the "if {positive}...else" can end up
sufficiently distant from the "if" that it's easy to miss.

Any thoughts on how others make the choice?

-tkc

Quin wrote:
> Thanks guys, I'm thinking it's a problem with IronPython. I'm switching
> to PyScripter and will test tomorrow.
>
I'd be very surprised to find that something as basic as this was wrong
with IronPython. Complex commercial software has been built on it, so
there's little question that the platform is sound.

Are you *sure* you copied and pasted the session you listed?

regards
Steve

> "Larry Hudson" <orgnut@yahoo.com> wrote in message
> news:ybmdnRFZZ_3nvu_WnZ2dnUVZ_hGdnZ2d@giganews.com ...
>> Quin wrote:
>>> s = f.readline()
>>> if 'mystring' in s: print 'foundit'
>>> if 'mystring' not in s: print 'not found'
>>> if 'mystring' in s:
>>> print 'processing'
>>>
>>> this generates output:
>>> not found
>>> processing
>>>
>>> so, it doesn't find the substring, but goes into processing code anyway.
>>>
>>> This is using IronPython
>>
>> As others have already said, this _does_ work properly.
>>
>> But a minor rearrangement is simpler, and IMHO clearer:
>>
>> if 'mystring' not in s:
>> print 'not found'
>> else:
>> print 'foundit'
>> print 'processing'
>>
>> -=- Larry -=-
>


--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

* Tim Chase:
> Larry Hudson wrote:
>> But a minor rearrangement is simpler, and IMHO clearer:
>>
>> if 'mystring' not in s:
>> print 'not found'
>> else:
>> print 'foundit'
>> print 'processing'
>
> I've always vacillated on whether that would better be written as Larry
> does, or as
>
> if 'mystring' in s
> print 'foundit'
> print 'processing'
> else:
> print 'not found'
>
> removing the "not" from the condition. I admit I choose one over the
> other based on some gut-feeling aesthetic that I can't really nail
> down. I think one of my major influencing factors revolves around the
> negative "not" portion having one or two lines and the positive portion
> having a large block of code. If the code-blocks are more equal in
> size, I tend to use "if {positive}", but if the negative "not" section
> is only 1-2 lines, I tend to do as Larry writes and make it harder to
> miss by using "if {negative}". Otherwise the "if {positive}...else" can
> end up sufficiently distant from the "if" that it's easy to miss.
>
> Any thoughts on how others make the choice?

I think it spills over from the practice of checking preconditions first, e.g.
returning or raising exceptions or whatever.

This avoids silly n-level nesting of the main "normal case" part.


Cheers,

- Alf

On 02/10/10 03:36, Tim Chase wrote:
> Larry Hudson wrote:
>> But a minor rearrangement is simpler, and IMHO clearer:
>>
>> if 'mystring' not in s:
>> print 'not found'
>> else:
>> print 'foundit'
>> print 'processing'
>
> I've always vacillated on whether that would better be written as Larry
> does, or as
>
> if 'mystring' in s
> print 'foundit'
> print 'processing'
> else:
> print 'not found'

<cut>
>
> Any thoughts on how others make the choice?
>
I cases like this when aesthetics are not that much of a deal breaker, I
usually put the condition which I think will be the true the majority of
the time first.
This is not for performance reasons (never tested whether this has any
effect) but more documentation like purpose to go from a most expected
case to the least expected one. YMMV

--
mph

Well, PyScripter works find with that code. Furthermore, the
un-intellisense in IronPython was problematic, inserting the wrong things,
which I had to erase.

Also, there were some code constructs IronPython let pass that PyScripter
didn't, namely, print(), PyScripter requires the ()

Something simple, like:
n = -1
if n <> -1:
print('fell through')

falls through to the print.

So, I don't know what the problem is with IronPython, perhaps it isn't
compatible with Python v3, but on my machine, at least, it doesn't perform.

"Steve Holden" <steve@holdenweb.com> wrote in message
news:mailman.2272.1265774639.28905.python-list@python.org...
> Quin wrote:
>> Thanks guys, I'm thinking it's a problem with IronPython. I'm switching
>> to PyScripter and will test tomorrow.
>>
> I'd be very surprised to find that something as basic as this was wrong
> with IronPython. Complex commercial software has been built on it, so
> there's little question that the platform is sound.
>
> Are you *sure* you copied and pasted the session you listed?
>
> regards
> Steve
>
>> "Larry Hudson" <orgnut@yahoo.com> wrote in message
>> news:ybmdnRFZZ_3nvu_WnZ2dnUVZ_hGdnZ2d@giganews.com ...
>>> Quin wrote:
>>>> s = f.readline()
>>>> if 'mystring' in s: print 'foundit'
>>>> if 'mystring' not in s: print 'not found'
>>>> if 'mystring' in s:
>>>> print 'processing'
>>>>
>>>> this generates output:
>>>> not found
>>>> processing
>>>>
>>>> so, it doesn't find the substring, but goes into processing code
>>>> anyway.
>>>>
>>>> This is using IronPython
>>>
>>> As others have already said, this _does_ work properly.
>>>
>>> But a minor rearrangement is simpler, and IMHO clearer:
>>>
>>> if 'mystring' not in s:
>>> print 'not found'
>>> else:
>>> print 'foundit'
>>> print 'processing'
>>>
>>> -=- Larry -=-
>>
>
>
> --
> Steve Holden +1 571 484 6266 +1 800 494 3119
> PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
> Holden Web LLC http://www.holdenweb.com/
> UPCOMING EVENTS: http://holdenweb.eventbrite.com/
>

Quin wrote:
> Thanks guys, I'm thinking it's a problem with IronPython. I'm
> switching to PyScripter and will test tomorrow.
>
>
I'm willing to bet money that it is not. If ironPython had a broken if
statement, don't you think we would have known, already ?

There's a rule when test writing/testing code:
"if you think the compiler is wrong, then you are wrong twice."

JM

Well, now you know!

"Jean-Michel Pichavant" <jeanmichel@sequans.com> wrote in message
news:mailman.2286.1265797348.28905.python-list@python.org...
> Quin wrote:
>> Thanks guys, I'm thinking it's a problem with IronPython. I'm switching
>> to PyScripter and will test tomorrow.
>>
>>
> I'm willing to bet money that it is not. If ironPython had a broken if
> statement, don't you think we would have known, already ?
>
> There's a rule when test writing/testing code:
> "if you think the compiler is wrong, then you are wrong twice."
>
> JM

Quin wrote:
> Well, now you know!
>
> "Jean-Michel Pichavant" <jeanmichel@sequans.com> wrote in message
> news:mailman.2286.1265797348.28905.python-list@python.org...
>> Quin wrote:
>>> Thanks guys, I'm thinking it's a problem with IronPython. I'm
>>> switching to PyScripter and will test tomorrow.
>>>
>>>
>> I'm willing to bet money that it is not. If ironPython had a broken
>> if statement, don't you think we would have known, already ?
>>
>> There's a rule when test writing/testing code:
>> "if you think the compiler is wrong, then you are wrong twice."
>>
>> JM
>

All I know is that you are using a python implementation that does not
support python 3. No wonder why your py3 code fails.

Please do not top post.

JM


IronPython

* Stable Version is 2.0.3 (targeting Python 2.5)
* Developers Version is 2.6 Beta 3 (targeting Python 2.6)

On 10 February 2010 03:36, Tim Chase <python.list@tim.thechases.com> wrote:
> Any thoughts on how others make the choice?

There are two criteria that I use here. I'll often tend towards the
positive test; it's just that little bit easier to comprehend, I
think. On the other hand, if one case is overwhelmingly more common,
I'll usually put that first even if it does mean using a negative
test.

I'm not buying the short-case-first argument. If the code in a case
block is long enough for that to matter, it really belongs in a
function of its own anyway.

--
Cheers,
Simon B.

On 02/10/10 10:53, Jean-Michel Pichavant wrote:
> Quin wrote:
>> Well, now you know!
>>
<cut>
>
> All I know is that you are using a python implementation that does not
> support python 3. No wonder why your py3 code fails.
>
<cut>
You knew you known, you know :-)

--
mph