[issue18657] Remove duplicate ACKS entries

New submission from Madison May: The title says it all. I used collections.Counter to check for duplicates in ACKS and cleaned up a few double entries. -- assignee: docs@python components: Documentation messages: 194410 nosy: docs@python, madison.may priority: normal severity: normal s

[issue18657] Remove duplicate ACKS entries

R. David Murray added the comment: Did you intend to attach a patch? -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-l

[issue18647] re.error: nothing to repeat

Tim Peters added the comment: I'm afraid it's just too tricky for the code to deduce that a negative lookahead assertion can imply that a later match can't be empty. But I don't know how smart the re compilation code already is ;-) It occurs to me now that the doctest regexp could worm around

[issue18657] Remove duplicate ACKS entries

Madison May added the comment: Now with 100% more patch. Thanks for the catch, David. -- keywords: +patch Added file: http://bugs.python.org/file31157/ACKS_duplicates.patch ___ Python tracker _

[issue18151] Idlelib: update to "with open ... except OSError" (in 2.7, leave IOError)

Roundup Robot added the comment: New changeset e450e85e2075 by Terry Jan Reedy in branch '3.3': Issue #18151: Replace remaining Idle 'open...close' pairs with 'with open'. http://hg.python.org/cpython/rev/e450e85e2075 New changeset 7f6661a90d02 by Terry Jan Reedy in branch '2.7': Issue #18151: R

[issue18151] Idlelib: update to "with open ... except OSError" (in 2.7, leave IOError)

Terry J. Reedy added the comment: Patch looked good, so I backported to 2.7 (attached, in case there are problems) and pushed. -- assignee: -> terry.reedy resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed Added file: http://bugs.python.org/file31158

[issue18657] Remove duplicate ACKS entries

Roundup Robot added the comment: New changeset 2ec323dadca2 by R David Murray in branch '3.3': #18657: remove duplicate entries from Misc/ACKS. http://hg.python.org/cpython/rev/2ec323dadca2 New changeset f4f81ebc3de9 by R David Murray in branch 'default': Merge: #18657: remove duplicate entries

[issue18657] Remove duplicate ACKS entries

R. David Murray added the comment: Thanks, Madison. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.3 -Python 3.5 ___ Python tracker

[issue10427] 24:00 Hour in DateTime

Changes by Alexander Belopolsky : -- resolution: -> rejected stage: test needed -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue1764286] inspect.getsource does not work with decorated functions

Changes by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10329] trace.py and unicode in Python 3

Changes by Alexander Belopolsky : -- stage: test needed -> committed/rejected status: open -> closed ___ Python tracker ___ ___ Python

[issue18606] Add statistics module to standard library

Daniel Stutzbach added the comment: As the person originally trying to take the mean of timedelta objects, I'm personally fine with the workaround of: py> m = statistics.mean([x.total_seconds() for x in data]) py> td(seconds=m) datetime.timedelta(2, 43200) At the time I was trying to take the

[issue18647] re.error: nothing to repeat

Serhiy Storchaka added the comment: Agree. Here is a partial patch which fixes getwidth() and doctest regexp. But I don't know how to fix _simple(). Perhaps we should permanently remove the "nothing to repeat" check. It guards only against '(.*)*', but there are other methods to make regexp ma

[issue18656] setting function.__name__ doesn't affect repr()

Guido van Rossum added the comment: Sorry. The actual problem reported was that the traceback uses the wrong name. I can still reproduce this in 3.4; attached is a repro. -- Added file: http://bugs.python.org/file31160/functools_wraps_oddity.py ___ P

[issue18656] setting function.__name__ doesn't affect repr()

