Mailman 3 September 2015 - Python-checkins

cpython: Fix regrtest --coverage on Windows
by victor.stinner 01 Oct '15

01 Oct '15

https://hg.python.org/cpython/rev/0f10e0b3e76d changeset: 98443:0f10e0b3e76d user: Victor Stinner <victor.stinner(a)gmail.com> date: Thu Oct 01 00:53:09 2015 +0200 summary: Fix regrtest --coverage on Windows Issue #25260: Fix ``python -m test --coverage`` on Windows. Remove the list of ignored directories. files: Lib/test/libregrtest/main.py | 5 +---- Lib/test/test_regrtest.py | 2 -- Misc/NEWS | 3 +++ 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/Lib/test/libregrtest/main.py b/Lib/test/libregrtest/main.py --- a/Lib/test/libregrtest/main.py +++ b/Lib/test/libregrtest/main.py @@ -272,10 +272,7 @@ def run_tests_sequential(self): if self.ns.trace: import trace - self.tracer = trace.Trace(ignoredirs=[sys.base_prefix, - sys.base_exec_prefix, - tempfile.gettempdir()], - trace=False, count=True) + self.tracer = trace.Trace(trace=False, count=True) save_modules = sys.modules.keys() diff --git a/Lib/test/test_regrtest.py b/Lib/test/test_regrtest.py --- a/Lib/test/test_regrtest.py +++ b/Lib/test/test_regrtest.py @@ -605,8 +605,6 @@ % (self.TESTNAME_REGEX, len(tests))) self.check_line(output, regex) - @unittest.skipIf(sys.platform == 'win32', - "FIXME: coverage doesn't work on Windows") def test_coverage(self): # test --coverage test = self.create_test() diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -157,6 +157,9 @@ Tests ----- +- Issue #25260: Fix ``python -m test --coverage`` on Windows. Remove the + list of ignored directories. + - PCbuild\rt.bat now accepts an unlimited number of arguments to pass along to regrtest.py. Previously there was a limit of 9. -- Repository URL: https://hg.python.org/cpython

1 0

cpython: Backout change 28d3bcb1bad6: "Try to fix _PyTime_AsTimevalStruct_impl() on
by victor.stinner 01 Oct '15

01 Oct '15

https://hg.python.org/cpython/rev/4bbe95f0a57b changeset: 98442:4bbe95f0a57b user: Victor Stinner <victor.stinner(a)gmail.com> date: Wed Sep 30 22:50:12 2015 +0200 summary: Backout change 28d3bcb1bad6: "Try to fix _PyTime_AsTimevalStruct_impl() on OpenBSD", I'm not sure that the change was really needed. I read the test result of an old build because the OpenBSD was 100 builds late. files: Python/pytime.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Python/pytime.c b/Python/pytime.c --- a/Python/pytime.c +++ b/Python/pytime.c @@ -454,7 +454,7 @@ _PyTime_AsTimevalStruct_impl(_PyTime_t t, struct timeval *tv, _PyTime_round_t round, int raise) { - _PyTime_t secs, secs2; + _PyTime_t secs; int us; int res; @@ -467,8 +467,7 @@ #endif tv->tv_usec = us; - secs2 = (_PyTime_t)tv->tv_sec; - if (res < 0 || secs2 != secs) { + if (res < 0 || (_PyTime_t)tv->tv_sec != secs) { if (raise) error_time_t_overflow(); return -1; -- Repository URL: https://hg.python.org/cpython

1 0

peps: PEP 507, GitLab
by barry.warsaw 30 Sep '15

30 Sep '15

