How many people here use Python on Windows? What are you using it for?
I for one, prefer win as a dev platform, no matter the deployment platform. That means if the language of choice is Python, I use Python on Windows. I always assumed that this is rather common..
I like the dualboot nature as when in debian I have no excuse to startup a game and get distracted, when in windows I know I'm off work and I can relax.
Also having access to good command line tools is priceless - I'm not conversant with powershell, so maybe windows is good for this now, but being able to quickly grep/sed/awk/vi/etc is so useful.
Server side on the other hand I'm all *nix all the time.
Wow. Ruby must have come a long way. Of course I gave up on it a long time ago when I couldn't find a good decompression library (only one that I could get to work was documented in Japanese).
I've found most python stuff "just works" or can be made to work.
Of course my use of Ruby dates to 2006 or so, as you can see that dates me quite a bit. I'm sure things have improved greatly over the years.
What about it? There's a few packages (mostly C extensions) that don't always build right, but the only problems I've had using pip and virtualenv on Windows have been related to corporate proxies/DNS.
For Python, I have, afaik, 3 (and a half) options:
1) Use something called "easy_install". Installing "easy_install" is not at all easy, which means that the entire experience is somewhat, well, ironic.
1b) Something with "egg files". I never quite understood what these are or how to use them, but I believe they are somehow related.
2) Use something called "pip". If "pip" knows your lib, then all is fine, but if not, things are bad. Also, there are different versions of pip for different "builds" of Python, and I do not know which to use. Tools seem not to be able to figure this out for me. In at least one case I ended up having multiple versions of pip, installed through different means, because the one that came with Python (which afair is the case) was not the right pip version.
3) Google for the library to discover that there is an installer for it, instead of using one of the package manager thingos mentioned above.
Trying to install trac on windows, I had to use all 3 of the above options (not 1b). I forgot what for what, but it wasn't trivial.
As you can see for my story, which is probably full of incorrect details, I'm not an expert. But I'm no expert of ruby gems either, and when I use Ubuntu I'm no expert at apt-get. Why do I need to be an expert of all the four-ish python library distributions to be able to install a single program?
virtualenv really is the key to getting this working well.
Installing trac is non-trivial no matter what operating system you're using.
64 bit vs 32 bit package problems can be horrible, too.
I introduced Python to the company in 2006 after writing a few very quick and dead simple test tools, and it seemed to pick up steam once our QA organization was looking for a way to beef up automation efforts.
Average users can easily manage installing Python since it requires no admin privileges, and it works out of the box without hassle (and it's already there for linux workstations). Once they have it installed you can just email *.pyw scripts and they work for Windows users automagically and email filters that block .exe attachments let them through. In the super restricted government computing environment I did this in (a mix of Windows and Linux computers), the only other reasonable option would have been the JVM, which wouldn't have been nearly as fast to develop against.
[1] I'm talking super simple one-off tools that are written and distributed in an afternoon, not fully designed and developed products. Keep in mind, creating a button that simply runs a regex against a file and spits out a result is literally magic for most people, what I can do in 3 hours of effort can save a non-programmer hundreds of man-hours of work.
I used it for Python's excellent NLTK (Natural Language Toolkit - http://www.nltk.org/) to build http://www.offensivest.com/books/ .
That site ranks the most vulgar English works released by Project Gutenberg. I calculated the ranking based on ~150k user ratings of the offensiveness of words listed on The Online Slang Dictionary.
In the *x world, I tend to use Perl, because I learned that first and know things in my fingers that I have to stop and think about with Python. In the Windows world, though Python for Windows just makes life so much easier.
I dev on Win because of the better multiple monitor support. I run using 3 large monitors on my Dev box, that I can rotate between landscape and portrait mode at will.
Python is my language of choice for WebDev, tools, etc...
A real POSIX shell that isn't slow. A fast gcc and the like.
It is a pain to compile psycopg2 and lxml on windows compared to linux. Cygwin and virtual machines are unfortunately too slow when you are used to working in a non-virtualized Linux environment.
I'm heavily biased though because once you are addicted to the command line, it becomes very hard to live on Windows :-(
I'm at one of the big three, where getting a *nix machine on the network is next to impossible without piles of paperwork, and Windows is a requirement for our test machines. I'm all for better Windows tools :)
Yes
How do you plan to protect IP?
Mainly by asking nicely.
We do use py2exe to package up our application, but that is more for convenience and to act as an indicator that we don't want people to go hacking around in the source code. Also, even though python makes up the bulk of the app, measured in lines of code, that is not where the really interesting things happen, so we're not too bothered one way or the other.
And in our studio, for good and bad, Windows is mostly deployed (audio guys might consider getting Macs again, as there was not proper support for ProTools on recent Windows versions)
I also script Android and *nix with it.
I see it as a universal shell.
I'm also writing a cross platform program in it. It's support for Windows features is quite good. (no gui stuff so I can't speak to that).
In the future I want to try pygame (or other gaming framework) if I can find the time.
It is already used heavily on the analysis side, but windows isn't required there.
And why do I use Windows? Excel.
At the moment though, I use Python for time management (using some scripts I wrote), a general purpose calculator, data munging on the fly, watching memcache stats, reporting and some other general bits of duct tape and string.
Having the power of .Net in a scripting language is great, but it would have been even nicer if that language was consistent with the others on the platform (C#, JS, Ruby, Python for instance.) In fact I regularly think of converting our existing PS deployment scripts to Python, and better tooling support would definitely help.
Don't try and think of it as similar to other shells like bash, but as an interactive console for objects. The operators, flow mechanisms and semantics make a lot of sense from that perspective, at least to me.
I've found that in that capacity, and as soon as I grokked the object pipeline, it's a wonderful tool with access to the entire .net ecosystem and a really hard push from Microsoft to have support for it on most of their tools
I've been automating several procedures with it and it's been working great.
That said, I also have some (iron)python scripts for some other tasks that don't involve as much glue between applications and services.