tswicegood

@grhmc -- that's really cool. I wish I'd had something like this a number of times. "Now, which one of the 10 boxes labeled "kitchen" has the peeler in it?" :-)

FWIW, I was a paying customer. I know others who were as well. Most everyone I know, including myself as of two weeks ago, has stopped paying for the service. It had gone downhill to the point of being unusable.

There is a demand for this type of service. Real-time chat is in extremely high demand still. Chat was the number one requested feature a "build-you-own" social network startup I worked at a handful of years ago even before Facebook added their chat.

Eye based window/input focus. I've been wanting this for years.

"Does it… work?" is not the standard by which good Python code is measured. Django went through this process years ago. It's convenient to be able to call `from myapp.models import *` and have an `Articles` model magically added to your module even though you never defined. They realized years ago that writing clever code for the sake of being clever was a bad idea. How are you going to get someone else to be able to maintain it? Not only do they have to know the logic of what you're doing, they have to know how you hacked things together.

Line 17 of PEP-20 sums up my thoughts on this code as more than an intellectual exercise.

> If the implementation is hard to explain, it's a bad idea.

Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job?

Just to clarify. I applaud this type of development for people trying to learn various parts of Python like playing with the stack, but the idea of this being used in the wild scares me a bit.

FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of import voodoo, specifically the import hooks that Python ships with. Here's an example of their use inside a small side project of mine: https://github.com/tswicegood/maxixe/blob/master/maxixe/__in...

All that said, this is horribly un-Pythonic. A much better route to so is something like envoy[1] which simply wraps `subprocess` in a sane API.

[1] https://github.com/kennethreitz/envoy

Frank's response covers it for me. There's plenty of dangerous things you can do in os. Same goes for sys, etc. None of them are going to launch missiles at someone or cause elevators to stop working, but you could blow away a day's work, drop a directory by accident, or some such.

As long as you can `import os`, you can be dangerous in Python. :-)

It looks like this is something that the developer is already thinking about. https://twitter.com/twolivesleft/status/129304975623995395

1) I think an aggressive personality is common in many successful---not the correct word, but it'll do---people. Look at any "team" sport where one player tends to take the spotlight. With the Tour de France on, I can't help but recall all of the prima donnas of Tours gone by. Actually, it's so rare to have a down-to-earth, genuinely thoughtful and nice person rise to the top in that sport that it's always called out when it happens.

2) I think being a jerk online and lack of in-person social skills aren't correlated. For whatever reason, when it's a computer screen in front of you, people tend to be more aggressive about their point of view. Unchecked, that can turn into "jerkiness," but I don't think it's a one to one. Don't get me wrong, I know plenty of people who are jerks online and the same offline. I also know plenty of people who are jerks online and the kind of person you hope passes you on the highway when you've got a flat or run out of gas---it's a given they're stopping and helping in any way they can.

3) I'm a little disturbed by the implication that a stunted career is what motivates people to contribute to open-source software, but I assume it wasn't meant quite that way. This illustrates an interesting point. Given that I don't know the context of where your fourth paragraph is coming from, I'm assuming the best and that you didn't mean it as I took it during my first reading.

That type of small misunderstanding could have resulted in me (or someone else) firing off a quick response calling you out on it, or even less hostilely taking issue with it and trying to rebute it. That in turn could have made you feel more defensive, so your next post might have been preemptively aggressive, and so on. This quickly deteriorates into a cycle where we're making each other more aggressive without meaning to and give rise to this mentality.

Subtly is lost online. It's ashamed, but the way it seems to be.

All that said, I do think those who the community looks up to are the ones that set the tone, for sure. I can point to many a project mailing list that have been rendered useless because some of the biggest (or perceived, historically, or actual) contributors take it over with their overly curt style of responses. :-/

Gah... Silly multiple domains: http://news.ycombinator.com/item?id=2709301

I would really be interested in some use-cases. The examples they give are fairly limited.

+1 to the attitude. It's all about getting the service back up and making it better. We (collectively) tend to spend too much time trying to figure out who to blame instead of just doing the cool shit that needs to be done. Kudos!

I think that's the whole point though. It used to be that you could be a Rails dev with very little Ruby experience. Now, that's not the case.

It's great to advance, but when you start out as being quick and easy to get started in then everyone starts progressing you can easily forget that it's taken years as a community to get to this point. If you're not careful, as a community, you end up leaving the newbies always playing catch up instead of providing them a helping hand to get started.

Completely self serving to post this -- I work for #9.

> virtualenv... falls down pretty hard on mouldes that require C bindings

Care to elaborate? virtualenv has worked fine for me and that plus pip means that the rest of the community can use and understand your code and all of its dependencies without having to have access to you or your machine to figure them out.

This is a bad idea on so many levels. You should always talk to the most specific version of your settings rather than have the super generic one try to add extra stuff from another module that it loaded.

I'm definitely hoping we can work this in too. We'd love to get this in once we figure out where it'll fit.

We're still in the process of getting everything setup. This is literally just today public. We'll be getting code setup with the ability to contribute and proper links on the website over the next few days to week.

Yes. We did and we are. :-) No need to reinvent the wheel here, so we're using what already has a proven track record in the newsroom.

Wordpress is an amazing blogging system and it's coming into its own right as a CMS, but it's not geared toward the newsroom. Armstrong (the name of the project) is being built for the newsroom. Because of that, it probably won't gain a ton of traction in the standard Drupal/Wordpress deployment area, but that's fine by us. We're out to make the best news CMS, but the best generic one.

That focus is what's sets us apart from many of the other open-source offerings out there, in my opinion.

I'm one of the devs on the project. It's Django/Python-based. That provides an amazing platform for newsrooms and their diverse needs, so we're just building on top of it.

This is all really cool stuff, but I can't help but thinking they've got a dozen or so separate packages here. They've also re-invented the wheel at every turn. All new wrapper for the Twitter API and every search engine? All new graphing library for JavaScript.

Don't get me wrong, this is all awesome, but a lot of it could have been re-used from better sources without having to spend time working on random API wrappers and the like. I would definitely like to know the reasoning behind creating everything from scratch.

That's an interesting idea. I like the idea of turning things off too. In some cases, that's more useful than explicitly defining a @task. Care to open a ticket on code.fabfile.org with it? Maybe we can work that in as an option in 1.1 (when @task is set to hit).

Yes. Those of us who have been in the Fabric community working with one another are aware of this. From my conversations on IRC with @tav, I thought he was as well.

It's always encouraging to see new people get involved. It's quite another to see someone relatively new to the community try to go around that community by announcing "new features" for a project they've barely started work on.

Sorry if that comes off a little bitter, but seeing this as the top post on HN today rubbed me the wrong way.

Just a quick note: these features are definitely experimental. The @task decorator has been in stable forks of Fabric for over a year at this point (this is the 3rd, if not 4th independent implementation of it). Likewise, parallel tasks have also been relatively stable for quite a long time.

You can also do:

    stuff = stuff is not None and stuff or []

At this point, pip is the way to install Python packages. Anyone who's pointing you otherwise is a bit out-of-date (touch?).

Not your normal HN fare, but the part about the main drives of people I found interesting from a startup/app perspective. Are these things you're paying attention to in your startup? Are you doing them for your own financial gain, or to create true value for the world?

Dive into Python and Python the Hard Way are both really good books that are available online to read through. Python.org provides some good docs too along with a pretty decent tutorial.

I assume since you're coming from PHP you're going to want to do some web stuff with it. Django has excellent docs and there's DjangoBook.com as well.