New to Python
Quin
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
John Gordon
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
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
Jean-Michel Pichavant
Copy paste the exact code
JM
Larry Hudson
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 -=-
Quin
PyScripter and will test tomorrow.
"Larry Hudson" <org...@yahoo.com> wrote in message
news:ybmdnRFZZ_3nvu_W...@giganews.com...
Tim Chase
> 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
Cameron Simpson
I do it like you, usually: if one branch is small, it comes first, the other
branch is easily in sight under the "else". Otherwise, I tend to go with "if
{positive}", or at any rate "if {the easiest-to-read-form-of-the-test}" if it
all still reads well. If the program flow gets ugly one way, that breaks
"still reads well" and can be cause to flip the condition.
In loops my tendency is a bit less flexible; I often have code like
this:
while ...:
if winnowing-test:
whinge
set flag
continue or break, depending
main body of loop here...
Not a lot of choice about positive/negative in that scenario,
though it fits well with the first criterion.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
A Master is someone who started before you did. - Gary Zukav
Steve Holden
> Thanks guys, I'm thinking it's a problem with IronPython. I'm switching
> to PyScripter and will test tomorrow.
>
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" <org...@yahoo.com> wrote in message
> news:ybmdnRFZZ_3nvu_W...@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/
Alf P. Steinbach
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
Martin P. Hellwig
> 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
Quin
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" <st...@holdenweb.com> wrote in message
news:mailman.2272.1265774...@python.org...
Jean-Michel Pichavant
> Thanks guys, I'm thinking it's a problem with IronPython. I'm
> switching to PyScripter and will test tomorrow.
>
>
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
"Jean-Michel Pichavant" <jeanm...@sequans.com> wrote in message
news:mailman.2286.1265797...@python.org...
Jean-Michel Pichavant
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)
Simon Brunning
> 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.
Martin P. Hellwig
> Quin wrote:
>> Well, now you know!
>>
>
> All I know is that you are using a python implementation that does not
> support python 3. No wonder why your py3 code fails.
>
You knew you known, you know :-)
--
mph
Roy Smith
Tim Chase <pytho...@tim.thechases.com> wrote:
In general, I try to avoid negation, because it makes things harder to
understand. When you write:
if not foo:
blah
else:
blah-blah
the else clause is executed if "not foo is not true". That quickly gets
confusing.
As for the code blocks being so large that the else becomes distant from
the condition, that smells like the two codeblocks want to be refactored
into distinct functions:
if foo:
do_one_thing()
else:
do_something_else()
It's not always practical, but my first reaction would be to try that and
see if it works.
Quin
things weren't working. Do you still want to bet money that it is? I can
screenshot you TD.
"Jean-Michel Pichavant" <jeanm...@sequans.com> wrote in message
news:mailman.2288.1265799...@python.org...
Peter Otten
> You know, Jack, that was the point of my original post: to determine why
> things weren't working. Do you still want to bet money that it is? I can
> screenshot you TD.
You haven't posted the complete script, and you haven't given a thorough
description how you invoke that script.
To help us find an explanation for your problem and a possible fix please
make the script as small as you can while preserving its very strange
behaviour, open a DOS window and invoke the Ironpython interpreter manually
on the command line.
Finally copy and paste the output and the complete script and post it here
again.
Peter
Jean-Michel Pichavant
> You know, Jack, that was the point of my original post: to determine
> why things weren't working. Do you still want to bet money that it
> is? I can screenshot you TD.
>
IronPython implements python 2.5 and you're still complaining about your
py3 code not working.
Try your code in a ruby shell, and tell the ruby community that their
intepreter cannot even handle an if statement. Feel free to put my mail
address in cc.
So to be clear, IronPython can properly handle if statements. I'll bet
all your money on that.
Jack
Terry Reedy
> 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.
'<>' is not legal in Python3, so above is not Python3 code.
Ethan Furman
> Any thoughts on how others make the choice?
>
> -tkc
If one branch is only a few lines, it comes first. As often as not,
that tiny branch is checking for errors, and the "else" branch doesn't
need to be indented.
def func(arg1):
if arg1 is 'stupid':
raise ValueError("that's a stupid argument!")
do_something
do_something_else
etc, etc
~Ethan~
Gerald Britton
> http://mail.python.org/mailman/listinfo/python-list
>
Something similar in a for-loop:
for x in y:
if not should_process(x): continue
# process x
--
Gerald Britton
Carl Banks
> 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'
> Any thoughts on how others make the choice?
I almost always arrange it as follows, regardless of the size of the
blocks or whether the condition is negated or not:
if (typical-condition):
typical-case
else:
exceptional-case
In particular I almost always test if something is not None, because
being None is almost always the exceptional case:
if x is not None:
...
else:
...
However, whenever the exceptional case action is to break, return,
continue, or raise an exception, I'll test for it and leave the
typical case unnested:
if (exceptional-condition):
exceptional-case
typical-case
No, it deosn't bother me in the least that I sometimes test for the
exceptional case and sometimes for the typical.
Whenever there is no typical case or exceptional case I'll go for the
simpler condition.
Carl Banks
J. Cliff Dyer
>
> The original code:
>
>
> s = f.readline()
> if 'mystring' in s: print 'foundit'
> if 'mystring' not in s: print 'not found'
> if 'mystring' in s:
> print 'processing'
>
>
> ... will only work on Python 2.x, as print is being used as a
> statement. If you change print to a function, that code will work in
> either Python 2.x or Python 3.x.
>
>
> However, in both CPython and IronPython, the above is provably correct
> code. It works fine: with those five lines alone, you are guaranteed
> to get 'foundit' followed by 'processing' if mystring is in s. With
> those five lines alone, you must get that result. If you aren't, then
> there's something else going on before or after-- and its not about
> IronPython vs CPython. To help diagnose what's wrong, copy and paste
> -real- results from a command prompt or interpreter when you run it,
> providing complete code. Something else is going wrong, you're looking
> in the wrong place to find the solution.
One other assumption that you are making is that f is a file-like object
that supports a reasonalbe readline function.
Quin: can you Ctrl-C, Ctrl-V the following code into a python file, by
itself, and run it to reproduce your problem?
from StringIO import StringIO
f = StringIO('This string contains mystring')
s = f.readline()
if 'mystring' in s: print 'foundit'
if 'mystring' not in s: print 'not found'
if 'mystring' in s:
print 'processing'
# Should print:
# foundit
# processing
f = StringIO('This string does not contain MyStRiNg')
s = f.readline()
if 'mystring' in s: print 'foundit'
if 'mystring' not in s: print 'not found'
if 'mystring' in s:
print 'processing'
# Should print:
# not found
And please, humor me and copy and paste the exact results as returned by
your IronPython interpreter.