[issue17445] Handle bytes comparisons in difflib.Differ

Changes by Berker Peksag : -- stage: commit review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23974] random.randrange() biased output

Raymond Hettinger added the comment: > we *still* have no documented guarantees of reproducibility, > so maybe it's safe to go ahead and change this. Raymond? It is documented here: https://docs.python.org/3/library/random.html#notes-on-reproducibility The idea that is that algorithms (and t

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Yury Selivanov added the comment: Attaching a revised patch (all Victor's comments but asyncio changes) -- Added file: http://bugs.python.org/file39155/await_02.patch ___ Python tracker

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Changes by Yury Selivanov : -- assignee: -> yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue8548] Building on CygWin 1.7: PATH_MAX redefined

Masayuki Yamamoto added the comment: This issue resolved on default branch in #20597 . In 3.4 branch latest, PATH_MAX seems unused already in Modules/main.c:12 and Python/pythonrun.c:35. I want to cherry-pick #20597 to 3.4 branch. -- nosy: +masamoto ___

[issue24019] str/unicode encoding kwarg causes exceptions

New submission from Mahmoud Hashemi: The encoding keyword argument to the Python 3 str() and Python 2 unicode() constructors is excessively constraining to the practical use of these core types. Looking at common usage, both these constructors' primary mode is to convert various objects into

[issue24018] add a Generator ABC

Stefan Behnel added the comment: Here's a new patch that addresses the review comments. I kept throw() and close() non-abstract and added an example to the tests instead that implements a minimal generator by inheriting these methods from the Generator base class, using it as a mixin. It only

[issue24018] add a Generator ABC

Stefan Behnel added the comment: > Is it a problem that the check can't be done in a fast way from C code? C code can still quickly special case the generator type in the positive case, and it will usually be interested in an exact type match anyway. Determining that an object is *not* (compat

[issue24018] add a Generator ABC

Stefan Behnel added the comment: Next question: should inspect.isgenerator() be changed? Or should its usages be replaced by isinstance(obj, Generator) ? -- ___ Python tracker _

[issue24018] add a Generator ABC

Martin Panter added the comment: I agree that there is no big reason why we should force generators to stop working after close(). Your new default implementation of close() is probably the right thing too. I added a few new comments on Reitveld. -- ___

[issue24018] add a Generator ABC

Stefan Behnel added the comment: Good catch with the RuntimeError. Patch updated. -- Added file: http://bugs.python.org/file39157/generator_abc.patch ___ Python tracker ___ _

[issue24018] add a Generator ABC

Stefan Behnel added the comment: > should inspect.isgenerator() be changed? Replying to myself, one thing that speaks against this approach is that "inspect" also has the functions "getgeneratorlocals()" and "getgeneratorstate()", which depend on "gen.gi_frame". Cython could emulate that, but

<    1   2