[issue26069] Remove the Deprecated API in trace module

Emanuel Barry added the comment: You seem to have forgotten to include a patch. -- nosy: +ebarry ___ Python tracker ___ ___ Python-bug

[issue26069] Remove the Deprecated API in trace module

Senthil Kumaran added the comment: Sorry for that. Here is the patch. -- keywords: +patch Added file: http://bugs.python.org/file41562/issue26069.patch ___ Python tracker ___ ___

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Looks good to me. Feel free to check it in, Mark, or one of us will get to it if you're not set up for committing right now. -- ___ Python tracker ___

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

Steve Dower added the comment: I don't think Vinay does much wrt the launcher in core anymore, it's mostly been me recently. I don't see any harm in this change, though I'll admit I also don't see the point. When is the launcher ever going to find Python built in-place? -- __

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: I would call SetDllDirectory instead of changing the current directory. This replaces the current directory in the DLL search. Then call SetDllDirectory(NULL) to restore the default before returning. When you say "the CRT assembly", you're talking about vcruntime14

[issue26072] pdb fails to access variables closed over

New submission from Antony Lee: Consider the following example: def f(x=1): def g(): y = 2 raise Exception g() f() $ python -mpdb -ccontinue example.py <... traceback ...> > /tmp/example.py(4)g() -> raise Exception (Pdb) p x # this can be wor

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: In this case, it needs to load vcruntime for the python##.dll, so linking isn't going to make any difference. We need to statically link the loader, since it will be run independently and can't have any dependencies, but when it finds a Python install and loads t

[issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title

Senthil Kumaran added the comment: @Martin, thanks for the review comments. I've addressed this is version 2 of the patch. I am submitting this change. -- versions: +Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41563/Issue23675-v2.patch

[issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title

Roundup Robot added the comment: New changeset 9ba001cb107b by Senthil Kumaran in branch '3.5': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/9ba001cb107b New changeset 60d4c3a29201 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.

[issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title

Roundup Robot added the comment: New changeset 99f5276e4197 by Senthil Kumaran in branch '2.7': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/99f5276e4197 -- ___ Python tracker

[issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title

Senthil Kumaran added the comment: Fixed in the active documentation branches 2.7,3.5 and 3.6. -- assignee: docs@python -> orsenthil resolution: -> fixed status: open -> closed ___ Python tracker _

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: > We'd have to statically link python##.dll. I was talking about the partially static build that you used for wininst-14.0-amd64.exe in rc3, in which vcruntime is linked statically but ucrt is linked dynamically (actually to the api-ms-win-crt-* API sets). But is th

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: Steve, I think I understand the linking problem now -- in terms of the bad assumption I mentioned in the previous message. Mark said the "built binary links against the DLL version of the CRT", but I just checked in 3.5.1 that you actually didn't switch that one to

[issue26073] Update the list of magic numbers in launcher

New submission from Serhiy Storchaka: There is a list of magic numbers in PC/launcher.c for mapping magic number to Python version. But it ends on 3.3 (and even only on 3.3a0). Proposed patch updates the list (by values taken from Lib/importlib/_bootstrap_external.py). -- components: W

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

Mark Hammond added the comment: > When is the launcher ever going to find Python built in-place? On the machine that built Python in-place :) I have a dev environment where all Python versions and pywin32 are built and that's the environment where py.exe is failing. My build scripts use py.exe

[issue26066] Language on the "Cryptographic Services" documentation page is out of date

Roundup Robot added the comment: New changeset 84fdbdd483a3 by Benjamin Peterson in branch '2.7': delete old crypto prose (closes #26066) https://hg.python.org/cpython/rev/84fdbdd483a3 New changeset d8944e059c7f by Benjamin Peterson in branch '3.4': delete old crypto prose (closes #26066) https:

<    1   2