[issue29073] bytearray.__mod__() truncates on first \x00

Roundup Robot added the comment: New changeset 277b36596a54 by Serhiy Storchaka in branch '3.5': Issue #29073: bytearray formatting no longer truncates on first null byte. https://hg.python.org/cpython/rev/277b36596a54 New changeset 9b77e3a586b0 by Serhiy Storchaka in branch '3.6': Issue

[issue29073] bytearray.__mod__() truncates on first \x00

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue29037] Python 2.7.13 prints version header and exits immediately on Windows 10 x64

Rüdiger Jungbeck added the comment: I have the same problem (on 2 different systems) with the win32 version in Windows 10. The problem seems to go away when I start python -S so it has something to do with site.py -- nosy: +ruediger.jungb...@rsj.de

[issue29091] Python 3.5+ socket.socketpair fallback incorrectly implemented

New submission from Seth Michael Larson: The socket.socketpair() fallback for Python 3.5+ is incorrectly implemented from the original source. The fallback doesn't provide a backlog argument to the lsock.listen() function call. When running the function it gives the following error:

[issue29087] UCS4 support functions are not implemented

Serhiy Storchaka added the comment: Thanks Victor. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29087] UCS4 support functions are not implemented

Roundup Robot added the comment: New changeset 29d46d29e169 by Serhiy Storchaka in branch '3.5': Issue #29087: Removed the documentation of non-existing UCS4 support functions. https://hg.python.org/cpython/rev/29d46d29e169 New changeset e44b6b01c8cf by Serhiy Storchaka in branch '3.6': Issue

[issue28871] Destructor of ElementTree.Element is recursive

Serhiy Storchaka added the comment: Ah, I tested only with non-debug build in which asserts were ignored! In 2.7 Element doesn't support garbage collection, and the trashcan mechanism Py_TRASHCAN_SAFE_BEGIN/Py_TRASHCAN_SAFE_END can't be applied. I see three alternatives: 1. Just revert the

[issue24288] Include/opcode.h is modified during building

Changes by Tres Seaver : -- title: permissions -> Include/opcode.h is modified during building ___ Python tracker ___

[issue24288] permissions

Changes by Tres Seaver : -- title: Include/opcode.h is modified during building -> permissions ___ Python tracker ___

[issue24288] Include/opcode.h is modified during building

Tres Seaver added the comment: ISTM that this issue should be re-opened, because it breaks out-of-tree building from a pristine / read-only source tree. If they are "public" headers, files like 'opcode.h' should be generated and checked in as part of the release process, rather than modified

[issue29059] Windows: Python not using ANSI compatible console

Joseph Hackman added the comment: Thanks for the tip! If you hadn't said that, I probably would have written it into the init scripts. I'll try to write something for python-ideas / PEP tomorrow, but have attached a quick patch here so I can link to this issue for an example implementation.

[issue29089] dictionary keys described incorrectly in tutorial

Xezlec added the comment: > Perhaps the sentence about a tuple pointing to a mutable could be tightened > up, though, by saying that if a tuple points to something that can not itself > be a dictionary key, then that tuple can not be a dictionary key. That would be great. Thank you. > I

[issue29057] Compiler failure on Mac OS X - sys/random.h

Benjamin Peterson added the comment: Right, my question is why does configure define HAVE_SYS_RANDOM_H if including sys/random.h causes an error? -- ___ Python tracker

[issue28180] sys.getfilesystemencoding() should default to utf-8

Nick Coghlan added the comment: I've now written this up as a PEP: https://github.com/python/peps/blob/master/pep-0538.txt The latest attached patch implements the specific design proposed in the PEP. Relative to the last Fedora specific patch, this tweaks the warning message wording

[issue29089] dictionary keys described incorrectly in tutorial

INADA Naoki added the comment: > If precision is the problem, could it be reworded to be more vague? "can be any immutable" seems vague enough to me. It doesn't say "cannot be any mutable type.". > Users are likely to assume documentation from any official source is the > final word. But

[issue29090] python34.dll crash

New submission from Mike Hobbs: Only info (Windows event viewer): Faulting application python_cc.exe, version 0.0.0.0, faulting module python34.dll, version 3.4.3150.1013, fault address 0x001059b7 Note: python_cc.exe is renamed python.exe to identify it in task manager. OS is Windows XP SP3