Benjamin Peterson added the comment: That's because argument error messages use the code's co_name rather than the functions. (This is a dupe of another bug about this that I can't find.) -- nosy: +benjamin.peterson ___ Python tracker

[issue18656] setting function.__name__ doesn't affect repr()

Mark Dickinson added the comment: http://bugs.python.org/issue4322 ? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue18656] setting function.__name__ doesn't affect repr()

Benjamin Peterson added the comment: Exactly -- resolution: -> duplicate status: open -> closed superseder: -> function with modified __name__ uses original name when there's an arg error ___ Python tracker

[issue4322] function with modified __name__ uses original name when there's an arg error

Benjamin Peterson added the comment: I think fixing this is a valid request. -- resolution: invalid -> status: closed -> open ___ Python tracker ___ _

[issue18652] Add itertools.coalesce

Serhiy Storchaka added the comment: > Well, for many – including me – it would mean to have this one-line function > in every other project or a PyPI dependency. But why you want to have a separate function instead of just use two builtins? -- ___ P

[issue18647] re.error: nothing to repeat

Tim Peters added the comment: Matching an empty string an unbounded number of times isn't a case of exponential runtime, it's a case of infinite runtime, unless the regexp internals are smart enough to cut the search off (I don't know enough about re's internals to know whether it's smart enou

[issue5845] rlcompleter should be enabled automatically

Serhiy Storchaka added the comment: Do you know that the readline module first force rebind of TAB to insert-tab? -- ___ Python tracker ___ ___

[issue18652] Add itertools.coalesce

Tim Peters added the comment: FWIW, I like this. It would be a nice addition to the itertools module. +1 The `key` argument should be renamed to `pred`, as others have said. As to the name, I like "first_true". Does what it says. Plain "first" is misleading, and "coalesce" is both inscrutab

[issue18652] Add itertools.coalesce

Hynek Schlawack added the comment: > But why you want to have a separate function instead of just use two builtins? This question has been answered twice now, once from Nick – please refer above. It's a clunky and error-prone solution to a common problem. Maybe you can't emphasize because it's

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: This smells like a new feature to me (it's certainly a fairly significant change in behaviour) and isn't appropriate for backporting to 2.7. It can however go into unittest2. I agree with David that a destructive iteration using pop is more likely to cause bac

[issue18563] No unit test for yiq to rgb and rgb to yiq converting functions

Serhiy Storchaka added the comment: This is superseded by issue14323. -- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> Normalize math precision in RGB/YIQ conversion ___ Python tracker

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: The doc patch looks good, thanks Matt. I'll read it through properly before committing. -- ___ Python tracker ___ __

[issue4322] function with modified __name__ uses original name when there's an arg error

Changes by Jesús Cea Avión : -- nosy: +jcea stage: committed/rejected -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailin

[issue4322] function with modified __name__ uses original name when there's an arg error

Changes by Jesús Cea Avión : -- versions: +Python 3.4 -Python 3.0 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14323] Normalize math precision in RGB/YIQ conversion

Serhiy Storchaka added the comment: Here is a patch which implements the FCC version of RGB/YIQ conversion. -- Added file: http://bugs.python.org/file31161/colorsys_yiq_fcc.patch ___ Python tracker

[issue18647] re.error: nothing to repeat

Matthew Barnett added the comment: Suppose you have a repeated pattern, such as "(?:...)*" or "(?:...){0,100}". If, after matching the subpattern, the text position hasn't changed, and none of the capture groups have changed, then there has been no progress, and the subpattern will be matched

[issue12645] test.support. import_fresh_module - incorrect doc

Ben Finney added the comment: On 01-Aug-2013, Eli Bendersky wrote: > Ben, would you like to provide an updated patch? Unfortunately, contributions are not accepted under the Apache Software Foundation License (as I had thought), but also require assigning extra privileges to the Python Software

[issue18652] Add itertools.coalesce

Nick Coghlan added the comment: A wild timbot appears! :) Tim Peters added the comment: > As to the name, I like "first_true". Does what it says. Plain "first" is misleading, and "coalesce" is both inscrutable and nearly impossible to spell ;-) A fair point, although skipping the underscore (

[issue18647] re.error: nothing to repeat

Tim Peters added the comment: Matthew, yes, I agree that a regexp engine can be coded to be robust against unboundedly repeated matching of an empty string. I don't know whether Python's current engine is so coded. It's easy to trick the 2.7 engine into accepting regexps that do try to match

[issue18647] re.error: nothing to repeat

Matthew Barnett added the comment: Python's current regex engine isn't so coded. That's the reason for the up-front check. -- ___ Python tracker ___

[issue18652] Add itertools.coalesce

Tim Peters added the comment: > skipping the underscore ("firsttrue" or "nexttrue") > would arguably be more consistent with other itertools names. Like izip_longest and combinations_with_replacement? ;-) I care about readability here more than consistency with the bulk of itertools names. "f

