While and If messing up my program?
Hey, I'm new to the Python world, but I do have experience in several
other languages. I've been running through a tutorial, and I decided that
I'd make a program that runs through a list, finds if there are any
duplicates. The program, doesn't work, but since its a first build I
wasn't too worried about it. I'd be highly impressed if I got the program
to run correctly in the first build, I want to debug it myself later.
What does worry me, is that I can't seem to get the program by a
certain spot. It keeps giving me the same error, and I don't know why.
The code:
ttllst=[4,3,45,3]
cnto=0
cntt=1
rept=-1
print cnto
print cntt
print ttllst[cnto]
print ttllst[cntt]
choice=raw_input("Begin? ")
if choice == "yes" or choice == "y":
while cnto<>len(ttllst)+1:
if ttllst[cnto]==ttllst[cntt]:
rept=rept+1
if cntt==len(ttllst):
print ttllst[cnto],"appears in the list",rept,"times."
cntt=-1
cnto=cnto+1
rept=-1
cntt=cntt+1
print "done."
After running the program I get error:
Traceback (most recent call last):
File "C:\Python24\Projects\repeatfinderlist", line 13, in -toplevel-
if ttllst[cnto]==ttllst[cntt]:
IndexError: list index out of range
Now, if I remove the while, and the If/choice lines like so:
ttllst=[4,3,45,3]
cnto=0
cntt=1
rept=-1
print cnto
print cntt
print ttllst[cnto]
print ttllst[cntt]
if ttllst[cnto]==ttllst[cntt]:
rept=rept+1
if cntt==len(ttllst):
print ttllst[cnto],"appears in the list",rept,"times."
cntt=-1
cnto=cnto+1
rept=-1
cntt=cntt+1
print "done."
I get no errors. The program doesn't work, granted, but I get no errors.
Can anyone tell me what I'm missing?
Thanks!
-CJ
--
http://mail.python.org/mailman/listinfo/python-list
Re: While and If messing up my program?
CJ <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: Thanks! I think I've nailed it. I appreciate all the input! -- http://mail.python.org/mailman/listinfo/python-list
Here I am again, same old arguments
Okay, same program, different issue. Thanks to the help that I was
given I was able to complete my program to find variables in a list that
were repeated, and display them once, and how many times they appeared in
the list. And it worked great!
But, being the perfectionist that I am, I wanted to make the proggie
allow any size of list, and not have to be recoded every time. So step
one was to not make the program reliant on the list itself being of X
length all the time.
Well, for some reason, the FOR loop is altering two of my lists. Using
PRINT magic, I was able to narrow down the lines that were causing it.
But the question remains: Why is it doing this? I'm sure there's a simple
answer that I just overlooked in the manual or something.
So without further ado, the code:
#setup variables
grub=[3,25,3,5,3,"a","a","BOB",3,3,45,36,26,25,"a",3,3,3,"bob","BOB",67]
grubrpt=grub
cntro=0
cntrt=0
rpt=0
skipped=0
#set up for variable length of grub
ttllen=len(grub)-1
print "The heck is this for loop doing?"
for point in range(0,ttllen,1):
print "Here's Grub=",grub
print "And grubrpt=",grubrpt
grubrpt[point]="blk"
#Makes sure that there are not multiple prints.
def alrdy_dn(grub,grubrpt):
if grub[cntro] in grubrpt:
return grubrpt
else:
print grub[cntro],"appears in list",rpt,"times."
grubrpt[grubrpt.index("blk")]=grub[cntro]
return grubrpt
#removes display of variables not repeated
def no_rpts(skipped,grubrpt):
if rpt==0:
skipped=skipped+1
else:
grubrpt=alrdy_dn(grub,grubrpt)
return skipped
#Main body of code
print "The List is:",grub
while cntro<>len(grub)-1:
if grub[cntro]==grub[cntrt]:
rpt=rpt+1
cntrt=cntrt+1
else:
cntrt=cntrt+1
if cntrt==len(grub):
skipped=no_rpts(skipped,grubrpt)
cntro=cntro+1
cntrt=0
rpt=-1
print skipped,"list elements are unique."
And the award winning Output:
The heck is this for loop doing?
Here's Grub= [3, 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a',
3, 3, 3, 'bob', 'BOB', 67]
And grubrpt= [3, 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a',
3, 3, 3, 'bob', 'BOB', 67]
Here's Grub= ['blk', 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25,
'a', 3, 3, 3, 'bob', 'BOB', 67]
And grubrpt= ['blk', 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25,
'a', 3, 3, 3, 'bob', 'BOB', 67]
Here's Grub= ['blk', 'blk', 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26,
25, 'a', 3, 3, 3, 'bob', 'BOB', 67]
And grubrpt= ['blk', 'blk', 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26,
25, 'a', 3, 3, 3, 'bob', 'BOB', 67]
It goes on like that, I'm not going to put all of it here for obvious
reasons. But, if I take out the whole for loop and the lines relating to
it and statically assign grubrpt as ["blk","blk"...] then the program
runs wonderfully.
From what I understand, you can never have too many functions, so I
tried to make the grub "blk" a function and got the same result. I'm
still nailing them down, so if my functions look a little weird you know
why. Also, I do realize that there is an easier way to do this, I just
created a little project for myself to learn the basics of the language.
Thanks for all the help!
-CJ
--
http://mail.python.org/mailman/listinfo/python-list
Re: Here I am again, same old arguments
Wow, thanks alot. I pretty much (due to my own desire to get the program to
)(@#T(=!!! work and
be done with it) just turned the list into a function that returns a list that
isn't attached to
anything but the function itself, but I've taken the advice to heart.
Most of what you posted makes sense, and is in fact easier than what I was
doing, but I have
three questions:
1) Why no global variables? I'm taking your word for it that they're bad. Far
be it from me to
argue with you, but why are they bad ideas to begin with? Most of the languages
I've used up to
this point have been reliant on globals, so I'm not entirely sure why they
shouldn't be used.
2) Why no for loop with an index? Again, far be it from me to argue, but it
seemed perfect for
my program.
3) Where do I find a command list, with syntax and all that fun stuff for
Python? I've explored
the python site to no end, but I can't seem to find a list.
Again, thanks to everyone who put my crappy noob proggie through the blender :D
I really did
learn alot. Like how my 60 line program got turned into a 15 line code snippet.
(I'm not being
sarcastic, really, thanks)
-
Wait a minute. I can use my PSP to play GAMES?!?
Steven D'Aprano <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On Sun, 09 Oct 2005 07:02:52 +, CJ wrote:
>
>>Okay, same program, different issue. Thanks to the help that I was
>> given I was able to complete my program to find variables in a list
>> that were repeated, and display them once, and how many times they
>> appeared in the list. And it worked great!
>>
>>But, being the perfectionist that I am, I wanted to make the
>>proggie
>> allow any size of list, and not have to be recoded every time. So
>> step one was to not make the program reliant on the list itself being
>> of X length all the time.
>
> First off -- don't use a for loop with an index as you are doing.
>
>> #setup variables
>> grub=[3,25,3,5,3,"a","a","BOB",3,3,45,36,26,25,"a",3,3,3,"bob","BOB",6
>> 7] grubrpt=grub
>> cntro=0
>> cntrt=0
>> rpt=0
>> skipped=0
>
> You are doing too much manual work! Let Python do the lion's share of
> the work for you!
>
>> #set up for variable length of grub
>> ttllen=len(grub)-1
>
> Why are you subtracting one from the length of the list?
>
>> print "The heck is this for loop doing?"
>> for point in range(0,ttllen,1):
>
> Using point as a loop index is generally a bad idea. The result coming
> from range is not a point, it is an integer, so why call it a point?
>
> You are also over-specifying the input arguments to range. If the step
> size is one, you don't need to specify it -- that's the default. You
> just make it harder to read, for no reason. Likewise the initial
> starting value of zero. Just use range(ttllen).
>
> This, by the way, will return a list [0, 1, 2, ... , length of list -
> TWO] because you already subtracted one from the length.
>
>> print "Here's Grub=",grub
>> print "And grubrpt=",grubrpt
>> grubrpt[point]="blk"
>
> As others have pointed out, grub and grubrpt are both names for the
> same list. Changing one changes the other.
>
>
>> #Makes sure that there are not multiple prints.
>> def alrdy_dn(grub,grubrpt):
>> if grub[cntro] in grubrpt:
>
> Ew!!! Global variables!!!
>
> Bad programmer! No biscuit!!!
>
> *wink*
>
> Global variables are almost always a BAD idea.
>
>> return grubrpt
>> else:
>> print grub[cntro],"appears in list",rpt,"times."
>> grubrpt[grubrpt.index("blk")]=grub[cntro] return grubrpt
>
> This is a strange function. What exactly is it meant to do? It
> combines user interface (printing the number of times each item
> appears) and functionality (counting the number of times each item
> appears) and side effects (changing the list), before returning one of
> the input arguments again.
>
> At least two of those things (counting the items, and printing the
> results) should be separated into different functions for ease of
> comprehension.
>
> I'm going to skip the rest of your code, because I don't understand it
> and am too lazy, er, I mean busy, to spend the time trying to decipher
> it. Especially since the function you are trying to duplicate manually
> is so easy to do if you work with Python instead of against it.
>
> def count_item(L, item):
> """Count the num
Python, SOAP & SSL
Was this ever solved? I'm running into the same problem right now. Any help is much appreciated. -cjb -- http://mail.python.org/mailman/listinfo/python-list
Strange crash issue on Windows w/ PyGTK, Cairo...
Hello list! I'm having a strange issue, and I'm not entirely certain yet where the actual problem is (ie, Python, PyGTK, or gtk+), but I figure I'll start here. Bear with me, this'll probably be a long explanation... I've been building an app which is meant to be run on both Linux and Windows. It uses PyGTK for its GUI, and the main area of the app is a gtk.DrawingArea which I draw on using PyCairo. I've been developing on Linux, and it works great on that platform, with no issues that I'm aware of. When running on Windows, though, the app exhibits the following behavior: 1) When the .py of the main file which runs the application GUI first gets compiled to a .pyc (ie: the first time it's run, or the first time after .py modification), the application runs totally fine, with no apparent problems. 2) Any attempt AFTER that, the application will start up, *start* to do its data-loading, but then almost immediately crash with an enigmatic "python.exe has generated errors and will be closed by Windows." When it does so, there is no output whatsoever to the console that the application was launched from, and the crash doesn't always happen in exactly the same place. The pattern remains the same, though - if the .pyc needs to be compiled, the application works fine, but if not: boom. I've been steadily stripping the program down to what I hoped would be a small, reproducible app that I could post here, and I do intend to do so still, but it's rather slow going. For now, I was hoping to see if anyone's ever heard of behavior like this before, and might know what to do about it, or at least a possible avenue of attack. As I've been reducing the program down, I've encountered even stranger (IMO) behavior... In one instance, changing a function name seemed to make the program work. I took out the handler which draws my app's "About" box, and suddenly my problem went away. Occasionally I would remove a function and the app would suddenly *always* fail with that Windows crash error, and I'd have to put the function back in. Keep in mind, these are functions which *aren't being called anywhere.* Sometimes I could replace a function's entire contents with just "pass" and the app would suddenly behave properly, or not behave at all. It's almost as if whatever's doing the byte-compilation is getting screwed up somehow, and really small changes to parts of the file which aren't even being touched are having a huge impact on the application as a whole. It's seriously vexing, and certainly the oddest problems I've seen in Python. Windows versions I can reproduce this on: XP and win2k Python versions I've reproduced this on: Python 2.5.4 with: PyGTK 2.12.1-2-win32-py2.5 PyGObject 2.14.1-1.win32-py2.5 PyCairo 1.4.12-1.win32-py2.5 Python 2.6.1 with: PyGTK 2.12.1-3-win32-py2.6 PyGObject 2.14.2-2.win32-py2.6 PyCairo 1.4.12-2.win32-py2.6 gtk+ 2.12.9-win32-2 (from http://sf.net/projects/gladewin32 , which is the version linked to from pygtk.org) The 2.6 Python stuff I've actually only tried on win2k so far, not XP, though given my history with this, I suspect that that wouldn't make a difference. Since gtk+ is the one bit of software that hasn't been swapped out for another version, I suppose that perhaps that's where the issue is, but it seems like Python should be able to at least throw an Exception or something instead of just having a Windows crash. And having it work the FIRST time, when the .pyc's getting compiled, is rather suspicious. Anyway, I'll continue trying to pare this app down to one manageable script which I can post here, but until then I'd be happy to hear ideas from anyone else about this. Thanks! -CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
bieff...@gmail.com wrote: > It looks like some of the C extension you are using is causing a > segfault or similar in python > interpreter (or it could be a bug in the interpreter itself, but it is > a lot less likely). Okay... I assume by "C extension" you'd include the PyGTK stuff, right? (ie: pycairo, pygobject, and pygtk) Those are the only extras I've got installed, otherwise it's just a base Python install. Would a bad extension really cause this kind of behavior though? Specifically the working-the-first-time and crash-subsqeuent-times? Do C extensions contribute to the bytecode generated while compiling? > I would suggest to fill the startup portion of your code with trace > statements to try to understand which module function is the > troublesome one, then go looking in the big tracking system of the > module, try the newest version and ask on the dedicated mailing list > if any. Are you talking about just throwing in various print statements, to find out where exactly it's dying? Or I see that there is an actual "trace" module in Python... I did do the former awhile ago and didn't find anything conclusive really. It was when approaching it from that angle that I stumbled across the case that if I simply renamed one of my functions, everything started working again. I'll do this a bit more once I've gotten the program down to a more manageable level. > Making a small script that cabn reproduce the bug is also a very good > idea, and will help speed-up the problem solution. Right, that's the goal. Right now it's still pretty unwieldy, still. I'll keep on it. Thanks for the response! -CJ -- WOW: Flemmy| "Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria!" 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
bieff...@gmail.com wrote: > If you have worked with C/C++, you know that memory-related bugs can > be very tricky. > More than once - working with C code - I had crashes that disappeared > if I just added > a 'printf', because the memory allocation scheme changed and the > memory corrupted was not anymore > relevant. Well, you turned out to be dead right about this, as I suppose should have been pretty obvious given the nature of the problems I was having. Anyway, the issue turned out to be zlib.decompress() - for larger sets of data, if I wasn't specifying "bufsize," the malloc()s that it was doing behind-the-scenes must have been clobbering memory. As soon as I specified bufsize, everything was totally kosher. Once I'm a bit more awake tomorrow I'll put together a testcase and send it in to the bug tracker. This does bring up one question: for larger chunks of data, is it More Appropriate to use a zlib decompression object instead of just passing it all through zlib.decompress()? Thanks, everyone... -CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: > Anyway, the issue turned out to be zlib.decompress() - for larger sets > of data, if I wasn't specifying "bufsize," the malloc()s that it was > doing behind-the-scenes must have been clobbering memory. As soon as I > specified bufsize, everything was totally kosher. Okay, I've got a reproducible testcase of this available up here: http://apocalyptech.com/pygtk-zlib/ I'm no longer *totally* convinced that it's a zlib issue... zlib's call actually returns a valid string, and the error happens later in the app. I've yet to be able to engineer a crash using anything other than that cairo.ImageSurface.create_from_png() function, so it's possible that specifying "bufsize" in zlib.decompress() merely allocates memory in such a way that a bug in PyCairo doesn't come to light in that case. So, I'm not really sure if I should submit this to Python or PyGTK's tracker yet. Could someone check it out and let me know what you think? That'd be great. Thanks! As I mention on that page, removing "import os" and "import sys" will "fix" the issue on XP, though you can remove them on win2k and still see the crash. Thanks, CJ -- WOW: Flemmy| "The ships hung in the sky in much the same p...@apocalyptech.com |way that bricks don't." - Douglas Adams, 24.24.2.3171 | _The Hitchhiker's Guide To The Galaxy_ -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: > Okay, I've got a reproducible testcase of this available up here: > http://apocalyptech.com/pygtk-zlib/ Hello, two brief notes here: 1) Someone on the PyGTK list mentioned that I should really be using StringIO instead of my own hacky attempt at one, in there, and of course he was right. Replacing my class with StringIO doesn't result in any changed behavior, at least, so I can definitely rule out any weirdness that my own file-like class could have introduced. I've uploaded a new version of run.py to the above URL which includes that change. 2) It looks like specifying "bufsize" isn't actually the totally magic bullet for this. I had put in that fix to my application, so it was using bufsize, and things seemed to be working all right, but after four or five data loads, I got that Windows crash again, regardless. The fix does make the application stable enough that I'm not that worried about it, at least, but it doesn't seem to have totally bypassed whatever bug I'm running into. -CJ -- WOW: Flemmy| "Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria!" 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: > Okay, I've got a reproducible testcase of this available up here: > http://apocalyptech.com/pygtk-zlib/ > > I'm no longer *totally* convinced that it's a zlib issue... zlib's call > actually returns a valid string, and the error happens later in the app. Hello, again, list. One last update on this, in case anyone happened to be curious about it. After talking with the PyCairo folks, it looks like this *was* a PyCairo issue after all, and the changes to the zlib call which had apparently fixed the issue were just incidental, basically, because of how the memory allocation ended up changing because of the modified vars. Anyway, a recent fix in PyCairo CVS seems to take care of it. zlib, as probably should have been expected, is vindicated! -CJ -- WOW: Flemmy| "Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria!" 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