[issue29089] dictionary keys described incorrectly in tutorial

R. David Murray added the comment: It is not wrong. It does not say that keys are limited to immutables, only that immutables can be keys. Perhaps the sentence about a tuple pointing to a mutable could be tightened up, though, by saying that if a tuple points to something that can not

[issue28871] Destructor of ElementTree.Element is recursive

STINNER Victor added the comment: haypo@selma$ gdb -args ./python ~/bug.py (gdb) run python: Objects/object.c:2453: _PyTrash_thread_deposit_object: Assertion `PyObject_IS_GC(op)' failed. Program received signal SIGABRT, Aborted. (gdb) py-bt Traceback (most recent call first): File

[issue28871] Destructor of ElementTree.Element is recursive

STINNER Victor added the comment: bm_xml_etree.py benchmark started to crash on Python 2.7 because of the change 78bf34b6a713. Python 2.7 @ 78bf34b6a713: bug.py does crash Python 2.7 @ 32cc37a89b58: no crash Full script:

[issue29089] dictionary keys described incorrectly in tutorial

Xezlec added the comment: > It's the tutorial. Probably better to just leave it alone. Precise > understanding can come later. But the problem isn't that it's imprecise. It's flat-out wrong. My opinion would be that it's always a bad idea to put wrong information in the documentation,

[issue29089] dictionary keys described incorrectly in tutorial

INADA Naoki added the comment: > It's the tutorial. Probably better to just leave it alone. Precise > understanding can come later. I agree. Beginner should start using dict with builtin immutable type as key. hashable is too complex at this point. -- nosy: +inada.naoki

[issue29087] UCS4 support functions are not implemented

STINNER Victor added the comment: Py_UCS4_strlen() added by: changeset: 72475:8beaa9a37387 user:Martin v. Löwis date:Wed Sep 28 07:41:54 2011 +0200 files: ... description: Implement PEP 393. Removed by: changeset: 73236:80a7ab9ac29f user:

[issue29087] UCS4 support functions are not implemented

STINNER Victor added the comment: I recall that the very first implementation of the PEP 393 (compact strings) was heavily based on UCS4. Slowly, I optimized the code by specializing functions to each kind of string (ACSII, Latin1, UCS2, UCS4). --

[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"

Claudio Freire added the comment: I cannot be 100% sure, but we have ample evidence suggesting we're experiencing this same crash in production. We have a big system that mixes Cython and pure-python coroutines, and in one version we started seeing segfaults that strongly hint at this root

[issue28080] Allow reading member names with bogus encodings in zipfile

Stephen J. Turnbull added the comment: Thanks for followup! I was just about to write you, now that 3.6 is out. Season's Greetings! First, how do you propose to proceed with issue28115 ("use argparse for the ZipFile module")? If you expect to commit that first (I'm in no hurry for this

[issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6)

Arkadiusz MiskiewiczArkadiusz Miskiewicz added the comment: Using configure option --with-dbmliborder=gdbm:bdb (so no ndbm in it) is another reason for such failure as seems that test suite has no conditional for it. --

[issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6)

Changes by Arkadiusz Miskiewicz Arkadiusz Miskiewicz : -- nosy: +arekm ___ Python tracker ___

[issue29089] dictionary keys described incorrectly in tutorial

R. David Murray added the comment: Note that this applies equally well to python3. -- title: Python 2 dictionary keys described incorrectly -> dictionary keys described incorrectly in tutorial versions: +Python 3.6, Python 3.7 ___ Python tracker

[issue29089] Python 2 dictionary keys described incorrectly

R. David Murray added the comment: It could say 'hashable object' instead of immutable object. I don't know if hash has been introduced by that point, though. It's the tutorial. Probably better to just leave it alone. Precise understanding can come later. -- nosy: +r.david.murray

[issue29089] Python 2 dictionary keys described incorrectly

New submission from Xezlec: In section 5.5 on the page https://docs.python.org/2/tutorial/datastructures.html#dictionaries the requirements given for dictionary keys are not correct. Specifically, it is claimed that only immutable objects (and tuples containing only immutable objects) may be

[issue29088] Inconsistent use of underscore in names that start with "is"

R. David Murray added the comment: Yep, that would be nice. But Python has evolved over time, and we must maintain backward compatibility. The names are what they are. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed

[issue29088] Inconsistent use of underscore in names that start with "is"

New submission from Kodiologist: Compare ``isinstance``, ``issubclass``, and ``islower`` to ``is_integer``, ``is_fifo``, and ``is_enabled``. In Python 3.6, of all the names in the standard library starting with ``is``, I count 69 names with the underscore and 91 without. It seems better to

[issue29058] Mark new limited C API

Steve Dower added the comment: You've described it correctly. > The problem is that the warning should be emitted only for users that use > incorrect API. But it shouldn't be emitted for users that use just 3.2 API This is why I suggested #warn and not #error. It's okay to ignore warnings if

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Sorry, but perhaps I don't fully understand you. It is legitimately to just define Py_LIMITED_API without requiring specific version: #define Py_LIMITED_API In that case you can use the stable API of the version 3.2, but can't use

[issue29080] unnecessary hg required for build version 3.6 on Windows

Changes by Steve Dower : -- stage: -> needs patch type: behavior -> compile error versions: +Python 3.7 ___ Python tracker ___

[issue29080] unnecessary hg required for build version 3.6 on Windows

Steve Dower added the comment: You're right. I moved that code from buildrelease.bat, which definitely requires hg. PC/build.bat should not fail if hg can't be found. You'll just end up with an empty sys._mercurial/sys.version after building. -- assignee: -> steve.dower

[issue29058] Mark new limited C API

Steve Dower added the comment: > Just defining Py_LIMITED_API actually implies =0x0302. That's the intent, but if it were actually the case then this issue wouldn't exist :) On 3.5.3, building with Py_LIMITED_API=1 will include APIs that should only be included when

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Changes by Serhiy Storchaka : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___

[issue28446] pyvenv generates malformed hashbangs for scripts

Vinay Sajip added the comment: As an extra data point, note the behaviour on Windows: C:\Users\Vinay> \python34\python -m venv "\Temp\aaa bbb"

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Eryk Sun added the comment: > It's presumably failing to read nonblocking random from CrpytGen > and falling back to seeding using time and pid. Yes and no. CryptGenRandom is not failing, but it is nonetheless calling random_seed_time_pid: >>> r = random.Random() Breakpoint 0 hit

[issue29087] UCS4 support functions are not implemented

New submission from Serhiy Storchaka: There is a special section in the documentation of Unicode Objects C API: UCS4 Support. https://docs.python.org/3/c-api/unicode.html#ucs4-support It documents utility functions that work on strings of Py_UCS4 characters like Py_UCS4_strlen(),

[issue29086] Document C API that is not part of the limited API

New submission from Serhiy Storchaka: >From the documentation: https://docs.python.org/3/c-api/stable.html In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API." But they don't. Following sample patch adds the notes to

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

Jason R. Coombs added the comment: That also looks good. $ head -n1 ~/.envs/issue22490/bin/cherryd #!/Users/jaraco/.envs/issue22490/bin/python -- ___ Python tracker

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Kyle Altendorf added the comment: time.sleep(0) and time.sleep(0.0) acted the same for me and both exhibited matching 'random' values in some cases. (win10, python3.6) I also printed time.time() with each 'random' value and it wasn't a perfect match but matching times tended to go with

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Ammar Askar added the comment: Can recreate under Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 and on latest master. -- nosy: +ammar2 versions: +Python 3.7 ___ Python tracker

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Donald Stufft added the comment: It's presumably failing to read nonblocking random from CrpytGen and falling back to seeding using time and pid. -- nosy: +dstufft ___ Python tracker

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Ned Batchelder added the comment: Adding a time.sleep(0.001) (or maybe even just 0) between the calls prevents the problem. -- ___ Python tracker ___

[issue20486] msilib: can't close opened database

Changes by 12345 67890 : Removed file: http://bugs.python.org/file45971/Add_ability_to_close_MSI_database_.patch ___ Python tracker ___

[issue20486] msilib: can't close opened database

12345 67890 added the comment: The method is now capitalized. Unfortunately, none of the methods are compliant with PEP formatting, but it's far too late to do anything about that. -- Added file: http://bugs.python.org/file46056/Add_ability_to_close_MSI_database_.patch

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Changes by Kyle Altendorf : -- nosy: +altendky ___ Python tracker ___ ___ Python-bugs-list

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Changes by Ned Batchelder : -- versions: +Python 3.6 ___ Python tracker ___ ___

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

New submission from Ned Batchelder: Creating two Random() instances in quick succession produces the same sequence, but only on Windows on Python 3.6. On 3.5 or earlier, or on Mac/Linux, the randomization is good. Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

Vinay Sajip added the comment: Thanks. It's worth checking what shebang was written to a script that was installed into the venv - e.g. cherryd. -- ___ Python tracker

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

Jason R. Coombs added the comment: On Python 3.6, I made the edit. I actually used the one-liner ` os.environ.pop('__PYVENV_LAUNCHER__', None)`. I then created a venv and installed a package and successfully ran a module in that package: $ python -m venv ~/.envs/issue22490-test $

[issue29084] C API of OrderedDict

Brett Cannon added the comment: If the API is broken in the limited API then I definitely think we should consistently make it not part of the limited API. As for removing it I don't have an opinion without knowing how many people are using it. -- nosy: +brett.cannon

[issue28818] simplify lookdict functions

INADA Naoki added the comment: http://bugs.python.org/issue28427#msg284101 > Sidenote: all branches now have a different version of dict object each, > which makes maintenance really painful... Large difference between py36 and py37 is this patch. Can I backport this to py36 to ease

[issue29061] secrets.randbelow(-1) hangs

Brendan Donegan added the comment: If I'm not mistaken, _randbelow is defined in Random, which SystemRandom inherits from. Just for clarity On Tue, 27 Dec 2016 at 22:08 Josh Rosenberg wrote: > > Josh Rosenberg added the comment: > > SystemRandom._randbelow has this

[issue29061] secrets.randbelow(-1) hangs

Josh Rosenberg added the comment: SystemRandom._randbelow has this problem, perhaps it should be fixed there, not in one of many possible wrappers for it? -- nosy: +josh.r ___ Python tracker

[issue29082] In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects

Chi Hsuan Yen added the comment: Sorry, but I'm afraid of being unable to test it. I tried to setup a Windows build environment for 2.x but failed. (I've once successfully built 3.x on Windows for issue25939, but things seems different now :( -- keywords: +patch Added file:

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Just defining Py_LIMITED_API actually implies =0x0302. I have no idea where a #warn can be added. -- ___ Python tracker

[issue28915] Modify PyObject_CallFunction() to use fast call internally

Roundup Robot added the comment: New changeset fa9933bf4ea0 by Serhiy Storchaka in branch 'default': Issue #28915: Exclude _Py_VaBuildStack from the limited API. https://hg.python.org/cpython/rev/fa9933bf4ea0 -- ___ Python tracker

[issue23903] Generate PC/python3.def by scraping headers

Roundup Robot added the comment: New changeset 2e5ad97c9c19 by Serhiy Storchaka in branch '3.5': Issue #23903: Added missed Windows-specific names to PC/python3.def. https://hg.python.org/cpython/rev/2e5ad97c9c19 New changeset 86a412584c02 by Serhiy Storchaka in branch '3.6': Issue #23903:

[issue29080] unnecessary hg required for build version 3.6 on Windows

Changes by Ned Deily : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___

[issue28446] pyvenv generates malformed hashbangs for scripts

Vinay Sajip added the comment: To reiterate Alex Regueiro's point, I don't think this is a bug, but a shortcoming of the underlying Berkeley exec(2) implementation. See this post: https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html We can leave the implementation as is, as on

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

Vinay Sajip added the comment: I'm not sure if msg230947 is still correct, and it seems neater to remove __PYVENV_LAUNCHER__ from where it's defined in the first place (the stub launcher C file) if it was just a shim needed around the time the functionality was developed (pre the 3.3

[issue23903] Generate PC/python3.def by scraping headers

Steve Dower added the comment: Unfortunately, there's no way too remove defined names from the DLL during Python 3 at all, except where the prototype was never provided. PyCFunction_New has always been a macro, and PySys_SetDefaultEncoding looks to have been removed before the API was

[issue29056] logging.Formatter doesn't respect more than one formatException()

Vinay Sajip added the comment: Perhaps I will try to make it even clearer, but to be fair, the format() documentation is just a few paragraphs above the formatException() documentation. It's all in the section entitled "Formatter Objects", and it's IMO reasonable to expect the whole

[issue29058] Mark new limited C API

Steve Dower added the comment: Can we add a #warn to the headers then? So people know that just defining Py_LIMITED_API actually implies =0x0305 (or whatever value is appropriate)? -- ___ Python tracker

[issue29056] logging.Formatter doesn't respect more than one formatException()

Dan Passaro added the comment: If there's no interest in changing the behavior I'd at least suggest that this caching is mentioned in the docs for the formatException() method specifically, with some kind of attention-grabbing note. (Right now this behavior is only explained in the format()

[issue28427] WeakValueDictionary next bug (with multithreading)

Antoine Pitrou added the comment: I've pushed the fixes now. It does introduce a small amount of additional code duplication in dictobject.c, but nothing unmanageable. Sidenote: all branches now have a different version of dict object each, which makes maintenance really painful...

[issue28427] WeakValueDictionary next bug (with multithreading)

Roundup Robot added the comment: New changeset 9acdcafd1418 by Antoine Pitrou in branch '2.7': Issue #28427: old keys should not remove new values from https://hg.python.org/cpython/rev/9acdcafd1418 -- ___ Python tracker

[issue29082] In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects

Serhiy Storchaka added the comment: Good catch Chi Hsuan Yen! This is my mistake, I though PyString_Size() works only with str (as many similar *_Size() functions). Agreed, this change should be reverted. Do you want provide the patch with tests? -- keywords: +easy (C) stage: ->

[issue29084] C API of OrderedDict

New submission from Serhiy Storchaka: C API of the C implementation of OrderedDict was added in 3.5 together with the C implementation of OrderedDict. But it was never announced nor documented. Some macros contain bugs. PyODict_Check() and PyODict_CheckExact() are declared in the limited API,

[issue29083] Readd PyArg_VaParse to the stable API

New submission from Serhiy Storchaka: Seems PyArg_VaParse() and PyArg_VaParseTupleAndKeywords() were excluded from the stable API by the mistake in fixing issue11626. These functions was in the stable API before 3.3, and the documentation doesn't mention that they are not in the stable API.

[issue23903] Generate PC/python3.def by scraping headers

Changes by Serhiy Storchaka : -- dependencies: +Readd PyArg_VaParse to the stable API ___ Python tracker ___

[issue28427] WeakValueDictionary next bug (with multithreading)

Roundup Robot added the comment: New changeset b8b0718d424f by Antoine Pitrou in branch '3.5': Issue #28427: old keys should not remove new values from https://hg.python.org/cpython/rev/b8b0718d424f New changeset 97d6616b2d22 by Antoine Pitrou in branch '3.6': Issue #28427: old keys should not

[issue19120] shlex.shlex.lineno reports a different number depending on the previous token

Changes by Christopher Hoadley : -- nosy: +hoadlck versions: +Python 3.6 ___ Python tracker ___

[issue16121] shlex.shlex.error_leader() reports incorrect line number

Changes by Christopher Hoadley : -- nosy: +hoadlck versions: +Python 3.6 ___ Python tracker ___

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Changes are not applied to 3.5. It is harder to do since many private functions in 3.5 are still available in limited API. And there is a risk to break third-party code that defines Py_LIMITED_API, but uses API with higher version than required. --

[issue24869] shlex lineno inaccurate with certain inputs

Changes by Christopher Hoadley : -- type: -> behavior versions: +Python 3.6 ___ Python tracker ___

[issue27650] Implement `__repr__` methods for logging.Logger and others

Vinay Sajip added the comment: This sounds like a Celery bug, so I don't propose to change anything in this area. -- ___ Python tracker ___

[issue29056] logging.Formatter doesn't respect more than one formatException()

Changes by Vinay Sajip : -- status: open -> closed ___ Python tracker ___ ___

[issue28998] Unifying Long Integers and Integers in 2.7

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue28998] Unifying Long Integers and Integers in 2.7

Roundup Robot added the comment: New changeset ffcb321ba9c0 by Serhiy Storchaka in branch '2.7': Issue #28998: More APIs now support longs as well as ints. https://hg.python.org/cpython/rev/ffcb321ba9c0 -- nosy: +python-dev ___ Python tracker

[issue29058] Mark new limited C API

Roundup Robot added the comment: New changeset f26c16aba11e by Serhiy Storchaka in branch '3.6': Issue #29058: All stable API extensions added after Python 3.2 are now https://hg.python.org/cpython/rev/f26c16aba11e New changeset 77f5f31bf699 by Serhiy Storchaka in branch 'default': Issue

[issue29061] secrets.randbelow(-1) hangs

Brendan Donegan added the comment: Ok, here's a second version of the patch. Normally I don't like testing multiple things in one test but I've gone with what seems to be the convention here in test_secrets.py -- Added file:

[issue27650] Implement `__repr__` methods for logging.Logger and others

Changes by Felix Yan : -- nosy: +felixonmars ___ Python tracker ___ ___

[issue27650] Implement `__repr__` methods for logging.Logger and others

lilydjwg added the comment: This hangs this test from celery: https://github.com/celery/celery/blob/master/t/unit/app/test_log.py#L72 It constructs a Logger with `.parent` to itself, making getEffectiveLevel loop forever. The code tries to raise an exception when such loops are detected, but

[issue20486] msilib: can't close opened database

Berker Peksag added the comment: Thanks for the patch, 12345. Steve knows better, but I think the method should be named "Close" instead of "close" like _msi.View's Close method. Also, I couldn't apply your patch: $ hg imp

[issue29069] Default PyPI URL in docs is not what is really in code

Berker Peksag added the comment: Thanks! -- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5, Python 3.6 ___ Python tracker

[issue29069] Default PyPI URL in docs is not what is really in code

Roundup Robot added the comment: New changeset c4cd7e00a640 by Berker Peksag in branch '3.5': Issue #29069: Update the default URL of PyPI server https://hg.python.org/cpython/rev/c4cd7e00a640 New changeset b1ccf713e8f8 by Berker Peksag in branch '3.6': Issue #29069: Merge from 3.5

[issue29025] random.seed() relation to hash() function and its determinism is vague

Raymond Hettinger added the comment: This is out of date. See http://bugs.python.org/issue27706 -- resolution: -> out of date status: open -> closed ___ Python tracker

[issue29056] logging.Formatter doesn't respect more than one formatException()

Raymond Hettinger added the comment: Can we close this? -- nosy: +rhettinger status: pending -> open ___ Python tracker ___

[issue12276] 3.x ignores sys.tracebacklimit=0

Anand Reddy Pandikunta added the comment: This patch fixes the issue. I have also added 2 test cases to make sure it works. -- keywords: +patch nosy: +ChillarAnand -docs@python Added file: http://bugs.python.org/file46053/Limit-traceback-if-sys.tracebacklimit-is-set.patch

[issue29011] No entry Deque in typing.py

Changes by Raymond Hettinger : Added file: http://bugs.python.org/file46052/Deque2.diff ___ Python tracker ___

[issue23903] Generate PC/python3.def by scraping headers

Roundup Robot added the comment: New changeset d95fee442e27 by Serhiy Storchaka in branch '3.5': Issue #23903: Added missed names to PC/python3.def. https://hg.python.org/cpython/rev/d95fee442e27 New changeset cb864fc4b3be by Serhiy Storchaka in branch '3.6': Issue #23903: Added missed names to

[issue29061] secrets.randbelow(-1) hangs

Brendan Donegan added the comment: Hi Raymond, I have done that when creating the patch and have confirmation in my inbox - perhaps Ewa hasn't filed it yet? On Tue, 27 Dec 2016 at 14:43 Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Brendan,

[issue29082] In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects

New submission from Chi Hsuan Yen: In issue27330, there's one more change besides fixing possible memory leaks. In LoadLibrary function of _ctypes: [1] -if (!PyArg_ParseTuple(args, "O|O:LoadLibrary", , )) +if (!PyArg_ParseTuple(args, "S|O:LoadLibrary", , )) Before this change, both

[issue29081] time.strptime() return wrong result

New submission from hywl51: In [1]:import time In [2]: time.strptime('2016 52 0', '%Y %W %w') Out[2]: time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=367, tm_isdst=-1) When given the parameters above, the function return the struct_time

[issue23903] Generate PC/python3.def by scraping headers

Roundup Robot added the comment: New changeset 8423f86486b3 by Serhiy Storchaka in branch '3.5': Issue #23903: Fixed errors and remove non-existing names in python3.def. https://hg.python.org/cpython/rev/8423f86486b3 New changeset b5470d08969c by Serhiy Storchaka in branch '3.6': Issue #23903:

  1   2   >