[issue33494] random.choices ought to check that cumulative weights are in ascending order
Paul Czyzewski added the comment: btw, this was my suggestion. Steven opened the issue on my behalf (I'm new). 1) Documentation change. I would suggest that, to this paragraph: "If neither weights nor cum_weights are specified, selections are made with equal probability. If a weights sequence is supplied, it must be the same length as the population sequence. It is a TypeError to specify both weights and cum_weights." The following sentence be added: "A cum_weights sequence, if supplied, must be in strictly-ascending order, else incorrect results will be (silently) returned." [BTW, in the current documentation, when I read this sentence: :For example, the relative weights [10, 5, 30, 5] are equivalent to the cumulative weights [10, 15, 45, 50]," it wasn't clear to me that this was the format of the cum_weights *argument*. I thought that this conversion happened internally. So, I'd prefer that something more explicit be stated (especially the part about silently giving bad results).] 2) I'm giving up on suggesting a code change. However, I'll just respond that a) I believe that the big win of the cum_weights option is for people who already have the sequence in that form, rather than that they will save the O(n) cost of having the list built. b) If I have big list, but also an other-than-tiny k value (eg, k=100), then the time (with the change) would be 400 time the O(log n) plus one times O(n), so this may or may not be significant. c) I agree that, if someone did, eg, 400 *separate* calls, each with k=1, the cost would be higher. This seems unlikely to me but... thanks Paul Czyzewski -- nosy: +PaulSFO ___ Python tracker <https://bugs.python.org/issue33494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33494] random.choices ought to check that cumulative weights are in ascending order
Paul Czyzewski added the comment: oops, if "k=400" -- ___ Python tracker <https://bugs.python.org/issue33494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33494] random.choices ought to check that cumulative weights are in ascending order
Paul Czyzewski added the comment: or, for a minimal doc change, change this sentence: "For example, the relative weights [10, 5, 30, 5] are equivalent to the cumulative weights [10, 15, 45, 50]," to: "For example, the relative call 'weights[10, 5, 30, 5]' is equivalent to the cumulative call 'cum_weights[10, 15, 45, 50]'," -- ___ Python tracker <https://bugs.python.org/issue33494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: I'm new to IDLE. I just upgraded to Mac El Capitan from Snow Leopard, and installed Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44). I have had the IDLE window freeze so many times (when clicking on something in the autocomplete window as described by Ned Deily) that I consider IDLE unusable. I'm not familiar with Python bug practices but I would consider this a serious bug because, as a product manager would probably put it, this is going to drive away a significant percentage of new users (i.e., unexplained freezing of the product when doing something which seems natural -- clicking on the item that I want to select). BTW, looks like I'm on tcl 8.5: >>> tkinter.TclVersion 8.5 Unrelated question: which can't Mac Spotlight find tkinter.py? is it in some compressed file or something, so I can't find a standalone py file? -- nosy: +paulsfo ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: Thanks, Terry and Ned. Ned, I checked (nice clear instructions, btw) and I had Tk 8.5.10. So I followed the link and installed 8.5.18. -- The freeze on mac still occurs but I understand that this will avoid some other bugs. BTW, I don't know how testing works for IDLE and Python, but that's what I do for a living, so maybe I'll try to get involved. -- ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: > Question: does the text widget freezes on button down or not until button up. > The experiment is to press and hold the button while moving the mouse. Does > the cursor move and select text while the button is down, or does it freeze > immediately. Paul, could you try this? Hi Terry, It's definitely on button down. The popup immediately disappears and I'm hung, without ever releasing the mouse button. Newbie question: what is the "normal" way to use this feature. I see that it apparently only works when I'm at the dot (eg, at op. ). So,if I want op.getcwd, I have to scroll a *long* way to get to it (rather than, eg, tyep op.g or whatever) and then, when op.getcwd shows (below the box), I need to type "()" and hit return. this seems a bit painful. Is that the best use of this feature? Paul -- ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: hi Tal and Terry, I hadn't noticed that continuing to type does go to the appropriate spot. However, I see what I think are two or three bugs (not sure is 'a)' is a bug) in the behavior: a) on my system it does not visibly filter the list. EG, if I type 'os.', wait for the popup, then type ge (so, 'os.ge') it scrolls down to, and selects, "get_blocking", but the rest of the list is still there. This is still useful but, Tal, I'm just pointing out that I don't see any options disappear (as I think you're saying they should). Should the list really be visibly filtered? b) say I want os.get_terminal_size. I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t". Now "get_terminal_size" is visible and selected but autocompletion doesn't occur. I.E., I still have 'os.get_t" below the popup. To get the full word I have to arrow *away* from the correct answer and then arrow back to it. Now "get_terminal_size" appears below the popup. This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue. c) Terry: regarding "Box comes up after cntl-space or time delay after key char." On my IDLE, the box *never* appears if I initially type beyond the ".". E.G. import os type "os.g" and wait. RESULT: the popup never appears. It will appear if I then do "cntl-space" but not from a time delay. This seems like another biggish usability bug. The time delay should work (as I think you're saying) and obviously "cntl-space" isn't something a newbie is likely to know to try. -- ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: hi Terry, thanks for all the responses. Well, what *I* found maddening was that typing "os." pause "g" works but typing "os.g" (with no pause) does nothing. :) But, anyway, I guess you're saying that that's as designed. >The list is not supposed to shrink. Having everything disappear on a typo >would not seem good to me. Actually, I think that many widgets do work that way, but I think that, here, I agree with you, since the user might notice a nearby entry which is what they wanted. What about my "b)" (copied just below)? Is there a reason not to autocomplete what's on the command line, as is done if you *arrow* to a selection? Again, not nearly as big an issue as the original hang but I can't think of a reason not to autocomplete in this case, and the code to do so must already exist. b) say I want os.get_terminal_size. I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t". Now "get_terminal_size" is visible and selected but autocompletion doesn't occur. I.E., I still have 'os.get_t" below the popup. To get the full word I have to arrow *away* from the correct answer and then arrow back to it. Now "get_terminal_size" appears below the popup. This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue. -- ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
paul czyzewski added the comment: >If you use the arrow keys to select and copy as you go, you still have > to hit tab twice to close the box (or click elsewhere). Not for me. If i use arrow keys then I just type "()" and the box disappears. So there's two(?) fewer keystrokes needed if you use the arrow keys. But anyway, I'll quit looking for additional minor bugs in this thread. :D thanks Paul -- ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