https://hg.python.org/peps/rev/7a68ed3b135b changeset: 6103:7a68ed3b135b user: Barry Warsaw <barry(a)python.org> date: Wed Sep 30 16:03:03 2015 -0400 summary: PEP 507, GitLab files: pep-0507.txt | 303 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 303 insertions(+), 0 deletions(-) diff --git a/pep-0507.txt b/pep-0507.txt new file mode 100644 --- /dev/null +++ b/pep-0507.txt @@ -0,0 +1,303 @@ +PEP: 507 +Title: Migrate CPython to Git and GitLab +Version: $Revision$ +Last-Modified: $Date$ +Author: Barry Warsaw <barry(a)python.org> +Status: Draft +Type: Process +Content-Type: text/x-rst +Created: 2015-09-30 +Post-History: + + +Abstract +======== + +This PEP proposes migrating the repository hosting of CPython and the +supporting repositories to Git. Further, it proposes adopting a +hosted GitLab instance as the primary way of handling merge requests, +code reviews, and code hosting. It is similar in intent to PEP 481 +but proposes an open source alternative to GitHub and omits the +proposal to run Phabricator. As with PEP 481, this particular PEP is +offered as an alternative to PEP 474 and PEP 462. + + +Rationale +========= + +CPython is an open source project which relies on a number of +volunteers donating their time. As with any healthy, vibrant open +source project, it relies on attracting new volunteers as well as +retaining existing developers. Given that volunteer time is the most +scarce resource, providing a process that maximizes the efficiency of +contributors and reduces the friction for contributions, is of vital +importance for the long-term health of the project. + +The current tool chain of the CPython project is a custom and unique +combination of tools. This has two critical implications: + +* The unique nature of the tool chain means that contributors must + remember or relearn, the process, workflow, and tools whenever they + contribute to CPython, without the advantage of leveraging long-term + memory and familiarity they retain by working with other projects in + the FLOSS ecosystem. The knowledge they gain in working with + CPython is unlikely to be applicable to other projects. + +* The burden on the Python/PSF infrastructure team is much greater in + order to continue to maintain custom tools, improve them over time, + fix bugs, address security issues, and more generally adapt to new + standards in online software development with global collaboration. + +These limitations act as a barrier to contribution both for highly +engaged contributors (e.g. core Python developers) and especially for +more casual "drive-by" contributors, who care more about getting their +bug fix than learning a new suite of tools and workflows. + +By proposing the adoption of both a different version control system +and a modern, well-maintained hosting solution, this PEP addresses +these limitations. It aims to enable a modern, well-understood +process that will carry CPython development for many years. + + +Version Control System +---------------------- + +Currently the CPython and supporting repositories use Mercurial. As a +modern distributed version control system, it has served us well since +the migration from Subversion. However, when evaluating the VCS we +must consider the capabilities of the VCS itself as well as the +network effect and mindshare of the community around that VCS. + +There are really only two real options for this, Mercurial and Git. +The technical capabilities of the two systems are largely equivalent, +therefore this PEP instead focuses on their social aspects. + +It is not possible to get exact numbers for the number of projects or +people which are using a particular VCS, however we can infer this by +looking at several sources of information for what VCS projects are +using. + +The Open Hub (previously Ohloh) statistics [#openhub-stats]_ show that +37% of the repositories indexed by The Open Hub are using Git (second +only to Subversion which has 48%) while Mercurial has just 2%, beating +only Bazaar which has 1%. This has Git being just over 18 times as +popular as Mercurial on The Open Hub. + +Another source of information on VCS popularity is PyPI itself. This +source is more targeted at the Python community itself since it +represents projects developed for Python. Unfortunately PyPI does not +have a standard location for representing this information, so this +requires manual processing. If we limit our search to the top 100 +projects on PyPI (ordered by download counts) we can see that 62% of +them use Git, while 22% of them use Mercurial, and 13% use something +else. This has Git being just under 3 times as popular as Mercurial +for the top 100 projects on PyPI. + +These numbers back up the anecdotal evidence for Git as the far more +popular DVCS for open source projects. Choosing the more popular VCS +has a number of positive benefits. + +For new contributors it increases the likelihood that they will have already +learned the basics of Git as part of working with another project or if they +are just now learning Git, that they'll be able to take that knowledge and +apply it to other projects. Additionally a larger community means more people +writing how to guides, answering questions, and writing articles about Git +which makes it easier for a new user to find answers and information about the +tool they are trying to learn and use. Given its popularity, there may also +be more auxiliary tooling written *around* Git. This increases options for +everything from GUI clients, helper scripts, repository hosting, etc. + +Further, the adoption of Git as the proposed back-end repository +format doesn't prohibit the use of Mercurial by fans of that VCS! +Mercurial users have the [#hg-git]_ plugin which allows them to push +and pull from a Git server using the Mercurial front-end. It's a +well-maintained and highly functional plugin that seems to be +well-liked by Mercurial users. + + +Repository Hosting +------------------ + +Where and how the official repositories for CPython are hosted is in +someways determined by the choice of VCS. With Git there are several +options. In fact, once the repository is hosted in Git, branches can +be mirrored in many locations, within many free, open, and proprietary +code hosting sites. + +It's still important for CPython to adopt a single, official +repository, with a web front-end that allows for many convenient and +common interactions entirely through the web, without always requiring +local VCS manipulations. These interactions include as a minimum, +code review with inline comments, branch diffing, CI integration, and +auto-merging. + +This PEP proposes to adopt a [#GitLab]_ instance, run within the +python.org domain, accessible to and with ultimate control from the +PSF and the Python infrastructure team, but donated, hosted, and +primarily maintained by GitLab, Inc. + +Why GitLab? Because it is a fully functional Git hosting system, that +sports modern web interactions, software workflows, and CI +integration. GitLab's Community Edition (CE) is open source software, +and thus is closely aligned with the principles of the CPython +community. + + +Code Review +----------- + +Currently CPython uses a custom fork of Rietveld modified to not run +on Google App Engine and which is currently only really maintained by +one person. It is missing common features present in many modern code +review tools. + +This PEP proposes to utilize GitLab's built-in merge requests and +online code review features to facilitate reviews of all proposed +changes. + + +GitLab merge requests +--------------------- + +The normal workflow for a GitLab hosted project is to submit a *merge request* +asking that a feature or bug fix branch be merged into a target branch, +usually one or more of the stable maintenance branches or the next-version +master branch for new features. GitLab's merge requests are similar in form +and function to GitHub's pull requests, so anybody who is already familiar +with the latter should be able to immediately utilize the former. + +Once submitted, a conversation about the change can be had between the +submitter and reviewer. This includes both general comments, and inline +comments attached to a particular line of the diff between the source and +target branches. Projects can also be configured to automatically run +continuous integration on the submitted branch, the results of which are +readily visible from the merge request page. Thus both the reviewer and +submitter can immediately see the results of the tests, making it much easier +to only land branches with passing tests. Each new push to the source branch +(e.g. to respond to a commenter's feedback or to fix a failing test) results +in a new run of the CI, so that the state of the request always reflects the +latest commit. + +Merge requests have a fairly major advantage over the older "submit a patch to +a bug tracker" model. They allow developers to work completely within the VCS +using standard VCS tooling, without requiring the creation of a patch file or +figuring out the right location to upload the patch to. This lowers the +barrier for sending a change to be reviewed. + +Merge requests are far easier to review. For example, they provide nice +syntax highlighted diffs which can operate in either unified or side by side +views. They allow commenting inline and on the merge request as a whole and +they present that in a nice unified way which will also hide comments which no +longer apply. Comments can be hidden and revealed. + +Actually merging a merge request is quite simple, if the source branch applies +cleanly to the target branch. A core reviewer simply needs to press the +"Merge" button for GitLab to automatically perform the merge. The source +branch can be optionally rebased, and once the merge is completed, the source +branch can be automatically deleted. + +GitLab also has a good workflow for submitting pull requests to a project +completely through their web interface. This would enable the Python +documentation to have "Edit on GitLab" buttons on every page and people who +discover things like typos, inaccuracies, or just want to make improvements to +the docs they are currently reading. They can simply hit that button and get +an in browser editor that will let them make changes and submit a merge +request all from the comfort of their browser. + + +Criticism +========= + +X is not written in Python +-------------------------- + +One feature that the current tooling (Mercurial, Rietveld) has is that the +primary language for all of the pieces are written in Python. This PEP +focuses more on the *best* tools for the job and not necessarily on the *best* +tools that happen to be written in Python. Volunteer time is the most +precious resource for any open source project and we can best respect and +utilize that time by focusing on the benefits and downsides of the tools +themselves rather than what language their authors happened to write them in. + +One concern is the ability to modify tools to work for us, however one of the +Goals here is to *not* modify software to work for us and instead adapt +ourselves to a more standardized workflow. This standardization pays off in +the ability to re-use tools out of the box freeing up developer time to +actually work on Python itself as well as enabling knowledge sharing between +projects. + +However if we do need to modify the tooling, Git itself is largely written in +C the same as CPython itself. It can also have commands written for it using +any language, including Python. GitLab itself is largely written in Ruby and +since it is Open Source software, we would have the ability to submit merge +requests to the upstream Community Edition, albeit in language potentially +unfamiliar to most Python programmers. + + +Mercurial is better than Git +---------------------------- + +Whether Mercurial or Git is better on a technical level is a highly subjective +opinion. This PEP does not state whether the mechanics of Git or Mercurial +are better, and instead focuses on the network effect that is available for +either option. While this PEP proposes switching to Git, Mercurial users are +not left completely out of the loop. By using the hg-git extension for +Mercurial, working with server-side Git repositories is fairly easy and +straightforward. + + +CPython Workflow is too Complicated +----------------------------------- + +One sentiment that came out of previous discussions was that the multi-branch +model of CPython was too complicated for GitLab style merge requests. This +PEP disagrees with that sentiment. + +Currently any particular change requires manually creating a patch for 2.7 and +3.x which won't change at all in this regards. + +If someone submits a fix for the current stable branch (e.g. 3.5) the merge +request workflow can be used to create a request to merge the current stable +branch into the master branch, assuming there is no merge conflicts. As +always, merge conflicts must be manually and locally resolved. Because +developers also have the *option* of performing the merge locally, this +provides an improvement over the current situation where the merge *must* +always happen locally. + +For fixes in the current development branch that must also be applied to +stable release branches, it is possible in many situations to locally cherry +pick and apply the change to other branches, with merge requests submitted for +each stable branch. It is also possible just cherry pick and complete the +merge locally. These are all accomplished with standard Git commands and +techniques, with the advantage that all such changes can go through the review +and CI test workflows, even for merges to stable branches. Minor changes may +be easily accomplished in the GitLab web editor. + +No system can hide all the complexities involved in maintaining several long +lived branches. The only thing that the tooling can do is make it as easy as +possible to submit and commit changes. + + +References +========== + +.. [#openhub-stats] `Open Hub Statistics <https://www.openhub.net/repositories/compare>` +.. [#hg-git] `Hg-Git mercurial plugin <https://hg-git.github.io/>` +.. [#GitLab] `https://about.gitlab.com/` + + +Copyright +========= + +This document has been placed in the public domain. + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: -- Repository URL: https://hg.python.org/peps

