Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32072 - [python-scipy] Import problems with python-scipy and python 3.3

Attached to Project: Community Packages
Opened by Vlad Seghete (vlsd) - Thursday, 18 October 2012, 22:41 GMT
Last edited by Jelle van der Waa (jelly) - Saturday, 17 November 2012, 12:43 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Jelle van der Waa (jelly)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


After upgrading to python3.3 scipy is experiencing crippling problems. Notably, in my case, when I try and import scipy.integrate I get the following:

>>> import scipy
>>> import scipy.integrate
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.3/site-packages/scipy/integrate/", line 50, in <module>
from .quadrature import *
File "/usr/lib/python3.3/site-packages/scipy/integrate/", line 5, in <module>
from scipy.special.orthogonal import p_roots
File "/usr/lib/python3.3/site-packages/scipy/special/", line 532, in <module>
from .lambertw import lambertw
File "lambertw.pyx", line 24, in init scipy.special.lambertw (scipy/special/lambertw.c:1588)
ValueError: level must be >= 0

There is a similar bug posted on the scipy dev trac [1], which makes me think that this is probably an upstream bug.

Packages involved:
* python 3.3.0-1, python-scipy 0.11.0, python-numpy 1.7.0-1

Steps to reproduce:
run the following:

python3.3 -c 'import scipy.integrate'

This task depends upon

Closed by  Jelle van der Waa (jelly)
Saturday, 17 November 2012, 12:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed by patching
Comment by Jelle van der Waa (jelly) - Sunday, 21 October 2012, 18:12 GMT
Looks like this is the problem:
The index argument to __import__() now defaults to 0 instead of -1 and no longer support negative values. It was an oversight when PEP 328 was implemented that the default value remained -1. If you need to continue to perform a relative import followed by an absolute import, then perform the relative import using an index of 1, followed by another import using an index of 0. It is preferred, though, that you use importlib.import_module() rather than call __import__() directly.
Comment by Jelle van der Waa (jelly) - Monday, 22 October 2012, 18:12 GMT
I think i fixed a couple of them, will look into a complete patch and hopefully send it upstream
Comment by Mike Ressler (mike_r) - Tuesday, 23 October 2012, 16:24 GMT
I'm interested in helping to test patches, if you would like an extra hand. I got bitten by this in a major way last night, and so am eager for fixes/workarounds.

As a data point, if I import something directly ("import numpy", "import scipy") things work. if I import one of my own modules with no relative imports from the directory the module is in, _most_of them work; e.g. if I go to my .../numpy_ext directory (see below) and "import npe_fits", it works. If I attempt to import that same working module from an alternate directory, then I get something like this:

In [2]: import numpy_ext.npe_fits as fits
ImportError Traceback (most recent call last)
<ipython-input-2-f1197ac680f1> in <module>()
----> 1 import numpy_ext.npe_fits as fits

/home/ressler/Python/Common/numpy_ext/ in <module>()
5 from .npe_convenience import *
6 from .npe_obsolete import *
----> 7 from .npe_bbflux import *
8 from .npe_fitting import *
9 from .npe_fits import *

/home/ressler/Python/Common/numpy_ext/ in <module>()
108 av_rl=av_rlx[q]
--> 110 from scipy.interpolate import splrep,splev
111 def drainelee(w) :
112 """Return the extinction values from a Draine-Lee curve between 0.1 and 1000 um

/usr/lib/python3.3/site-packages/scipy/interpolate/ in <module>()
146 """
--> 148 from .interpolate import *
149 from .fitpack import *

/usr/lib/python3.3/site-packages/scipy/interpolate/ in <module>()
11 dot, poly1d, asarray, intp
12 import numpy as np
---> 13 import scipy.special as spec
14 import math

/usr/lib/python3.3/site-packages/scipy/special/ in <module>()
527 from .basic import *
--> 528 from . import specfun
529 from . import orthogonal
530 from .orthogonal import *

ImportError: cannot import name specfun
Comment by Jelle van der Waa (jelly) - Tuesday, 23 October 2012, 18:35 GMT
Could you report it upstream since it's about a different scipy module. I don't know if anyone reported it yet.
Comment by Jelle van der Waa (jelly) - Sunday, 28 October 2012, 20:04 GMT Comment by Joe Neeman (jneem) - Sunday, 28 October 2012, 21:37 GMT
I still get an error (although a different one):

>>> import scipy.stats
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.3/site-packages/scipy/stats/", line 321, in <module>
from .stats import *
File "/usr/lib/python3.3/site-packages/scipy/stats/", line 199, in <module>
from . import distributions
ImportError: cannot import name distributions
Comment by Mike Ressler (mike_r) - Tuesday, 30 October 2012, 23:25 GMT
I get the same error as Joe. There is a bug report upstream on this issue - I haven't seen any resolution yet. You can find it at
Comment by Tyler (good_boy) - Wednesday, 31 October 2012, 23:01 GMT
I also would like very much like to see this resolved. If patch testing is needed I can help as well.
Comment by Jelle van der Waa (jelly) - Saturday, 03 November 2012, 18:23 GMT Comment by Joe Neeman (jneem) - Saturday, 03 November 2012, 19:24 GMT
This works for me now (at least, I can import scipy.stats -- I haven't tried anything complicated yet).

Comment by Vlad Seghete (vlsd) - Monday, 05 November 2012, 22:12 GMT
This also works for me. Thank you!
Comment by Mike Ressler (mike_r) - Tuesday, 06 November 2012, 18:26 GMT
Okay - this latest package fixes it for me as well. I use a fairly complex ipython setup with multiple default imports (numpy, matplotlib, portions of scipy, and a host of my own modules) and everything now loads without errors, as it used to under python-3.2.

Were your changes patches to the upstream code or something in the Arch build files?
Comment by Jelle van der Waa (jelly) - Wednesday, 07 November 2012, 10:30 GMT
I fetched the changes from upstream, I will push a package in the repos today.
Comment by Franck Michea (kushou) - Friday, 16 November 2012, 21:42 GMT
Is this done? It looks like at least. I can't reproduce with scipy freshly installed from community (0.11.0-4).