Foreword: Please do not reply to digest messages (or without editing the subject), as tracking threads is quite difficult :-) Thanks.
> I understand. I think what I was proposing was less drastic: I think > the UsbSerial class (and indeed the whole serialext package) is more > general than just for FTDI chips, and would make more sense as a part > of pyusb. Then all different USB-serial chip drivers, including pyftdi, > could share it as common code. I do not mind if some pyftdi code move to pyusb, but this is really up to Wander. I'm not sure it would really make sense though. I'm sure nobody wants to move the UsbTools class: this code is crap (I can write this as I wrote it :-) ). The features it provides are definitely useful, as enumerating a full USB bus topology takes so much time that it should be done as few times as possible. However the way it is implemented is really ugly (it was a quick and dirty hack that has not been removed) and rewriting it is my todo list for years... To sum up: rewrite it, do not import it if you really need it. The only potential issue with licenses is the ftdi.py file. All other ones do no need to use the LGPL v2 license. Manu. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