1 0

peps: Add some open issues.
by barry.warsaw 30 Sep '15

30 Sep '15

https://hg.python.org/peps/rev/2fb211ea5cb1 changeset: 6104:2fb211ea5cb1 user: Barry Warsaw <barry(a)python.org> date: Wed Sep 30 16:32:56 2015 -0400 summary: Add some open issues. files: pep-0507.txt | 28 ++++++++++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/pep-0507.txt b/pep-0507.txt --- a/pep-0507.txt +++ b/pep-0507.txt @@ -278,6 +278,34 @@ possible to submit and commit changes. +Open issues +=========== + +* What level of hosted support will GitLab offer? The PEP author has been in + contact with the GitLab CEO, with positive interest on their part. The + details of the hosting offer would have to be discussed. + +* What happens to Roundup and do we switch to the GitLab issue tracker? + Currently, this PEP is *not* suggesting we move from Roundup to GitLab + issues. We have way too much invested in Roundup right now and migrating + the data would be a huge effort. GitLab does support webhooks, so we will + probably want to use webhooks to integrate merges and other events with + updates to Roundup (e.g. to include pointers to commits, close issues, + etc. similar to what is currently done). + +* What happens to wiki.python.org? Nothing! While GitLab does support wikis + in repositories, there's no reason for us to migration our Moin wikis. + +* What happens to the existing GitHub mirrors? We'd probably want to + regenerate them once the official upstream branches are natively hosted in + Git. This may change commit ids, but after that, it should be easy to + mirror the official Git branches and repositories far and wide. + +* Where would the GitLab instance live? Physically, in whatever hosting + provider GitLab chooses. We would point gitlab.python.org (or + git.python.org?) to this host. + + References ========== -- Repository URL: https://hg.python.org/peps

