Have a few questions about libusb VS openusb
I'm the author of a project called Berry4all that allows tethering for Blackberries Via USB.
Cuurrently I'm using libusb-0.x but i'd like /need to migrate to either libusb1.x OR libopenusb ... but I'm not sure which to pick
Some of the things I need:
- Linux support
- Mac OSX support (need it to work and be able to package it)
- Python bindings
Opinions on either and why pick one over the other.
I would go for libusb-1 because it seems architecturally simpler, more actively maintained, more portable and more mainstream than OpenUSB. Their webpage lists successful projects based on it, and a small comparison to OpenUSB you might find useful.
Related
So it's a new millennium; Apple has waved their hand; it's now legal to include a Python interpreter in an iPhone (App Store) app.
How does one go about doing this? All the existing discussion (unsurprisingly) refers to jailbreaking. (Older question: Can I write native iPhone apps using Python)
My goal here isn't to write a PyObjC app, but to write a regular ObjC app that runs Python as an embedded library. The Python code will then call back to native Cocoa code. It's the "control logic is Python code" pattern.
Is there a guide to getting Python built in XCode, so that my iPhone app can link it? Preferably a stripped-down Python, since I won't need 90% of the standard library.
I can probably figure out the threading and Python-extension API; I've done that on MacOS. But only using command-line compilers, not XCode.
It doesn't really matter how you build Python -- you don't need to build it in Xcode, for example -- but what does matter is the product of that build.
Namely, you are going to need to build something like libPython.a that can be statically linked into your application. Once you have a .a, that can be added to the Xcode project for your application(s) and, from there, it'll be linked and signed just like the rest of your app.
IIRC (it has been a while since I've built python by hand) the out-of-the-box python will build a libPython.a (and a bunch of other libraries), if you configure it correctly.
Of course, your second issue is going to be cross-compiling python for ARM from your 86 box. Python is an autoconf based project and autoconf is a pain in the butt for cross-compilation.
As you correctly state, making it small will be critical.
Not surprising, either, is that you aren't the first person to want to do this, but not for iOS. Python has been squeezed into devices much less capable than those that run iOS. I found a thread with a bunch of links when googling about; it might be useful.
Also, you might want to join the pyobjc-dev list. While you aren't targeting a PyObjC based application (which, btw, is a good idea -- PyObjC has a long way to go before it'll be iOS friendly), the PyObjC community has been discussing this and Ronald, of anyone, is probably the most knowledgeable person in this particular area. Note that PyObjC will have to solve the embedded Python on iOS problem prior to porting PyObjC. Their prerequisite is your requirement, as it were.
I've put a very rough script up on github that fetches and builds python2.6.5 for iPhone and simulator.
http://github.com/cobbal/python-for-iphone
Work in progress
Somewhat depressing update nearly 2 years later: (copied from README on github)
This project never really got python running on the iPhone to my
satisfaction, and I can't recommend using it for any serious project
at this stage.
Most notably missing is pyobjc support (which turns out to be much
harder to port to iPhone since it relies on more platform-specific
code)
Also missing is the ability to statically compile modules, (all are
currently built as dylibs which works for development, but to my
knowledge wouldn't be allowed in the App Store)
At this point this project is mostly meant to be a starting point for
anyone smarter than me who wants to and can tackle the above issues.
I really wish it were practical to write apps entirely in Python, but
at this point it seems impossible.
I also started such a project. It comes with its own simplified compile script so there is no need to mess around with autoconf to get your cross compiled static library. It is able to build a completely dependency-free static library of Python with some common modules. It should be easily extensible.
https://github.com/albertz/python-embedded/
I seem to be a fairly reasonable programmer once the configuration is set up, but am a noob at yak shaving, especially when there is a confusing choice of different yaks.
I am enjoying learning Python. It was the obvious choice with its abundance of libraries, native execution on both windows (for the moment) and linux (later, but not right now), and regular syntax. Up to now, everything I've wanted to add on has either just installed from a binary, or just been a simple file copy to the lib folder; pyaudio, numpy, videocapture, etc etc.
I am now tackling USB. I have bought a UM245R usb module and want to bit-bang it. I quickly learnt from PyUSB errors that I needed a backend. After a bit of reading, it appeared that as I have no legacy code, libusb1.0 was the appropriate choice. Is this correct?
Now my problems start. I am thoroughly confused about how to get it onto my PC. I have no tools or experience to build it from source, and cannot find anything that claims to be a self-installing .exe. I have seen a number of seperate installers mentioned, but cannot find any concensus on which uses what or is the correct way to go. I think I've been through all the replies here tagging libusb, without finding the specifics.
Would somebody who's done this for windows (XP SP3) take me by the hand and tell me what to use to install it please, for Python 2.6.
thanks in advance
From the pyUSB tutorial; "platform neutrality; ... PyUSB comes with builtin backends for libusb 0.1, libusb 1.0 and OpenUSB". So pyUSB doesn't really care what you use. But libusb 1 seems to be the safe choice.
Look at the windows backend section of the libusb wiki. You'll find prebuilt windows binaries (zadig.exe, under "Driver Installation") for libusb 1.0 there.
There are known restrictions to the underlying Microsoft driver that might impact its usability; e.g. you cannot reset USB devices nor change the device configuration.
As a small-time Python package writer (cobs, simplerandom), I'm wondering what Python versions I should support.
I've heard anecdotally that Python 2.5 is still in use on enterprise type servers. So I thought 2.5 was the oldest that needed to be practically supported, here in 2011.
However, I saw this blog in which the author says he's still using 2.4. From memory, I saw an e-mail on the PyCrypto mailing list saying they aimed to keep support going back to 2.2 if possible.
Of course, then there's Python 3.x which is slowly gaining momentum. It would be good to know who is using that.
Then, there is also Jython and Ironpython, and I have very little idea about them.
Is there any concrete and up-to-date Python installation/usage data available to enlighten us? Is there any "best practices" or other advice for what versions/flavours of Python a package writer should aim to support?
I think that this is a problem that's simply inherent when developing any software. Anyone could be running any version and would need support for that version (I wonder how many people are still running Windoze ME out there? ;)). Personally, when developing libraries, I'll support only support the current version+. If for no other reason, because I'm only one person and I don't have a team.
Having said that, I'd stick my packages up on github and take patches from anyone who wants support for previous versions (and is willing to put in the work).
Edit:
I've found that a good rule in software development (especially packages) is develop only for what is needed, not what you think might be needed. In other words, get it working for whatever version of Python you're running (or is dearest to you) and then take support requests if you want to implement them yourself as people need them.
I have servers that run Python 2.3. :-)
But no, you don't need to support it. Most servers like that are just running, and do not get any new modules installed.
When creating a new module today, 2.6, 2.7, 3.1 and 3.2 is the versions to support. For existing modules you can ask your users. :-)
You should support the latest of the 2.x series (2.7 as of now) and 3.x (3.2 as of now). Unless you have a specific need for supporting older versions, I don't think you need to go there.
As for alternate implementations like IronPython and Jython, you should do that only if needed. It can be time consuming (although perhaps educational) to support you app for all these implementations.
As a side node, to test your app on multiple versions/implementations of Python, I recommend tox.
I see this question but it's from 2008. Seems like many version control systems have become trendy lately. Also, the question was exactly my situation:
Django based web application
Using an isolated virtulaenv environment
One man developer
Will not be open sourced
Linear project (no branches)
Perhaps will be using tags for releases (but not needed)
At some point, it might become two developers. I'll worry about that down the line.
My question: Is there any reason to switch to another version control system now? I use SVN on a Linux development box right now.
For a one-person development effort, use whatever version control system lets you get your work down most effectively. For my own private projects, I do use Git these days, but that's only because I feel it gives me benefits vs. other choices. It is really up to personal preference.
Lately I've felt like I should also learn Mercurial, to be more well rounded, but that's just for my own education. So again, whatever works best for you is what to use.
Currently I have Python 3.1.1 installed on my system, same version on my server with WSGI 3.0 running on Apache 2.2.
I want to keep using Python 3.1, but I'm finding that lots of libraries/frameworks don't support it yet, namely Django, Pylons, MySQLdb, etc.
I also checked an account I have on a friend's server, and it is running Python 2.3.4...
I want to write a sort of blog/forum type application that I can expand into a CMS, and eventually write related desktop applications for, as sort of a long-term pet project.
I'd like to use the newest version of Python possible for best security and highest consistency with the desktop-applications-to-be, while still maintaining a good level of portability, and supporting most of the frameworks and libraries I will use.
But I'm lost on which one I should pick. It seems like 2.4 would have the greatest amount of portability but it's sort of old, and I don't want to wind up using a bunch of post-2.4 features that won't compile, and having to re-write with messier code to compensate for it. 2.6 would be better, but it seems like lots of libraries are still porting over to that, and 3.1 would be the best since it eliminates a lot of cruft from the language.
One thing I'd like to highlight is that it'd be nice to know what I will be missing if I choose an older version of Python. For example, if I were to need my application to run on my old Python 2.3.4 account on my friend's server, what libraries/features would I be lacking that exist in newer versions? What problems would I surely run into that would make me wish I was using Python 2.6 or 3.1? Which of these features would be available via __future__ imports?
So, what would be the best direction to go? Should I just use 2.6 and deal with any issues? Should I go for 2.4 to maximize my ability to possibly distribute it to shared hosting environments? Or should I just jump into 3.1 and have a slightly-crippled application until libraries like MySQLdb catch up?
For now, Python 3 is not widely deployed in production. Depends on what you use Python for. If it's just for one off scripts, it will be ok either way, if the idea is to use third party modules, C modules and or deploy painlessly, then settle for any of the 2.4+ versions. Many projects strive to keep 2.3 compativility, but you shouldn't have any problems to use 2.4-2.6, as the changes in the language are minor. If you can, use 2.6, as it's the closest to Python 3, as it has some features backported to it.
The problem with Python 3 is a Catch 22:
most useful third party modules are still not ported to 3, as developers are waiting for wide usage,
people can't migrate because modules they rely on haven't migrated yet, keeping the sage low.
You should not have any problems using any of the 2.4-2.6, give 3, some time.
Use Python 2.6
Begin with Python 2.5 if you're not sure.
Have a look at Google App Engine (based on Django). It's using Python 2.5 and it's free.
However, you will not be able to call scipy (for example) or any libraries with "C" inside.
You will have the greatest amount of portability with Python2.5. Moreover, python3k is not really used in the industry.
"2.6 would be better, but it seems like lots of libraries are still porting over to that"
What? What libraries -- that you need -- are "still porting over to that"?
"3.1 would be the best" "but I'm finding that lots of libraries/frameworks don't support"
Correct. You've stated that twice in the question. That's very clear.
"Should I just use 2.6 and deal with any issues"
What issues? Do you have any specific concerns?
It seems to work really, really well. What are your specific concerns?
For intranet web apps I had to install python 2.5 (due to combination of wiki, bug tracker, and httpd WSGI compatibility).
For custom web apps I standardized on python 3.2.
Thus I have both installed simultaneously. I write for 3.2 and bring specific libraries up to spec as needed. However large packages which I don't want to modify use their own 2.5.
Compatibility between 3.2 and 3rd party packages is still an issue at this time, and so is the lack of proper python recipes.
In summary: Install two versions.