Py3.3 support for xlwt #32
Conversation
* Currently uses the future module for py2k compatibility. Only a couple of functions (just ``range`` and ``str``, I think) are used, so this dependency could be removed easily enough.
* Why is the diff so noisy??
* Also add future==0.4.0 to requirements.txt. This is not currently read; it is for the user's info only ...
* Mention Py3 compatibility and dependency on ``future``
* The diff was way too big. Why??
* Ah ... this file has CRLF line terminators ;)
|
I am very interested in this pull request |
Fix "ImportError: No module named 'future'"
|
I am very interested in this pull request as well. I do need to output Excel files at work, and I would definitely like to move my full toolchain to Python3. This (and xlutils, as I also frequently have to copy incoming files before enriching them), is the last important holdout. |
|
For those watching this, I have uploaded this as a fork to PyPI as Please post any bugs or problems as comments here for now. |
|
Hi, i just found this, great stuff...but must wonder a bit where the maintainers have gone.. My only objection is using the u"" explicit unicode syntax that only 3.3 started allowing again before 3.3 is out on platforms like Ubuntu LTS and others(they use 3.2). However, that is not likely a valid one, as the next Ubuntu LTS that is out in april has as a release goal to be python 3 only, and then it would be very strange to stay with 3.2. So Is there some important reason for using explicit u"", or can I just change that to implicit and go on for now? Again, good work! |
|
@zig007 I would imagine they kept the |
|
Yeah, I suppose so. I was rather asking if I would cause myself problems if I would change it to 3.2-syntax temporarily, if he knew something of the top of his head, to make it work with my project, as not all its other dependencies were compatible with 3.2 yet. However, I have decided to upgrade everything to 3.3 now instead, so it doesn't matter. Thanks everyone!! |
|
I would like to test xlwt-future in 3.3.5. |
|
@SalvaJ : xlwt-future is a fork, please contact its maintainers. |
|
@cjw296 Where is that fork? |
|
@edschofield , @takluyver - where are we on this? At the very least, we need to drop the requirement for @edschofield 's "future" package, it should be replaced with a minimal compat.py is in xlrd here: https://github.com/python-excel/xlrd/blob/master/xlrd/timemachine.py I'd also like to see Manfred's unit tests merged across... If anyone has time for both of the above, I'll do my very best to get the reviewing and merging done as soon as I can and then get a release out... |
|
I'll work on integrating Manfred's unit tests. |
|
PR #42 adds the tests. |
|
The tests are now merged, so it's ready for someone to merge @edschofield 's Python 3 changes in. |
|
is this a 'released' version of 3.3 compat for xlwt? https://pypi.python.org/pypi/xlwt-future |
|
@jreback - no, that's a fork. |
|
@jreback: yes, it's a temporary fork until |
|
@cjw296: thanks for your earlier message. I will see what I can do with removing the The downside to replacing the |
|
@edschofield @cjw296 thanks for the info! |
|
I've done Python 3 support without external dependencies in #46. |
|
Okay, closing this one. |
Hi John,
I have patched xlwt to support Python 3.3 as well as Python 2.6/2.7 with a single codebase (i.e. no embedded 2to3 conversion).
This currently introduces one dependency: my future package for Py2/3 compatibility.
I would be interested in your feedback. The patch set is big but most of the changes should be uncontroversial (e.g. converting print statements to print functions). The unicode / bytes disambiguation was the most difficult part.
It seems to work now under both Python 3.3 and Python 2.7 for all the example scripts, but this could do with more testing.
Kind regards,
Ed Schofield (ed@pythoncharmers.com)