1 0

cpython: Issue #25171: Fix compilation issue on OpenBSD in random.c
by victor.stinner 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/e4ac5a899657 changeset: 98441:e4ac5a899657 user: Victor Stinner <victor.stinner(a)gmail.com> date: Wed Sep 30 22:06:51 2015 +0200 summary: Issue #25171: Fix compilation issue on OpenBSD in random.c Patch written by Remi Pointel. files: Python/random.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Python/random.c b/Python/random.c --- a/Python/random.c +++ b/Python/random.c @@ -364,7 +364,7 @@ #ifdef MS_WINDOWS return win32_urandom((unsigned char *)buffer, size, 1); -#elif PY_GETENTROPY +#elif defined(PY_GETENTROPY) return py_getentropy(buffer, size, 0); #else return dev_urandom_python((char*)buffer, size); @@ -411,7 +411,7 @@ else { #ifdef MS_WINDOWS (void)win32_urandom(secret, secret_size, 0); -#elif PY_GETENTROPY +#elif defined(PY_GETENTROPY) (void)py_getentropy(secret, secret_size, 1); #else dev_urandom_noraise(secret, secret_size); @@ -427,7 +427,7 @@ CryptReleaseContext(hCryptProv, 0); hCryptProv = 0; } -#elif PY_GETENTROPY +#elif defined(PY_GETENTROPY) /* nothing to clean */ #else dev_urandom_close(); -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.4 -> 3.5): (Merge 3.4) Issue #25182: Fix compilation on Windows
by victor.stinner 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/0eb26a4d5ffa changeset: 98439:0eb26a4d5ffa branch: 3.5 parent: 98436:e8b6c6c433a4 parent: 98438:2652c1798f7d user: Victor Stinner <victor.stinner(a)gmail.com> date: Wed Sep 30 15:03:31 2015 +0200 summary: (Merge 3.4) Issue #25182: Fix compilation on Windows files: Objects/fileobject.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/Objects/fileobject.c b/Objects/fileobject.c --- a/Objects/fileobject.c +++ b/Objects/fileobject.c @@ -376,7 +376,7 @@ PyObject *bytes = NULL; char *str; Py_ssize_t n; - int _errno; + int err; if (self->fd < 0) { /* fd might be invalid on Windows @@ -403,10 +403,13 @@ } n = _Py_write(self->fd, str, n); - _errno = errno; + /* save errno, it can be modified indirectly by Py_XDECREF() */ + err = errno; + Py_XDECREF(bytes); + if (n == -1) { - if (_errno == EAGAIN) { + if (err == EAGAIN) { PyErr_Clear(); Py_RETURN_NONE; } -- Repository URL: https://hg.python.org/cpython

