[2.7] Distutils msvc9 win81 #4242
Conversation
Also backport new functions temp_dir() and python_is_optimized(). temp_cwd() now accepts None as a name (means using tempfile.mkdtemp). check_syntax_error() now accepts arguments lineno and offset. Use more specific error messages in get_attribute().
…nish (#1583) * bpo-30357 each test in test_thread waits until all spawn threads finish * bpo-30357 each test in test_thread waits until all spawn threads finish * bpo-30357: test_thread now uses threading_cleanup() (#1592) test_thread: setUp() now uses support.threading_setup() and support.threading_cleanup() to wait until threads complete to avoid random side effects on following tests. Co-Authored-By: Victor Stinner <victor.stinner@gmail.com> * bpo-30357: test_thread now uses threading_cleanup() (#1592) test_thread: setUp() now uses support.threading_setup() and support.threading_cleanup() to wait until threads complete to avoid random side effects on following tests. Co-Authored-By: Victor Stinner <victor.stinner@gmail.com>
* Use explicit numbering for footnotes referred by explicit number. * Fix literal strings formatting in howto/urllib2.rst. * Add `:noindex:` to duplicated definition of list. * Update susp-ignored.csv for reference/expressions.rst. (cherry picked from commit d97b7dc)
Running Python with the -3 option now emits deprecation warnings for getchildren() and getiterator() methods of the Element class in the xml.etree.cElementTree module and when pass the html argument to xml.etree.ElementTree.XMLParser(). Fixed a deprecation warning about the doctype() method of the xml.etree.ElementTree.XMLParser class. Now it is emitted only when define the doctype() method in the subclass of XMLParser. Fixed a bug in the test_bug_200708_close test method. An EchoTarget instance was incorrectly passed to XMLParser() as the html argument and silently ignored. Tests no longer failed when use the -m option for running only selected test methods. Checking warnings now is more specific, warnings are expected only when use deprecated features.
Ran the docstrings through spell checker, and fixed spelling issues.
…oop on exc (GH-1683) (#1817) * bpo-30414: multiprocesing.Queue._feed do not break from main loop on exc Queue background running thread was not handling exceptions correctly. Any exception occurred inside thread (putting unpickable object) cause feeder to finish running. After that every message put into queue is silently ignored. * bpo-30414: multiprocesing.Queue._feed do not break from main loop on exc Queue background running thread was not handling exceptions correctly. Any exception occurred inside thread (putting unpickable object) cause feeder to finish running. After that every message put into queue is silently ignored.. (cherry picked from commit bc50f03)
…#1858) This fixes a faulty backport to the Python 2.7 branch only of http://bugs.python.org/issue28032. Details in the bpo-29766.
laranzu
requested review from
gpshead,
ncoghlan,
rhettinger,
skrah,
terryjreedy and
a team
as code owners
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
|
Thanks for the PR. A couple issues:
|
|
This PR is drastically wrong. After getting a tracker username, signing the contributor agreement, opening an issue, nosying the windows experts, and getting approval from one of them, most likely Zach Ware, it needs to be redone properly as a small patch to the appropriate branches. If it is a good thing to do, it might be applicable to all current branches. Or one of the experts might point out how to do what you want without a patch. This is not my field of expertise. |
|
On Fri, Nov 3, 2017 at 10:58 AM, Mariatta ***@***.***> wrote:
Does this need to have the target base branch 2.7 instead of master?
I didn't know, first time trying this so I was just working through
the steps on the web page "Life cycle of a pull request".
Will submit a new pull request against the 2.7 branch after creating an issue.
I haven't looked at your changes, but from what you described it doesn't seem trivial, so you'll need to create an issue in https://bugs.python.org
It's two lines of code plus a comment, so I thought trivial.
…--
cheers,
Hugh Fisher
|
|
To compile Python 2.7 extensions with the Visual C Tools for Python 2.7, you should be using setuptools in your At least that's my understanding - @zooba may be able to clarify further. Sorry if I've misunderstood the intention of this PR, it's currently showing as changing 2000+ files (probably because of the switch of target from master to 2.7), so it's not really reviewable in its current form. |
|
Perhaps patches are easier after all than GitHub ... This would of course contradict the official doctrine so it cannot be true. |
|
On Fri, Nov 3, 2017 at 7:53 PM, Paul Moore ***@***.***> wrote:
To compile Python 2.7 extensions with the Visual C Tools for Python 2.7, you should be using setuptools in your setup.py. The support needed for the Visual C tools was added to setuptools rather than to core distutils, as I understand it, and that was a deliberate choice (as it means users don't need to upgrade their Python simply to build extensions.
At least that's my understanding - @zooba may be able to clarify further.
Sorry if I've misunderstood the intention of this PR, it's currently showing as changing 2000+ files (probably because of the switch of target from master to 2.7), so it's not really reviewable in its current form.
I am using setuptools with a setup.py, which ends up calling msvc9compiler.py
My fault as to intention, the actual change is two new lines of code
and a comment. I screwed up the pull request, will be trying again.
…--
cheers,
Hugh Fisher
|
|
On Fri, Nov 3, 2017 at 8:22 PM, Stefan Krah ***@***.***> wrote:
Perhaps patches are easier after all than GitHub ... This would of course contradict the official doctrine so it cannot be true.
Patches are easier for a small project with fewer contributors. This
is the first time I've ever made
a pull request on GitHub, and it would almost certainly have been
problem free (in the sense of
being correctly formed, not in the sense that my code patch would have
been accepted) if I'd
been making a change to the current version of Python rather than the
ancient 2.7
…--
cheers,
Hugh Fisher
|
|
On Fri, Nov 03, 2017 at 10:16:01AM +0000, Hugh Fisher wrote:
On Fri, Nov 3, 2017 at 8:22 PM, Stefan Krah ***@***.***> wrote:
> Perhaps patches are easier after all than GitHub ... This would of course contradict the official doctrine so it cannot be true.
>
Patches are easier for a small project with fewer contributors.
My remark was against the offical CPython doctrine, not against you. :-)
Sorry if it came across differently.
These large mis-merges happen about twice a week. They never happened
in the previous mercurial setup. I conclude that GitHub isn't as easy
as advertised.
There is a considerable body of opinion outside CPython that PRs are not
optimal even for a large project:
torvalds/linux#17 (comment)
|
|
Discussions of PR process aside, I can only guess what the change here is meant to be, but I'd suggest searching bugs.python.org for existing bugs. Especially those that are closed as rejected or have extended discussion after they were completed. If you don't find anything, or aren't satisfied with the responses, open a new bug and we can discuss it there. |
|
Steve: The intended change here is commit c59773e with comment 'Look for vcvarsall...', The message is just above your comment. Clicking either the comment or hash shows just the 3 line diff, isolated from the 300000+ line total diff. Hugh: When you click the Create PR button, github lists all the commits that would be included in the PR. It there is anything other than your commit or commits, something is wrong and one should stop and not continue. |
|
I'm guessing the commit was made against an outdated local 2.7 branch. Even though the change is only 2 lines, it's a code change, and will require a news entry. Most of the times, only typo fixes are considered as "trivial". |
|
New issue created 31932, with reference to previous issue where this bug may have been identified but not fixed. Thank you everybody for telling me what I did wrong. Valuable learning experience and I hope to make different mistakes next time. Next step I believe is for a core developer to reject this request? |
|
I already did when I closed it. And by the way, my advice to carefully look at the list of commits to be included is based on experience ;-). |
Fix bug: setup.py cannot find vcversall.bat on MSWin 8.1 if installed in user AppData
I could not build a native extension for Python 2.7 on my MS Windows 8.1 system because VCVARSALL.BAT could not be found, even after restarting everything. Eventually worked out that the Python 2.7 CLI compiler tools installer had put the files in a subdirectory of the invisible user AppData instead of a system wide directory. (Possibly because I did not run the installer as administrator?)
Pull request adds a couple of lines of code to look for vcvarsall.bat under AppData if not fould elsewhere.