[issue18647] re.error: nothing to repeat

Tim Peters added the comment: > Python's current regex engine isn't so coded. That's > the reason for the up-front check. It's peculiar then that nobody noticed before now that the check was so badly broken ;-) Offhand, do you have an example that displays bad behavior in 2.7? I'm curious be

[issue18652] Add itertools.first_true (return first true item in iterable)

Nick Coghlan added the comment: I concede Tim's point about itertools already using underscores where it improves readability of a name :) So, the latest state of the proposal is to add the following, preferably directly to the module, but at least as a recipe in the itertools docs: def f

[issue18078] threading.Condition to allow notify on a specific waiter

João Bernardo added the comment: I've been thinking about returning a list on "wait_for_any", but that way you will not be able to implement "wait_for" using it! "wait_for" will return False on timeouts while "wait_for_any" will return a list with some conditions(evaluates to True). Also, "wa

[issue18078] threading.Condition to allow notify on a specific waiter

Raymond Hettinger added the comment: FWIW, I don't support adding this functionality. I don't see precedents for Condition Variables behaving this way in other languages. Also, I don't think it is worth the added complexity, learning curve, and maintenance burden. Condition variables are us

[issue18658] Mercurial CPython log ticket link is broken

New submission from Vajrasky Kok: Go to http://hg.python.org/cpython. All ticket links (number preceded by #), such as #18567 refer to bugs in jython. For example: 5 hours ago R David Murray Merge: #18657: remove duplicate entries from Misc/ACKS.default tip 5 hours ago R David Murray

[issue14323] Normalize math precision in RGB/YIQ conversion

Terry J. Reedy added the comment: Can you add a reference for the coefficients? I believe def test_main(): test.support.run_unittest(ColorsysTest) if __name__ == "__main__": test_main has been and is being replaced in other test files with if __name__ == "__main__": unittest.main and sho

[issue18658] Mercurial CPython log ticket link is broken

Ned Deily added the comment: Sorry, I'm not seeing this behavior. Is it still happening for you? -- nosy: +ned.deily ___ Python tracker ___ _

[issue18651] test failures on KFreeBSD

Ronald Oussoren added the comment: I don't expect problems on OSX because of this. However: the patch replaces support.anticipate_failure by unittest.skipIf and that seems wrong to me. -- ___ Python tracker _

[issue18606] Add statistics module to standard library

Ronald Oussoren added the comment: As noted before statistics.sum seems to have the same functionality as math.fsum. Statistics.add_partial, which does the majority of the work, also references the same cookbook recipe as the math.fsum documentation. IMHO statistics.sum should be removed. -

[issue18078] threading.Condition to allow notify on a specific waiter

Charles-François Natali added the comment: > FWIW, I don't support adding this functionality. I don't see precedents for > Condition Variables behaving this way in other languages. Also, I don't > think it is worth the added complexity, learning curve, and maintenance > burden. Condition varia

[issue18658] Mercurial CPython log ticket link is broken

Vajrasky Kok added the comment: Okay, it looks like it has been fixed. The format has changed as well. Previously: 5 hours ago R David Murray Merge: #18657: remove duplicate entries from Misc/ACKS.default tip 5 hours ago R David Murray #18657: remove duplicate entries from Misc/ACKS.

[issue18651] test failures on KFreeBSD

Petr.Salinger added the comment: It is related to http://bugs.python.org/issue12958 http://bugs.python.org/issue17684 The second one changed support.anticipate_failure to unittest.skipIf -- nosy: +Petr.Salinger ___ Python tracker

[issue18532] hashlib.HASH objects should officially expose the hash name

Roundup Robot added the comment: New changeset 238c37e4c395 by Jason R. Coombs in branch 'default': Issue 18532: Added tests and documentation to formally specify the .name attribute on hashlib objects. http://hg.python.org/cpython/rev/238c37e4c395 -- nosy: +python-dev

[issue18532] hashlib.HASH objects should officially expose the hash name

Jason R. Coombs added the comment: I've confirmed the tests pass and the updated documentation renders nicely and without warnings. These changes now make the name attribute officially-supported and tested. -- resolution: -> fixed ___ Python tracke

<    1   2