1 0

cpython (3.4): Issue #25182: Fix compilation on Windows
by victor.stinner 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/2652c1798f7d changeset: 98438:2652c1798f7d branch: 3.4 parent: 98435:6347b154dd67 user: Victor Stinner <victor.stinner(a)gmail.com> date: Wed Sep 30 15:01:34 2015 +0200 summary: Issue #25182: Fix compilation on Windows Restore also errno value before calling PyErr_SetFromErrno(). files: Objects/fileobject.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/Objects/fileobject.c b/Objects/fileobject.c --- a/Objects/fileobject.c +++ b/Objects/fileobject.c @@ -376,7 +376,7 @@ PyObject *bytes = NULL; char *str; Py_ssize_t n; - int _errno; + int err; if (self->fd < 0) { /* fd might be invalid on Windows @@ -411,13 +411,16 @@ #else n = write(self->fd, str, n); #endif - _errno = errno; + /* save errno, it can be modified indirectly by Py_XDECREF() */ + err = errno; Py_END_ALLOW_THREADS + Py_XDECREF(bytes); if (n < 0) { - if (_errno == EAGAIN) + if (err == EAGAIN) Py_RETURN_NONE; + errno = err; PyErr_SetFromErrno(PyExc_IOError); return NULL; } -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.5 -> default): (Merge 3.5) Issue #25182: Fix compilation on Windows
by victor.stinner 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/d1090d733d39 changeset: 98440:d1090d733d39 parent: 98437:0b0945c8de36 parent: 98439:0eb26a4d5ffa user: Victor Stinner <victor.stinner(a)gmail.com> date: Wed Sep 30 15:03:50 2015 +0200 summary: (Merge 3.5) Issue #25182: Fix compilation on Windows files: Objects/fileobject.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/Objects/fileobject.c b/Objects/fileobject.c --- a/Objects/fileobject.c +++ b/Objects/fileobject.c @@ -376,7 +376,7 @@ PyObject *bytes = NULL; char *str; Py_ssize_t n; - int _errno; + int err; if (self->fd < 0) { /* fd might be invalid on Windows @@ -403,10 +403,13 @@ } n = _Py_write(self->fd, str, n); - _errno = errno; + /* save errno, it can be modified indirectly by Py_XDECREF() */ + err = errno; + Py_XDECREF(bytes); + if (n == -1) { - if (_errno == EAGAIN) { + if (err == EAGAIN) { PyErr_Clear(); Py_RETURN_NONE; } -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.5 -> default): Issue #25182: The stdprinter (used as sys.stderr before the io module is
by serhiy.storchaka 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/0b0945c8de36 changeset: 98437:0b0945c8de36 parent: 98434:ec02ccffd1dc parent: 98436:e8b6c6c433a4 user: Serhiy Storchaka <storchaka(a)gmail.com> date: Wed Sep 30 15:51:01 2015 +0300 summary: Issue #25182: The stdprinter (used as sys.stderr before the io module is imported at startup) now uses the backslashreplace error handler. files: Misc/NEWS | 3 +++ Objects/fileobject.c | 25 +++++++++++++++++++++---- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -180,6 +180,9 @@ Core and Builtins ----------------- +- Issue #25182: The stdprinter (used as sys.stderr before the io module is + imported at startup) now uses the backslashreplace error handler. + - Issue #25131: Make the line number and column offset of set/dict literals and comprehensions correspond to the opening brace. diff --git a/Objects/fileobject.c b/Objects/fileobject.c --- a/Objects/fileobject.c +++ b/Objects/fileobject.c @@ -372,8 +372,11 @@ static PyObject * stdprinter_write(PyStdPrinter_Object *self, PyObject *args) { + PyObject *unicode; + PyObject *bytes = NULL; char *str; Py_ssize_t n; + int _errno; if (self->fd < 0) { /* fd might be invalid on Windows @@ -383,13 +386,27 @@ Py_RETURN_NONE; } - /* encode Unicode to UTF-8 */ - if (!PyArg_ParseTuple(args, "s", &str)) + if (!PyArg_ParseTuple(args, "U", &unicode)) return NULL; - n = _Py_write(self->fd, str, strlen(str)); + /* encode Unicode to UTF-8 */ + str = PyUnicode_AsUTF8AndSize(unicode, &n); + if (str == NULL) { + PyErr_Clear(); + bytes = _PyUnicode_AsUTF8String(unicode, "backslashreplace"); + if (bytes == NULL) + return NULL; + if (PyBytes_AsStringAndSize(bytes, &str, &n) < 0) { + Py_DECREF(bytes); + return NULL; + } + } + + n = _Py_write(self->fd, str, n); + _errno = errno; + Py_XDECREF(bytes); if (n == -1) { - if (errno == EAGAIN) { + if (_errno == EAGAIN) { PyErr_Clear(); Py_RETURN_NONE; } -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.4 -> 3.5): Issue #25182: The stdprinter (used as sys.stderr before the io module is
by serhiy.storchaka 30 Sep '15

