440,602 Members | 1,507 Online
Need help? Post your question and get tips & solutions from a community of 440,602 IT Pros & Developers. It's quick & easy.

# spliting a list by nth items

 P: n/a I feel like this has probably been answered before, but I couldn't find something quite like it in the archives. Feel free to point me somewhere if you know where this has already been answered. I have a list in a particular order that I want to split into two lists: the list of every nth item, and the list of remaining items. It's important to maintain the original order in both lists. So the first list is simple: nth_items = items[::n] The second list is what's giving me trouble. So far, the best I've come up with is: non_nth_items = list(items) del non_nth_items[::n] Is this the right way to do this? Steve -- You can wordify anything if you just verb it. - Bucky Katt, Get Fuzzy Jul 18 '05 #1
33 Replies

 P: n/a Steven Bethard wrote: I feel like this has probably been answered before, but I couldn't find something quite like it in the archives. Feel free to point me somewhere if you know where this has already been answered. I have a list in a particular order that I want to split into two lists: the list of every nth item, and the list of remaining items. It's important to maintain the original order in both lists. So the first list is simple: nth_items = items[::n] The second list is what's giving me trouble. So far, the best I've come up with is: non_nth_items = list(items) del non_nth_items[::n] Is this the right way to do this? There's probably no "right" way. Your way isn't the way I would have thought to do it, I think. But it's brilliant. :-) (Also simple and clear.) -Peter Jul 18 '05 #2

 P: n/a Steven Bethard wrote: I have a list in a particular order that I want to split into two lists: the list of every nth item, and the list of remaining items. It's important to maintain the original order in both lists. So the first list is simple: nth_items = items[::n] The second list is what's giving me trouble. non_nth_items = [x for x in items if x % n] -- Michael Hoffman Jul 18 '05 #3

 P: n/a I believe you meant somthing like: non_nth_items = [items[i-1] for i in range(1,len(items)-1) if i % n] I don't think the "if x % n" won't work on his list of items Larry Bates "Michael Hoffman" wrote in message news:ci**********@pegasus.csx.cam.ac.uk... Steven Bethard wrote: I have a list in a particular order that I want to split into two lists: the list of every nth item, and the list of remaining items. It's important to maintain the original order in both lists. So the first list is simple: nth_items = items[::n] The second list is what's giving me trouble. non_nth_items = [x for x in items if x % n] -- Michael Hoffman Jul 18 '05 #4

 P: n/a Larry Bates wrote: I believe you meant somthing like: non_nth_items = [items[i-1] for i in range(1,len(items)-1) if i % n] I don't think the "if x % n" won't work on his list of items D'oh! I wasn't thinking--the test list of items I used was range(something), so of course it worked. What I meant was: non_nth_items = [x for index, x in enumerate(items) if index % n] Thanks for the correction. -- Michael Hoffman Jul 18 '05 #5

 P: n/a Larry Bates swamisoft.com> writes: I believe you meant somthing like: non_nth_items = [items[i-1] for i in range(1,len(items)-1) if i % n] Yeah, the items list is not of the form range(x) -- in fact, my current use for this is with a list of filenames -- so Michael Hoffman's solution: non_nth_items = [x for x in items if x % n] wouldn't work. In the full fledged problem, I actually have a start parameter for the slice as well as the step parameter (n), so I could probably do something along these lines (inspired by your two suggestions): non_nth_items = [item for i, item in enumerate(items) if (i - start) % n] instead of my original non_nth_items = list(items) del non_nth_items[start::n] The enumerate/range solution is a little more verbose, but it does only go through the list once. Thanks for the good suggestions! STeve Jul 18 '05 #6

 P: n/a [Steven Bethard] so I could probably do something along these lines (inspired by your two suggestions): non_nth_items = [item for i, item in enumerate(items) if (i - start) % n] instead of my original non_nth_items = list(items) del non_nth_items[start::n] The enumerate/range solution is a little more verbose, but it does only go through the list once. Thanks for the good suggestions! The enumerate solution has a lot going for it. It is more flexible and easily accomodates criteria other than every nth item. More importantly, it demonstrates an important guiding principle: multiple list deletions are a code smell indicating that building a new list is a better approach. On this newsgroup, I've seen people tie themselves in knots with multiple in-place deletions during iteration when the new list approach was clearer, more robust, and faster. The runtime behavior of the non_nth_items[start::n] approach is implementation dependent. One can easily imagine a O(n**2) process running behind the scenes. CPython is a smarter than that, but the code for list_ass_subscript() in listobject.c is not a pretty sight. Raymond Hettinger Jul 18 '05 #7

 P: n/a Raymond Hettinger writes: The enumerate solution has a lot going for it. It is more flexible and easily accomodates criteria other than every nth item. Yeah, I'm not so much worried about this, or I wouldn't be using items[start::n] to make the nth_items list in the first place. (If I was planning to allow for other criteria, I'd probably use filter or ifilter instead of the slicing...) More importantly, it demonstrates an important guiding principle: multiple list deletions are a code smell indicating that building a new list is a better approach. This was kinda my feeling -- hence why I posted. Part of the problem for me was that because the two lists were so closely related semantically, I was looking for a syntax that was also closely related. Sometimes this is a good intuition to have, sometimes not. ;) The runtime behavior of the non_nth_items[start::n] approach is implementation dependent. Ahh, I didn't know that. Good thing to know... Thanks, Steve Jul 18 '05 #8

 P: n/a >>> x = [0,1,2,3,4,5,6,7,8,9] n = 3 y = [x[i] for i in range(len(x)) if i%n==0] z = [x[i] for i in range(len(x)) if i%n<>0] x [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] y [0, 3, 6, 9] z [1, 2, 4, 5, 7, 8] "Steven Bethard" wrote in message news:ma**************************************@pyth on.org... | I feel like this has probably been answered before, but I couldn't | find something quite like it in the archives. Feel free to point me | somewhere if you know where this has already been answered. | | I have a list in a particular order that I want to split into two | lists: the list of every nth item, and the list of remaining items. | It's important to maintain the original order in both lists. | | So the first list is simple: | | nth_items = items[::n] | | The second list is what's giving me trouble. So far, the best I've | come up with is: | | non_nth_items = list(items) | del non_nth_items[::n] | | Is this the right way to do this? | | Steve | -- | You can wordify anything if you just verb it. | - Bucky Katt, Get Fuzzy Jul 18 '05 #9

 P: n/a I was one of the frequent posters on the many tools/ides/gui threads that appeared here over the past weeks. I'm now partly satisfied. My search for a good IDE that is usable in my lowend machine is still not completed. But I found a good setup using a free editor and PythonWin working together. I'm using Crimson Editor, a small freeware editor. The most interesting part is that it isn't the most featured of all editors I've tried; it isn't as powerful as vi or emacs, but has one feature that I wanted the most, that is a fairly simple project management tool. It simply allows me to organize a list of files that I'm using for a project on the left pane. I can click on a file to open it. It's amazingly useful when you're dealing with "hot" files stored on several different directories, and you don't have to remember where is it located, or to manually walk the open file dialog looking for it. I'm using PythonWin for testing, mostly because the Windows console is so braindead, and because PythonWin help is quick well organized (it's about the same that you find in the web, but a little bit more convenient). I'm also evaluating Wing IDE 2.0; I had a few issues with it that were solved, but for some tasks I found it too heavy for my limited resources. Anyway, I'm keeping an eye on it. -- http://mail.python.org/mailman/listinfo/python-list -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: ca********@gmail.com mail: ca********@yahoo.com Jul 18 '05 #10

 P: n/a Carlos Ribeiro writes: I'm using Crimson Editor, a small freeware editor. The most interesting part is that it isn't the most featured of all editors I've tried; it isn't as powerful as vi or emacs, but has one feature that I wanted the most, that is a fairly simple project management tool. It simply allows me to organize a list of files that I'm using for a project on the left pane. I can click on a file to open it. It's amazingly useful when you're dealing with "hot" files stored on several different directories, and you don't have to remember where is it located, or to manually walk the open file dialog looking for it. I'm an Emacs user, but you might try looking at http://ecb.sf.net as a 'plugin' to (X)Emacs. It comes installed with XEmacs... Also, I can't help with Windows. I find that tools there are very poor when compared to what we have on unices :-) -- Godoy. Jul 18 '05 #11

 P: n/a Carlos Ribeiro wrote: I'm using PythonWin for testing, mostly because the Windows console is so braindead, and because PythonWin help is quick well organized (it's about the same that you find in the web, but a little bit more convenient). You may want to try ipython (http://ipython.scipy.org). It gives you under Windows (or linux, or OSX) colored tracebacks, tab-completion, directory management, integrated pdb loading on uncaught exceptions, profiler support, and quite a bit more. I don't use windows, but under linux my development setup is Xemacs+ a terminal with ipython running. Thanks to ctypes and UNCreadline, you get exactly the same functionality under windows (along with your editor of choice). I honestly find it to be a _very_ efficient setup. Cheers, f Jul 18 '05 #12

 P: n/a Carlos Ribeiro wrote: I was one of the frequent posters on the many tools/ides/gui threads that appeared here over the past weeks. I'm now partly satisfied. My search for a good IDE that is usable in my lowend machine is still not completed. But I found a good setup using a free editor and PythonWin working together. I'm using Crimson Editor, a small freeware editor. The most interesting part is that it isn't the most featured of all editors I've tried; it isn't as powerful as vi or emacs, but has one feature that I wanted the most, that is a fairly simple project management tool. It simply allows me to organize a list of files that I'm using for a project on the left pane. I can click on a file to open it. It's amazingly useful when you're dealing with "hot" files stored on several different directories, and you don't have to remember where is it located, or to manually walk the open file dialog looking for it. I'm using PythonWin for testing, mostly because the Windows console is so braindead, and because PythonWin help is quick well organized (it's about the same that you find in the web, but a little bit more convenient). I'm also evaluating Wing IDE 2.0; I had a few issues with it that were solved, but for some tasks I found it too heavy for my limited resources. Anyway, I'm keeping an eye on it. -- http://mail.python.org/mailman/listinfo/python-list i do a lot of python (and jython) programming and i use crimson editor and pythonwin also. in fact, i use crimson editor for everything. i've even associated just about every file type in windows to crimson editor :) bryan Jul 18 '05 #13

 P: n/a Jeremy Jones wrote: Another tool that I use that I just started using but I'm finding indispensable is IPython. Features: :) I'm glad you like it, though. * tab completion - this is probably the hugest benefit. * executes (some? all?) OS commands without having the exit out - tab completion works on filesystem paths here The @rehash magic command will load _all_ of your \$PATH as aliases, by default only the most common things are loaded. You can just type alias to see what's active. Note that the pysh profile (ipython -p pysh) preloads your whole path, and adds a few more modifications, so you can use ipython as a system shell, but with python syntax (and full two-way communication of variables). Here's an example: fperez@maqroll[~/test]|8> \$\$files=ls fperez@maqroll[~/test]|9> type(files) <9> fperez@maqroll[~/test]|10> len files -------------------------> len(files) <10> 33 fperez@maqroll[~/test]|11> for f in files: |..> if len(f) > 10: |..> wc -l \$f |..> 4 inspectbug.py 73 ramptest.py Granted, it's silly, but I don't know in the shell how I could easily say "run wc -l over all files whose name is longer than 10 characters". I can _never_ remember how to do complicated logic/looping in the shell, while I can certainly do such things trivially in python. The pysh profile puts ipython in a mode which bridges this gap. Incidentally, pysh is actually just a special configuration mode for ipython, consisting of about only 36 lines of code (the rest is regular ipython). * probably more....but I'm still digging into this Lots more :) Best, f Jul 18 '05 #14

 P: n/a Dan Perl wrote: I debugged one of my scripts (that I knew it works) and got an unexplainable exception. It turns out that Wing IDE falsely detects some exceptions. They know about it and they suggest that if you KNOW that it's a false exception you should flag it to be ignored. Yes, Wingware people, I know it's a false exception, but What exactly is a "false exception"? I have never heard of such a thing, and can't imagine what it might be. Python raises exceptions, they are subclasses of Exception or (old-style) strings, they have tracebacks, they come from a variety of sources, there's lots of things to know about exceptions but "falseness" is not something about which I'm aware... -Peter Jul 18 '05 #16

 P: n/a On Sun, 26 Sep 2004 21:36:18 -0400, Peter Hansen wrote: Dan Perl wrote: I debugged one of my scripts (that I knew it works) and got an unexplainable exception. It turns out that Wing IDE falsely detects some exceptions. They know about it and they suggest that if you KNOW that it's a false exception you should flag it to be ignored. Yes, Wingware people, I know it's a false exception, but What exactly is a "false exception"? I have never heard of such a thing, and can't imagine what it might be. Python raises exceptions, they are subclasses of Exception or (old-style) strings, they have tracebacks, they come from a variety of sources, there's lots of things to know about exceptions but "falseness" is not something about which I'm aware... They're false in the sense that that they're not supposed to be raised to the attention of the user. What happens is that Wing IDE is super sensitive with regards to exceptions; when an exception is raised in some internal module, Wing tries to outsmart the library and warn the user that an exception happened. A "false exception" is one that would happen and be silently treated by the library itself, without nobody noticing, but that's catched by Wing IDE nonetheless, in a totally unnecessary and obstrusive way. You can see that it's a case where the tool tries to be too smart for its own good. p.s. Why do they do it? For what I could see, the intention seems to be able to catch situations where a valid exception that should be raised to the user attention is silented by a generic error handler. It really may be useful in some situations, but it isn't a reasonable default in my opinion. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: ca********@gmail.com mail: ca********@yahoo.com Jul 18 '05 #17

 P: n/a Yes, that's what I was talking about. Thanks, Carlos, for explaining it. I actually should have said false detection of exceptions or wrong detection of exceptions. I don't remember what Wingware are calling it. Actually, the way they were qualifying it was something like "if you do not see this exception when running the script outside the IDE, then you should probably flag it to be ignored". And they are giving a list of builtin modules where those exceptions are usually "falsely" detected. I didn't try to figure out what their exception detection mechanism is and why they have this problem. I just uninstalled the IDE. So 10 days for the trial was more than enough after all. ;-) I think I had it installed for about 2 days. I can tolerate a bug and I wouldn't be so riled up, but what got me was the marketing spin and how they were just excusing the bug, like they would never fix it. The "false exceptions" and the lack of a class browser made me decide not to choose Wing IDE this time. Their attitude about the "false exceptions" made me cut the trial short and never to consider Wing IDE again. Dan "Carlos Ribeiro" wrote in message news:ma**************************************@pyth on.org... On Sun, 26 Sep 2004 21:36:18 -0400, Peter Hansen wrote: Dan Perl wrote: > I debugged one of my > scripts (that I knew it works) and got an unexplainable exception. It > turns > out that Wing IDE falsely detects some exceptions. They know about it > and > they suggest that if you KNOW that it's a false exception you should > flag it > to be ignored. Yes, Wingware people, I know it's a false exception, > but What exactly is a "false exception"? I have never heard of such a thing, and can't imagine what it might be. Python raises exceptions, they are subclasses of Exception or (old-style) strings, they have tracebacks, they come from a variety of sources, there's lots of things to know about exceptions but "falseness" is not something about which I'm aware... They're false in the sense that that they're not supposed to be raised to the attention of the user. What happens is that Wing IDE is super sensitive with regards to exceptions; when an exception is raised in some internal module, Wing tries to outsmart the library and warn the user that an exception happened. A "false exception" is one that would happen and be silently treated by the library itself, without nobody noticing, but that's catched by Wing IDE nonetheless, in a totally unnecessary and obstrusive way. You can see that it's a case where the tool tries to be too smart for its own good. p.s. Why do they do it? For what I could see, the intention seems to be able to catch situations where a valid exception that should be raised to the user attention is silented by a generic error handler. It really may be useful in some situations, but it isn't a reasonable default in my opinion. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: ca********@gmail.com mail: ca********@yahoo.com Jul 18 '05 #18

 P: n/a I've done a little more digging into the Wing IDE documentation and this is one of the better explanations I've found on the "false exceptions": "As you try out the various demos from the tree on the left of the wxPython demo app, you will sometimes see Wing IDE report exceptions in its Error List dialog, which will come to the front as the wxPython demo pauses at the exception. These are not program errors or a malfunction of the IDE. As described at the end of the Error List text, these are caused by Wing's proactive exception detection algorithm, which cannot see into the C and C++ code that is handling these exceptions outside of the debugger. To get past them, select "Ignore this exception location" in the Error List window and click on Continue Execution. You will see 3-4 of these the first time Wing IDE encounters them. After that, your ignore list is stored in the project so you will never see them again, even in future debug sessions. Subsequently, you will benefit from Wing's ability to stop immediately at the point of exception, rather than after the fact. This makes understanding the conditions leading to an error much easier and speeds up debug turn-around." I can see a benefit in stopping at the point of exception, but if that causes false positives (term used by one of their support people) with the builtin modules that are implemented in C/C++, then I'd rather just live without this benefit. Apparently, there is a way to disable that behavior (I found out about it only now), but Wing keeps recommending the "Ignore this exception location" solution. And here is the kind of comment that really bothers me. An actual statement from their documentation ("Debugging Zope with Wing IDE"): "Another useful exception related feature is the ability to ignore exceptions selectively by line of code on which they occur. You can choose this option in the Error List window that comes up when an exception occurs. In Zope, as in other Python apps that contain some non-Python code, Wing will incorrectly identify some exceptions as unhandled because it cannot see whether enclosing C code is going to handle the exception. This usually happens in 1-2 places in Zope and can be dealt with by ignoring subsequent instances of the exception. The zope.wpr project distributed with the Wing+Zope bundle already has these ignores in place." No, this is NOT a "useful exception related feature", it's a workaround for a bug. And it's 1-2 times for Zope, it was 3-4 times in the comments above, how do they get these estimates? I got this problem (er, useful exception related feature) with the first script I debugged. Dan "Carlos Ribeiro" wrote in message news:ma**************************************@pyth on.org... On Sun, 26 Sep 2004 21:36:18 -0400, Peter Hansen wrote: Dan Perl wrote: > I debugged one of my > scripts (that I knew it works) and got an unexplainable exception. It > turns > out that Wing IDE falsely detects some exceptions. They know about it > and > they suggest that if you KNOW that it's a false exception you should > flag it > to be ignored. Yes, Wingware people, I know it's a false exception, > but What exactly is a "false exception"? I have never heard of such a thing, and can't imagine what it might be. Python raises exceptions, they are subclasses of Exception or (old-style) strings, they have tracebacks, they come from a variety of sources, there's lots of things to know about exceptions but "falseness" is not something about which I'm aware... They're false in the sense that that they're not supposed to be raised to the attention of the user. What happens is that Wing IDE is super sensitive with regards to exceptions; when an exception is raised in some internal module, Wing tries to outsmart the library and warn the user that an exception happened. A "false exception" is one that would happen and be silently treated by the library itself, without nobody noticing, but that's catched by Wing IDE nonetheless, in a totally unnecessary and obstrusive way. You can see that it's a case where the tool tries to be too smart for its own good. p.s. Why do they do it? For what I could see, the intention seems to be able to catch situations where a valid exception that should be raised to the user attention is silented by a generic error handler. It really may be useful in some situations, but it isn't a reasonable default in my opinion. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: ca********@gmail.com mail: ca********@yahoo.com Jul 18 '05 #19

 P: n/a Dan Perl wrote: Yes, that's what I was talking about. Thanks, Carlos, for explaining it. I actually should have said false detection of exceptions or wrong detection of exceptions. I don't remember what Wingware are calling it. Actually, the way they were qualifying it was something like "if you do not see this exception when running the script outside the IDE, then you should probably flag it to be ignored". And they are giving a list of builtin modules where those exceptions are usually "falsely" detected. As a recent convert to Wing I think you aren't giving them enough credit: remember, this only happens in the 2.0 BETA product (or, if it also happens in earlier versions, they are definitely planning to minimize the effects in the production version). I didn't try to figure out what their exception detection mechanism is and why they have this problem. I just uninstalled the IDE. So 10 days for the trial was more than enough after all. ;-) I think I had it installed for about 2 days. I can tolerate a bug and I wouldn't be so riled up, but what got me was the marketing spin and how they were just excusing the bug, like they would never fix it. Well, I'm sure I remember reading somewhere that before they go into production they plan to add a standard list of such exceptions for the various Python versions, so that the standard libraries are far less troublesome in this respect. Plus, IIRC, all you have to do is check an "ignore this exception" box to have a specific exception ignored everafter, which didn't seem like a huge deal to me. The "false exceptions" and the lack of a class browser made me decide not to choose Wing IDE this time. Their attitude about the "false exceptions" made me cut the trial short and never to consider Wing IDE again. I find that it's very useful to be able to select from a dropdown list of defined classes, and then select from a further drop-down list of methods of that class. While it may not be a full class browser it's certainly excellent functionality. regards Steve Jul 18 '05 #20

 P: n/a "Steve Holden" wrote in message news:41************@holdenweb.com... Dan Perl wrote: Yes, that's what I was talking about. Thanks, Carlos, for explaining it. I actually should have said false detection of exceptions or wrong detection of exceptions. I don't remember what Wingware are calling it. Actually, the way they were qualifying it was something like "if you do not see this exception when running the script outside the IDE, then you should probably flag it to be ignored". And they are giving a list of builtin modules where those exceptions are usually "falsely" detected. As a recent convert to Wing I think you aren't giving them enough credit: remember, this only happens in the 2.0 BETA product (or, if it also happens in earlier versions, they are definitely planning to minimize the effects in the production version). According to the documentation this was happening in much earlier, production, versions. You are saying "they are definitely planning to minimize the effects in the production version". Can you please qualify that? Minimize how? What does "minimizing the effects" mean anyway? I didn't try to figure out what their exception detection mechanism is and why they have this problem. I just uninstalled the IDE. So 10 days for the trial was more than enough after all. ;-) I think I had it installed for about 2 days. I can tolerate a bug and I wouldn't be so riled up, but what got me was the marketing spin and how they were just excusing the bug, like they would never fix it. Well, I'm sure I remember reading somewhere that before they go into production they plan to add a standard list of such exceptions for the various Python versions, so that the standard libraries are far less troublesome in this respect. A "standard" list? I don't see what's "standard" about that. And the "standard libraries" are not "troublesome", the IDE is. On the other hand, I suppose that this would be an "effect minimization". I don't know what their plans are, but they could include a list of all the possible false positives and automatically ignore them. Forgive me, but that is a hack and I will not have any respect for that. You are using the same kind of marketing spin speak that Wingware is using. I can understand that you like the tool and you feel you have to defend it. But I think this is the wrong way to do it, both for you and for Wingware. I probably shouldn't get so worked up about it. To be fair, since I tried the tool I have discovered that Wing IDE also has the option to disable that behavior and to debug in a mode where unhandled exceptions are just treated like a normal run would treat them. Plus, IIRC, all you have to do is check an "ignore this exception" box to have a specific exception ignored everafter, which didn't seem like a huge deal to me. It's just too bad I don't have a checkbox for "Ignore marketing spin at this location". Dan Jul 18 '05 #21

 P: n/a Dan Perl wrote: "Steve Holden" wrote in message news:41************@holdenweb.com... [...]As a recent convert to Wing I think you aren't giving them enough credit:remember, this only happens in the 2.0 BETA product (or, if it alsohappens in earlier versions, they are definitely planning to minimize theeffects in the production version). According to the documentation this was happening in much earlier, production, versions. You are saying "they are definitely planning to minimize the effects in the production version". Can you please qualify that? Minimize how? What does "minimizing the effects" mean anyway? All I was doing was pointing out htat they are aware of hte phenomenon, and that I (unlike you, apparently) am prepared to live with a minor nit in order to get the advantages the tool gives me.I didn't try to figure out what their exception detection mechanism isand why they have this problem. I just uninstalled the IDE. So 10 daysfor the trial was more than enough after all. ;-) I think I had itinstalled for about 2 days. I can tolerate a bug and I wouldn't be soriled up, but what got me was the marketing spin and how they were justexcusing the bug, like they would never fix it.Well, I'm sure I remember reading somewhere that before they go intoproduction they plan to add a standard list of such exceptions for thevarious Python versions, so that the standard libraries are far lesstroublesome in this respect. A "standard" list? I don't see what's "standard" about that. And the "standard libraries" are not "troublesome", the IDE is. On the other hand, I suppose that this would be an "effect minimization". I don't know what their plans are, but they could include a list of all the possible false positives and automatically ignore them. Forgive me, but that is a hack and I will not have any respect for that. Well, fine. You are using the same kind of marketing spin speak that Wingware is using. I can understand that you like the tool and you feel you have to defend it. But I think this is the wrong way to do it, both for you and for Wingware. Nope, I don;t feel I have to defend it. The tool does what it does, I was merely sayiong that some people (such as me) can work with it as it is. You apparently can't. Fine. I probably shouldn't get so worked up about it. To be fair, since I tried the tool I have discovered that Wing IDE also has the option to disable that behavior and to debug in a mode where unhandled exceptions are just treated like a normal run would treat them. Well, yes, but I thought we were focusing ont he deficiencies of the tool, not the advantages :-)Plus, IIRC, all you have to do is check an "ignore this exception" box tohave a specific exception ignored everafter, which didn't seem like a hugedeal to me. It's just too bad I don't have a checkbox for "Ignore marketing spin at this location". Indeed. Hope you feel better now. Dan regards Steve Jul 18 '05 #22

 P: n/a Dan Perl wrote: Right off the bat, the trial period was only 10 days. I've evaluated quite a few tools that had a free trial period and I don't think I can remember of ever having only 10 days before. Then, the GUI is kind of awkward in a few places (the "project tree view", or something like that, and the toolbars). In fairness, the initial period is 10 days but it can be renewed at the end of that for another 10 days. The renewal procedure is done online and takes about 10 seconds. I also *think* that during the beta period you can repeatedly renew anyway. I agree with your comments about the GUI - it's just so busy but I feel that with all the alternatives. Apart from Emacs of course ;-). Ian Jul 18 '05 #23

 P: n/a On Mon, 27 Sep 2004 12:04:47 -0400, Dan Perl wrote: I myself felt disturbed by your comments on WingIDE. But yes, I do understand your nagging on "false exceptions" which can be turned off. You turned it down because of this and because the short trial period (which can be prolonged with 1 button click)... well, it didn't seem fair towards the tool. It has its shortcomings but the ones you mention are ridiculous. It beats Komodo 3.01 in some aspect: - it shines when it comes to auto-completion. No need to feed some "intelligent database" for each and every file you introduce like in Komodo (first crash while building the database). - in my case it works seamlessly with wxPython. Komodo crashed constantly. Auto-completion with wxPython did never work (tried on 2 machines) - WingIDE is much more robust although beta than Komodo, which crashed about 5 times during 3h of work (Win2K; about 20 times because of wxPython are not taken into account). WingIDE does not crash since around patch 3 (we are now at patch 8). So I would say: Use Komodo if you: - are programming as well in other languages that Komodo supports (PHP, Perl, Python, HTML, ...) - need built-in cvs access - can live with an IDE that crashes from time to time Use Wingware if you: - need a good "intelligent" auto-completion even for wxPython, pyQt, ... - need an extensible IDE (you may in future add your own tools easily) - need an IDE that focusses on Python and that tries to do the best on this single language - can live with an IDE that does not look as polished as Komodo This comparison is not perfect. But you may realize that I turned it down for it constantly crashing on me (which might be a problem of me and my 2 machines) and the useless auto-completion (constantly feeding the database; does not work with wxPython). Those 2 points were in my case the show stopper. Sad, because the idea behind Komodo is just great, the looks is fantastic... I will give it another chance with 4.0... Happy wing user, Marco Jul 18 '05 #24

 P: n/a "Dan Perl" writes: "Marco Aschwanden" wrote in message news:ma**************************************@pyth on.org... On Mon, 27 Sep 2004 12:04:47 -0400, Dan Perl wrote: I myself felt disturbed by your comments on WingIDE. But yes, I do understand your nagging on "false exceptions" which can be turned off. You turned it down because of this and because the short trial period (which can be prolonged with 1 button click)... well, it didn't seem fair towards the tool. It has its shortcomings but the ones you mention are ridiculous. The 10 day trial period just gave me a bad first impression and the explanations for the false positives just left me with a bad taste. I gave up on Wing because of the false positives (their simple existence, even without the explanations) and the lack of a class browser. I encountered the false positives first and I almost gave up right there. But it was just the first day and I thought I should look more. Like you say, I wanted to be fair. When I found that the class browser is not supported in the Personal edition I threw my arms in the air. For whatf it's worth, the "false positives" you refer to was a significant reason that I really liked Wing. If you ever use any code that runs Python through an extension boundary (my key use is with wxPython, where all of your GUI objects and event handlers run from within the wxPython extension), Wing is one of the few debuggers that catches exceptions in that code. That's because normally the exceptions are handled by the wxPython extension module, and then suppressed so that they don't kill the main event loop. In my experience, there are minimal other false positives that a normal application triggers (a consistent one I recall was in the sre code), although the current 2.0 beta may still be getting tuned with respect to its default "known" list, and I was more than willing to mark those to be ignored in order to be able to be sure of catching any exceptions within my own code, regardless of whether it was triggered through an extension or not. (...) My "nagging" on the false positives is mostly on the spin that Wingware puts in their explanations. It's one thing to explain it the way that Stephan did, that it was better to offer something imperfect if that was also providing some important advantages and then also offer the other alternative ("We weighed having a necessarily imperfect but useful feature with not having the feature at all."). And it's another thing to insist that this is not a problem and it is actually good for you. This doesn't seem to bother other people as much as it bothered me, but I do have a beef with it. The actually good for you part is arguably true, since otherwise you have the potential to be generating exceptions in your own code and not even know it. But I agree that different people will react differently (note how differently you and I reacted to this feature), so the more that can be done to explain the feature (and its configurability) the better. -- David Jul 18 '05 #26

 P: n/a "Dan Perl" writes: "Marco Aschwanden" wrote in message news:ma**************************************@pyth on.org... On Mon, 27 Sep 2004 12:04:47 -0400, Dan Perl wrote: I myself felt disturbed by your comments on WingIDE. But yes, I do understand your nagging on "false exceptions" which can be turned off. You turned it down because of this and because the short trial period (which can be prolonged with 1 button click)... well, it didn't seem fair towards the tool. It has its shortcomings but the ones you mention are ridiculous. [...] To be fair again to Wing, I gave up on it based on the false positives before finding out that I could have switched to another debug mode. But that's their fault too because the widget that came up with the false positive just says you can ignore the exception and then there was something else just praising the tool, but there was no mention of the different debug modes. I found that option only once I searched the manual. Maybe it's just me, but I'm not reading the manuals when I'm trying out several tools. My "nagging" on the false positives is mostly on the spin that Wingware puts in their explanations. It's one thing to explain it the way that Stephan did, that it was better to offer something imperfect if that was also providing some important advantages and then also offer the other alternative ("We weighed having a necessarily imperfect but useful feature with not having the feature at all."). And it's another thing to insist that this is not a problem and it is actually good for you. This doesn't seem to bother other people as much as it bothered me, but I do have a beef with it. Dan, I suspect that (though perhaps their marketing may have room for improvement here ;-) there may have been an unstated assumption on the part of the Wing IDE people that, "obviously", the false-positives issue is only a "nit" if one has a hard debugging problem on one's hands, and that "obviously", one turns this feature off under all other circumstances. Not necessarily obvious at all, of course. Perhaps, like many of the rest of us, they only wheel out their debugger when they hit a really *nasty* problem, so the exception issue simply never arises as anything other than a minor wart in what I can see could be a very handy feature. That would explain why this feature is on by default. Another explanation is that it's turned on by default just to advertise the feature -- if you don't bump into it like this, you might never realise it existed. John Jul 18 '05 #29