-
Notifications
You must be signed in to change notification settings - Fork 146
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
Under python3.3 --help throws TypeError #40
Comments
Thanks! Also: interesting. Seems like I need to write proper integration tests that start an individual python process. |
Did you just sign up for GitHub to file this issue ? Thank you so much and enjoy your stay! |
I did indeed. I am late to Python, and so missed the whole 2->3 str vs unicode vs bytes psychodrama - all my code is python 3, and you just assume that stdin/stdout/argv are all in unicode, as are text & config files. It works if I comment out
but I have no idea what other impact that has. (No other direct uses of sys.stdout or print that I could immediately see, and logging.log shouldn't need a bespoke encoder, but I don't use 2.7) Regardless, the tool still works fine (and is jolly useful). For entirely sensible reasons, the test harness is about making sure the version numbers are bumped correctly! |
I stumbled upon that line aswell, @peritus, could you explain why it's needed? |
Hi; To chime in: If that line was introduced by 027137a #13, then you have a problem. The bug reported in #13 is a problem the OP there has, having his terminal malconfigured to use a Unicode-incompatible encoding and/or Python falls back to ASCII (he should check, e.g., "sys.defaultencoding()" after opening a REPL), and was not a problem of bumpversion in the first place. Ergo, that commit adding the getwriter line @kernowcastellan found should be reverted... (BTW, I, too cannot see the help output in the current stable version 0.4.0 when using Py3k) EDIT: BTW, kudos to you @peritus, for this nice library; a real life saver :) |
Well, actually, the issue is deeper, I just realized the OP of #11 seems to use Py2.x, which in turn uses ASCII as its default encoding, not the actual terminal encoding (BTW, yet another GREAT reason to stop using these outdated 2.x Python series: Py3 does actually realize the environment it is running in, Py2 defaults to ASCII always). So what you were seeing in #13 and #11 is actually an issue that you are tring to write a string containing non-ASCII chars to an ASCII-only file handle (stdout). In essence, the problem is here that if you are using Py2, you should make sure your output streams are all UTF-8-enabled, but if you are using Py3 you are golden already and any change is bad (thus, the problem we see here). So, in summary, you should hedge the above change 027137a to only be encoding stdout to UTF-8 instead of ASCII when using Py2. |
Thanks for the kind words and the write-up @fnl! Finally had some time to play with it, here's a branch that adds s regression test: 7846265 However, I wasn't able to make it work in py3, might correlate to this: http://bugs.python.org/issue9779 Need to investigate some more. |
Travis likes it though. Seems like I rather need to fix the terminal encoding in my vagrant box. If there are no objections, I'll merge this to master. |
No objections, this is exactly what I argument is the "correctest" fix [other than telling everybody (especially on HN...) to stop the whining and start using Py3k] |
released in v0.4.1 |
Running in a python 3.3 virtualenv environ, with 0.4.0 installed from pip/pypi. It throws a TypeError if invoked with --help
Same is true if I clone the repo and invoke directly
The text was updated successfully, but these errors were encountered: