Mailing-List: contact notifications-help@libcloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@libcloud.apache.org
From: pzrq <git@git.apache.org>
To: notifications@libcloud.apache.org
Reply-To: notifications@libcloud.apache.org
Message-ID: <git-pr-769-libcloud@git.apache.org>
Subject: [GitHub] libcloud pull request: PY3: Reduce AWS S3 test errors if
 lxml is p...
Content-Type: text/plain
Date: Wed, 20 Apr 2016 07:03:27 +0000 (UTC)

GitHub user pzrq opened a pull request:

    https://github.com/apache/libcloud/pull/769

    PY3: Reduce AWS S3 test errors if lxml is present

    ## PY3: Reduce AWS S3 test errors if lxml is present
    
    ### Description
    
    At least lxml should raise ValueError pretty quickly if self.body is a str type, and it was almost certainly assumed to be 'utf-8', this being the web, so we'll pay the price of the decode & encode on the production happy path to get a probable overall speedup from lxml. http://lxml.de/performance.html
    
    Seems cleaner than alternate approaches like trying to inject an additional Response.content attribute to work with the Python 3 bytes type or changing the response.body to a bytes type (causes JSON tests to break). e.g. See https://github.com/apache/libcloud/pull/767
    
    I don't have an aliyun.py, etc driver to test against so don't feel comfortable changing that though happy for others to do so.
    
    In my local Python 3.5+lxml virtualenv, running "python setup.py test", which hopefully Travis will confirm:
    
    ```
    BEFORE
    ----------------------------------------------------------------------
    Ran 5439 tests in 24.415s
    
    FAILED (failures=4, errors=595, skipped=14)
    
    AFTER
    ----------------------------------------------------------------------
    Ran 5439 tests in 27.036s
    
    FAILED (failures=4, errors=176, skipped=14)
    ```
    
    ### Status
    
    Replace this: describe the PR status. Examples:
    
    - work in progress (checking Travis for any regressions)
    - done, ready for review
    
    ### Checklist (tick everything that applies)
    
    - [ ] [Code linting](http://libcloud.readthedocs.org/en/latest/development.html#code-style-guide) (required, can be done after the PR checks)
    - [ ] Documentation
    - [ ] [Tests](http://libcloud.readthedocs.org/en/latest/testing.html)
    - [ ] [ICLA](http://libcloud.readthedocs.org/en/latest/development.html#contributing-bigger-changes) (required for bigger changes)


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/mathspace/libcloud xml-response

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/libcloud/pull/769.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #769
    
----
commit 20256129463692af5833c74d0bfa1b1f761a8764
Author: Peter Schmidt <peter@peterjs.com>
Date:   2016-04-20T06:33:37Z

    PY3: Reduce AWS S3 test errors if lxml is present
    
    At least lxml should raise ValueError pretty quickly if self.body is a str type, and it was almost certainly assumed to be 'utf-8', this being the web, so we'll pay the price of the decode & encode on the production happy path to get a probable overall speedup from lxml. http://lxml.de/performance.html
    
    Seems cleaner than alternate approaches like trying to inject an additional Response.content attribute to work with the Python 3 bytes type or changing the response.body to a bytes type (causes JSON tests to break). e.g. See https://github.com/apache/libcloud/pull/767
    
    I don't have an aliyun.py, etc driver to test against so don't feel comfortable changing that though happy for others to do so.
    
    In my local Python 3.5+lxml virtualenv, running "python setup.py test":
    
    BEFORE
    ----------------------------------------------------------------------
    Ran 5439 tests in 24.415s
    
    FAILED (failures=4, errors=595, skipped=14)
    
    AFTER
    ----------------------------------------------------------------------
    Ran 5439 tests in 27.036s
    
    FAILED (failures=4, errors=176, skipped=14)

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---