Re: [python-control-discuss] NoneType and circular relative imports

[Richard M. <mu...@cd...>]

Great references.  I read them briefly and there are some clear things to try.  If understand it right, one fix is what Scott suggested (most the imports inside the functions), but there are other things to try.  It looks like part of the problem is that 2to3 creates relative imports, but not sure.  In any case, I know have a good starting point.  I think what I'll need to do is get python 3.x running so that I can definitively test that things are working.

Won't have time to look at this until Friday, earliest.  For sure over the weekend.

-richard

On 31 Oct 2012, at 21:01 , Dale Lukas Peterson <haz...@gm...> wrote:

> I just Googled "python package import best practices" and found this:
> 
> http://docs.python.org/3.4/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
> 
> I don't know that there are any differences between the
> recommendations for Python 3.x vs. 2.x, but for what it is worth here
> is the same page but for Python 2.7.3 (they might be identical, I'm
> not sure):
> 
> http://docs.python.org/2.7/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
> 
> In particular they give the advice "Never use relative package
> imports".  There is also good information there regarding how to avoid
> circular dependencies, which is exactly the issue with the current
> code.
> 
> Luke
> 
> On Wed, Oct 31, 2012 at 11:28 AM, Dale Lukas Peterson
> <haz...@gm...> wrote:
>>> import loops: if you have a chance, Luke, can you try out Scott's change
>>> and see if it works on python 3.  I'll try to install it over the weekend
>>> and try it myself, but would be good to get another check.
>> 
>> I applied Scott's change to revision 211, then ran:
>> $ find . -name "*.py" -exec 2to3 -w {} \;
>> 
>> Then I built and installed it and when I import it, it gives me this error:
>> 11:17:33 ~$ python
>> Python 3.2.3 (default, Sep 30 2012, 09:06:04)
>> [GCC 4.6.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import control
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in <module>
>>  File
>> "/home/hazelnusse/usr/lib64/python3.2/site-packages/control-0.6a-py3.2.egg/control/__init__.py",
>> line 60, in <module>
>>    from .bdalg import series, parallel, negate, feedback
>>  File
>> "/home/hazelnusse/usr/lib64/python3.2/site-packages/control-0.6a-py3.2.egg/control/bdalg.py",
>> line 55, in <module>
>>    from . import xferfcn as tf
>>  File
>> "/home/hazelnusse/usr/lib64/python3.2/site-packages/control-0.6a-py3.2.egg/control/xferfcn.py",
>> line 84, in <module>
>>    from .statesp import StateSpace
>>  File
>> "/home/hazelnusse/usr/lib64/python3.2/site-packages/control-0.6a-py3.2.egg/control/statesp.py",
>> line 85, in <module>
>>    from .xferfcn import TransferFunction
>> ImportError: cannot import name TransferFunction
>>>>> 
>> 
>> So 2to3 is converting "from xferfcn import TransferFunction" to "from
>> .xferfcn import TransferFunction", which for some reason does not work.  I
>> think the reason it does not work has to do with the __init__.py file as
>> well as the __all__ variable not being set in each module (i.e., statesp.py
>> and xferfcn.py).
>> 
>>>> Is anyone ensuring that running the 2to3 tool is sufficient for use of
>>>> python-control with Python 3, or otherwise working on a script that makes
>>>> necessary changes?
>> 
>> I have apparently verified that it isn't.  Sympy uses a script called
>> "use2to3" which runs 2to3 on most (but not all) of the source python files
>> and generates a new source tree in a folder called "py3k-sympy" that
>> contains the converted files.  You then build and install sympy from that
>> folder using python3.  You can see how they do it here:
>> 
>> https://github.com/sympy/sympy/blob/master/bin/use2to3
>> 
>>>> While that design pattern is nice, it may not yet be warranted for
>>>> python-control, which is contained entirely in a single directory with no
>>>> subpackages.  The simplest change I see to avoid the import error you found
>>>> is below (given as diff output).
>> 
>> True.  I'm not certain what the "best" way to do this is either, I just know
>> what has worked for me in another project across many different versions of
>> Python.
>> 
>> Luke
> 
> 
> 
> -- 
> “People call me a perfectionist, but I'm not. I'm a rightist. I do
> something until it's right, and then I move on to the next thing.”
> ― James Cameron
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss