magmax / python-readchar

Python library to read characters and key strokes
MIT License
153 stars 46 forks source link

Could not install on Windows 7 x64 - setup.py fails because of UTF-8 encoding of README.rst #5

Closed mbdevpl closed 4 years ago

mbdevpl commented 9 years ago

Hello, I've had a curious issue with the readchar module. My post also includes a workaround.

I've been trying to use readchar lately because I jump between Linux and Windows a lot. Last month I discovered how great python is. Since then, I'm writing various helper scripts for both platforms, and I wrote a simple question/answer function that takes y/n in one keystroke to help me with some otherwise tedious tasks.

On linux (python 3) readchar installed and runs without any problems. However, on Windows 7 64bit (tested both Python 3.4 and 3.3 because I read somewhere that readchar has issues on windows with py3.4) I cannot even install it using pip. Also, when I cloned and tried to build using simple: python-readchar (master) $ python setup.py build I get:

Traceback (most recent call last):
  File "setup.py", line 39, in <module>
    long_description=read_description(),
  File "setup.py", line 11, in read_description
    return fd.read()
  File "c:\Programs\Python34\lib\encodings\cp1250.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2590: character maps to <undefined>

so... I investigated, and noticed that README.rst is encoded in UTF-8. I converted it to ANSI with Notepad++. The "guilty" characters were just the two characters in your name (Á and í). After that, both setup.py build and setup.py install worked. However, still, when I run readchar.readchar(), I get this strange error

  File "d:\Projects\python\mbdev.py", line 29, in ask
    answer = readchar.readchar().decode("utf-8").lower()
  File "C:\Programs\Python34\lib\site-packages\readchar-1.1.1-py3.4.egg\readchar\readchar_windows.py", line 14, in readchar
    while ch in '\x00\xe0':
TypeError: 'in <string>' requires string as left operand, not bytes

So... I changed the line 14 in readchar_windows.py from while ch in '\x00\xe0': to while ch.decode() in '\x00\xe0':

and changed my code from answer = readchar.readchar().decode("utf-8").lower() to answer = readchar.readchar().lower() And now it works on Windows. I feel that this solution might not be the optimal one, maybe on some other Windows systems the decode() is not needed as the char is already of type str. Maybe something along the lines of the type check present in readchar_linux.py is needed?

Also, I noticed that the readchar.readchar() in 1.1.0 (from pypi) returns bytes on linux, while 1.1.1 (current master from github) returns str. So, after I changed my code it stopped working on linux. After that I cloned and built rearchar from github also on my linux machine.

And now it really works on both platforms! :)

I'm willing to do some more testing on windows in the future. @magmax Please let me know if I can help with improving and/or testing readchar_windows.py as it looks like the windows code lags behind the readchar_linux.py.

magmax commented 9 years ago

Wow.

All of that is great!

I really have no way to test it in Windows. I have no Windows machine, and that file was just copied from a stackoverflow thread (as it is said in the header, I hope).

So please, fix anything you find, because I cannot test it.

I will do all what you say as soon as I can.

Thank you very much.

mbdevpl commented 9 years ago

Please also take a look at the merge request #6, because it seems that fixing the issue of README.rst for Windows breaks the code on linux. I've forked your repo and created branch 'devel'. I would be grateful for some feedback if setup.py build is also broken on branch 'devel' in your linux environment. I'm currently unsure how to properly fix it - so that the same code builds on both linux and windows.

ag-eitilt commented 8 years ago

A simpler, though less elegant (which shouldn't take priority over working code) solution would be to stick to ASCII characters in the README: the only change necessary would be "Miguel Ángel García" -> "Miguel A'ngel Garci'a" or something similar.

EDIT: Apparently my instructor is familiar with this, and offered an even better solution: change line 10 from with open('README.rst') as fd: to with open('README.rst', encoding="utf8") as fd:

EDIT 2: I've opened #19 to provide my solution, as well as one for another line that needed fixing.

mbdevpl commented 6 years ago

This issue (as well as #26) can be marked as fixed as soon as #27 is resolved.

mbdevpl commented 4 years ago

As #27 has been resolved, I think this should be closed. If anyone else experiences the same issue with the latest version (as of now: 2.0.1), please reopen.