`from dolfin import *` no longer imports `ufl.product`
from dolfin import *
used to export ufl.product
. It no longer does, since SWIG was removed.
Comments (13)
-
-
reporter I agree this is less important than many others, and expect the inevitable
wontfix
status.(a) I wanted to report any incompatibilities that arose in trying the new Python bindings, to discuss each and decide whether they're justified or not.
(b) dolfin exports lots of other UFL routines (e.g.
inner
,grad
). I don't think dolfin should be in the business of deciding which parts of UFL to export or not. Either export it all or export none of it. -
@pefarrell Agree. It's unfortunate that the namespace is so polluted; given current state not importing something is rather arbitrary.
(I've heard of tab-completion with DOLFIN causing crashes with so much in the toplevel namespace).
-
What about having
from fenics import *
pull in everything in dolfin and ufl? This approach avoids dolfin being a gatekeeper for what is considered "core" ufl and what is "fringe". -
This is more subtle. There are DOLFIN overloads of UFL. Should those be pulled by dolfin or not?
-
I would say that if
ufl.product
was imported before then it should probably be imported. -
There are more issues of this kind,
ufl.Index, ufl.indices
also missing. -
reporter And
diag
. -
Let's make a branch with the missing imports added back. We can comment, pull-request and merge as usual.
-
Why don't we overhaul the namespacing now when there is a chance?
To be more constructive, we wanted to have namespaces in DOLFIN. Why don't we put UFL imports and its DOLFIN overloads into
dolfin.ufl
?Who still wants to write legacy FEniCS can do
from dolfin.ufl import *
. But in any case the change will make more clear what's going on. -
@blechta This is a typical example of dilemma between ease of use and clarity (the actual understanding of what I am doing). From developer's point of view clarity is prior to ease. Users do not usually care what is UFL and what method is imported from where. To me, personally, FEniCS tends towards the ease of use.
-
Does this have been resolved? I cannot use indices(), like before with 2017.2. Is there a workaround for those old commands?
-
from ufl import indices
- Log in to comment
I don't see how this is a bug. Previous DOLFIN module was creeping with imports. I don't even know why there is
ufl.product
instead of standardnumpy.product
.In a broader perspective, pybind11 keeps the right to bring an usually big number of interface changes, not always with deprecations. It is a good opportunity to fix old pains. I don't see why developers of FEniCS applications should spend time on backward compatibility with old software.