30 Sep '15

https://hg.python.org/cpython/rev/e8b6c6c433a4 changeset: 98436:e8b6c6c433a4 branch: 3.5 parent: 98413:73b6b88ac28a parent: 98435:6347b154dd67 user: Serhiy Storchaka <storchaka(a)gmail.com> date: Wed Sep 30 15:50:32 2015 +0300 summary: Issue #25182: The stdprinter (used as sys.stderr before the io module is imported at startup) now uses the backslashreplace error handler. files: Misc/NEWS | 3 +++ Objects/fileobject.c | 25 +++++++++++++++++++++---- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -11,6 +11,9 @@ Core and Builtins ----------------- +- Issue #25182: The stdprinter (used as sys.stderr before the io module is + imported at startup) now uses the backslashreplace error handler. + - Issue #25131: Make the line number and column offset of set/dict literals and comprehensions correspond to the opening brace. diff --git a/Objects/fileobject.c b/Objects/fileobject.c --- a/Objects/fileobject.c +++ b/Objects/fileobject.c @@ -372,8 +372,11 @@ static PyObject * stdprinter_write(PyStdPrinter_Object *self, PyObject *args) { + PyObject *unicode; + PyObject *bytes = NULL; char *str; Py_ssize_t n; + int _errno; if (self->fd < 0) { /* fd might be invalid on Windows @@ -383,13 +386,27 @@ Py_RETURN_NONE; } - /* encode Unicode to UTF-8 */ - if (!PyArg_ParseTuple(args, "s", &str)) + if (!PyArg_ParseTuple(args, "U", &unicode)) return NULL; - n = _Py_write(self->fd, str, strlen(str)); + /* encode Unicode to UTF-8 */ + str = PyUnicode_AsUTF8AndSize(unicode, &n); + if (str == NULL) { + PyErr_Clear(); + bytes = _PyUnicode_AsUTF8String(unicode, "backslashreplace"); + if (bytes == NULL) + return NULL; + if (PyBytes_AsStringAndSize(bytes, &str, &n) < 0) { + Py_DECREF(bytes); + return NULL; + } + } + + n = _Py_write(self->fd, str, n); + _errno = errno; + Py_XDECREF(bytes); if (n == -1) { - if (errno == EAGAIN) { + if (_errno == EAGAIN) { PyErr_Clear(); Py_RETURN_NONE; } -- Repository URL: https://hg.python.org/cpython

1 0