On Wed, 30 Jul 2014 15:24:58 -0500, Guy Streeter wrote:
On 07/30/2014 12:52 PM, David Sommerseth wrote:
> On 30/07/14 00:07, Guy Streeter wrote:
>>
>> Personally, I really want to forget Python 2 and just write in Python 3 from
>> now on. I'd like to propose some enhancements to the tuna GUI (more on that
in
>> another email), but I don't want to write them in Python 2, especially if
they
>> need to be changed for Python 3 in the future.
>
> I agree. Moving towards Python 3 is the future. But I'm glad Python 2
> will be supported for a while, so the transition can go smoother and not
> be rushed.
>
> I'm also the upstream maintainer of python-ethtool, and I do poke at it
> from time to time. Moving towards Python 3 is a bigger job, but not
> impossible. But I'm also evaluating if another approach of integration
> should be considered, in addition to remove some old and deprecated APIs.
>
>
> --
> kind regards,
>
> David Sommerseth
>
I checked the tuna code, and it uses get_active_devices() and get_module()
from python-ethtool. It wouldn't be hard to come up with that functionality in
an alternative way, so I don't think we have a really hard dependency there.
It occurred to me today that I have already written for another project a
Cython module that does everything we need python-schedutils to do. I could
break that out for tuna. It works just fine when compiled with Cython3.
python-linux-procfs is an odd collection of info parsed from /proc. I think
uplifting it to python3 is probably less work than finding alternative sources
for the information tuna gets from it.
I do have Cython modules that provide bindings for libnuma and libcgroup, in
case that's something tuna could use.
--Guy
can you please share via git{hub,orious} or another git repo?
_______________________________________________
tuna-devel mailing list
tuna-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel