Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed setup.py so that it doesn't throw encoding error. #112

Merged
merged 2 commits into from Jan 22, 2016

Conversation

shirish93
Copy link
Contributor

Without this change, the installation via python setup.py install is broken in certain Windows system with encoding set to other than 'utf-8'.

Without specifying the encoding of the README file, the open defaults to system config encoding, which doesn't have to be 'utf-8'. Opening the file in UTF-8 mode fixes that.

Traceback of the error thrown without the fix:

Traceback (most recent call last): File "setup.py", line 156, in <module> README_rst = fd.read() File "C:\Users\n0272436\Downloads\WinPython-32bit-3.4.3.4\python-3.4.3\lib\encodings\cp1252.py", line 23, return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 17233: character maps to <undefined>

Without specifying the encoding of the README file, the open defaults to system config encoding, which doesn't have to be 'utf-8'. Opening the file in UTF-8 mode fixes that.

Traceback of the error thrown without the fix:

`Traceback (most recent call last):
  File "setup.py", line 156, in <module>
    README_rst = fd.read()
  File "C:\Users\n0272436\Downloads\WinPython-32bit-3.4.3.4\python-3.4.3\lib\encodings\cp1252.py", line 23,
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 17233: character maps to <undefined>
`
@codecov-io
Copy link

Current coverage is 100.00%

Merging #112 into master will not affect coverage as of f8393b8

@@            master    #112   diff @@
======================================
  Files            5       5       
  Stmts          244     244       
  Branches        49      49       
  Methods          0       0       
======================================
  Hit            244     244       
  Partial          0       0       
  Missed           0       0       

Review entire Coverage Diff as of f8393b8

Powered by Codecov. Updated on successful CI builds.

The previous change was invalid for python 2.X, and was breaking the travis CI builds. This fixes the issue, and makes the code compatible to both 2.X and 3.X.

The error in question is referred to, and discussed here:

http://stackoverflow.com/questions/25049962/is-encoding-is-an-invalid-keyword-error-inevitable-in-python-2-x
@shirish93
Copy link
Contributor Author

So it appears that the build fails due to this pip error:
Support for Python 3.0-3.2 has been dropped. Future versions will fail here.
I see this has been discussed here: john-kurkowski/tldextract#50

Perhaps opening the file with UTF-8 encoding fails in 3.0-3.2? Not sure why my code would cause this exact behavior.

Either way, the failure of test 566.3 seems to pit all other versions of Python against 3.0-3.2. Would it be worth considering to remove those from build tests entirely?

@lrq3000
Copy link
Member

lrq3000 commented Jan 21, 2016

Thank you for the patch, i'm the dev running on windows so ill try your
patch when i get internet access with my computer.

About dropping Python 3.2, yes we will do but only when a new PyPy3 will be
released. Until then, i'd like to support both.
Le 21 Jan. 2016 18:14, "Shirish Pokharel" notifications@github.com a
écrit :

So it appears that the build fails due to this pip error:

Support for Python 3.0-3.2 has been dropped. Future versions will fail
here.

I see this has been discussed here: john-kurkowski/tldextract#50
john-kurkowski/tldextract#50

Perhaps opening the file with UTF-8 encoding fails in 3.0-3.2? Not sure
why my code would cause this exact behavior.

Either way, the failure of test 566.3 seems to pit all other versions of
Python against 3.0-3.2. Would it be worth considering to remove those from
build tests entirely?


Reply to this email directly or view it on GitHub
#112 (comment).

@lrq3000
Copy link
Member

lrq3000 commented Jan 21, 2016

Ps: moderate my previous reply : we will MAYBE drop Py3.2, when a new PyPy3
gets released. We will considerate that from the active userbase (but I
know Py3.2 is widely seend as an incomplete version so yeah, if noone uses
it, we'll drop).
Le 21 Jan. 2016 21:09, "Stephen LARROQUE" lrq3000@gmail.com a écrit :

Thank you for the patch, i'm the dev running on windows so ill try your
patch when i get internet access with my computer.

About dropping Python 3.2, yes we will do but only when a new PyPy3 will
be released. Until then, i'd like to support both.
Le 21 Jan. 2016 18:14, "Shirish Pokharel" notifications@github.com a
écrit :

So it appears that the build fails due to this pip error:

Support for Python 3.0-3.2 has been dropped. Future versions will fail
here.

I see this has been discussed here: john-kurkowski/tldextract#50
john-kurkowski/tldextract#50

Perhaps opening the file with UTF-8 encoding fails in 3.0-3.2? Not sure
why my code would cause this exact behavior.

Either way, the failure of test 566.3 seems to pit all other versions of
Python against 3.0-3.2. Would it be worth considering to remove those from
build tests entirely?


Reply to this email directly or view it on GitHub
#112 (comment).

@casperdcl casperdcl mentioned this pull request Jan 22, 2016
@casperdcl
Copy link
Sponsor Member

Travis is failing to build the environment (see #117 ) so I'm going to merge this in. master is currently failing due to this issue anyway.

@casperdcl casperdcl merged commit 3f8a253 into tqdm:master Jan 22, 2016
@lrq3000
Copy link
Member

lrq3000 commented Jan 22, 2016

Ok thank's for confirming the issue and the culprit. I agree, let's drop Py32. It's way too buggy anyway, even in normal circumstances.

@lrq3000
Copy link
Member

lrq3000 commented Jan 22, 2016

Thank you @shirish93 for the patch!

@lrq3000
Copy link
Member

lrq3000 commented Jan 22, 2016

What's interesting is that PyPy3, which is based on Py32, doesn't suffer from this issue. So it's all ok for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants