Import error

Dec 2, 2013 at 5:03 PM
This may not be PTVS but I don't get the error in Wing on my dev box so I'm wondering if someone can point me in the right direction to solve it. I'm trying to build a case for using VS2013 and PTVS so I've installed it on a VM on my dev box. (can't install on my dev box directly yet as our IT department is not supporting IE10 yet).
I'm getting this error when I try to run the same code that works in Wing.

cannot import name ifilter on the following line of code:
import openpyxl as xl
I have installed this package using easy setup same as on my dev box. I've installed the site packages that are installed on my dev box also so I don't get why I'm getting this import error.
Any pointers on what the problem could be?
Coordinator
Dec 2, 2013 at 5:15 PM
I assume it's breaking into the debugger and showing you the exception. If you continue, does it work?

It's likely that we're detecting the exception, but can't tell that it's being handled elsewhere. You can disable breaking on this exception as shown here, but if you can provide the call stack you're seeing when it breaks it will help us figure out how to improve our detection.

(Basically, it comes down to it being very difficult to tell whether an exception is going to be handled or not without losing the context of where it is thrown. By the time Python finds an exception handler, it's thrown away all the old stack frames, so we have to try and find it ourselves before letting Python execute anything. Sometimes we don't get it right...)
Dec 2, 2013 at 5:35 PM
Edited Dec 2, 2013 at 5:41 PM
Okay, so here's the call stack:
xmltools module line 35 Python
__init__ module line 33     Python
cell module line 37         Python
__init__ module line 29         Python
testPreInit module line 4   Python
If I continue it does work but that exception will through others in the department here just like it did me.
To disable breaking on that exception, my option is to disable breaking on Import errors all together by unchecking user unhandled import errors right?

Opps, scratch that, it will continue on but it actually fails to load the openpyxl module as seen later in the code when I try to load a workbook on this line of code:
wbIn = xl.load_workbook(inWorkbook)

It opens up an open file dialog with cell.py filled in for the file it's looking for.
Stack trace
check_numeric in cell line 223  Python
set_value_explicit in cell line 245 Python
bind_value in cell line 330 Python
_set_value in cell line 341 Python
fast_parse in worksheet line 140    Python
read_worksheet in worksheet line 241    Python
_load_workbook in excel line 197    Python
load_workbook in excel line 143 Python
main in preInit line 61 Python
main in testPreInit line 25 Python
testPreInit module line 30  Python
Coordinator
Dec 2, 2013 at 5:48 PM
It looks like a similar situation, and it's probably because we're not able to locate the source files. We'll have to take a look at openpyxl to see exactly why we're having trouble.

Yes, you'll have to stop breaking on all user-unhandled import errors.
Dec 2, 2013 at 5:57 PM
Okay well let me know when you can get past it so I can continue testing.
I wind up getting a fatal error that it won't get past:
invalid literal for int() with base 10: '0.27700000000000002'
On that line of code where I'm loading the workbook.
Dec 13, 2013 at 11:09 PM
Hi Zooba,
any progress on this? Is this only happening in that openpyxl module?
Coordinator
Dec 13, 2013 at 11:40 PM
I'm sorry, I haven't had a chance to look into this package yet. I'm on vacation right now, so if I get some downtime I'll try it out (more likely than it sounds - there are far fewer distractions while I'm out of the country).
Coordinator
Dec 15, 2013 at 3:17 AM
I just tried a few things, but it all seems to be working for me. I am using a later build than 2.0 (should be the same as our last dev build for everything that matters) but haven't had to change any settings.

I wonder how dependent this is on your particular spreadsheet? The invalid literal error is coming from data in the spreadsheet you're loading, though it should be handled immediately. I can't see why we're not detecting the handler - it is the simplest possible case and openpyxl is pure Python, so there's no C extensions to worry about. Do you see the same issues if you open a blank sheet?

One possibility for us not finding the handler may be due to how it was installed. I used a simple pip install openpyxl for 2.7 and 3.3 - did you do something different or use a version earlier than 1.7.0? When VS breaks at the error, do you see the source code for openpyxl?

As for "does this happen in any other projects", yes it does, but we haven't been able to find a common cause besides installation issues. Installing with pip should work fine in every case - custom installers may do weird things that hurt IntelliSense, but debugging uses standard Python features (like __file__) and most libraries don't do anything to break this. openpyxl certainly doesn't seem to do anything strange, at least in the latest version.
Dec 18, 2013 at 4:12 PM
Zooba,
I installed openpyxl using easy install. is that part of the problem here? If so, should I just use pip to install over it or remove my local install of openpyxl?

I haven't tried to open a blank worksheet yet as I've been busy on other project but I can see if a re-install of the package might fix it.

Thank you

Steve
Coordinator
Jan 6 at 9:22 PM
Have you had any luck with this? easy_install is usually as good an option as pip, as long as both are up to date.

If it is specific to your data then you may have to file an issue with the openpyxl developer(s). A fatal error is exactly what we should be breaking on in the debugger, so we wouldn't have anything to fix in this case.
Jan 6 at 9:25 PM
Hi Zooba,
I've been out for a couple of weeks.
I'll get to this ASAP. Hopefull some time this week.

Steve
Mar 12 at 7:33 PM
Hey Steve,
I believe I have a partial answer to this import error issue. Here's the deal.
The version of openpyxl that most of our code is using is 1.6.2. The newest release is at 1.8.4.
If I install 1.6.2 locally using the following syntax:
easy_install \server\path\openpyxl-1.6.2-py2.7.egg
it gets installed on my machine but PTVS cannot find it and I get the import error even after updating the Completion DB and restarting VS 2013.
However, if I open up a command promp in the folder where python lives (version 2.7 btw) and run the following:
pip openpyxl
it goes out and gets the lastest version (I guess) and installs it and then I update the Completion DB and restart VS and I don't get an import error and intellisense works properly.

What say you about this? Does this sound right to you?

Steve
Coordinator
Mar 12 at 8:00 PM
That sounds like easy_install is just copying the .egg file over and not extracting it. Our analyzer won't look inside .eggs (a long-standing issue I'd love to fix, but keep struggling to find the time for) and so the best workaround is to use pip to install (pip install openpyxl==1.6.2 should give you the correct version) or use easy_install --always-unzip <path>.

If you use the "Install Python Package" dialog inside VS then we will ensure easy_install gets the right options.
Mar 12 at 8:04 PM
Yes, poking around that is exactly what easy_install was doing. I noticed the egg would be stuffed into the "Python27\ArcGIS10.1\Lib" folder rather than placed in an openpyxl folder like pip was doing. I'll try one of your methods of using easy_install and see how that goes.

Thank you,

Steve