As a newbie to Python, my biggest issue when coming up to speed on a new project is chasing down the types of arguments to and return values from functions. Previously I was a Java programmer and while I don't miss its verbosity, I do miss how I always knew what types I was working with. Does anybody have any tips that make this easier?
The biggest tip: The Python interactive shell is your friend. Use it to play with things you're not sure of. IPython[1] is a more advanced Python shell you may like. Lots of people also swear by pdb, the Python debugger. Personally, I get less use out of it than others, but YMMV.
But overall, this is a problem involving documentation, design and naming, and your own mindset.
Ideally you would never really be put in the position of not knowing, because it would be clearly documented. Of course, we all know how well that tends to work.
Second, well-designed systems with good naming practices will make it fairly obvious most of the time what sort of arguments are expected, and what you can expect to get back. (This is related to the next point.)
Finally, coming from a "static" language, your brain just isn't trained to perform its own type inference and deal with duck typing. This is mostly a matter of practice, you get better at it. But if you aren't already familiar with various kinds of typing, be sure to do some reading. A better understanding of the differences will help make sense of what you're seeing.
This illustrates the folly of big government. The politicians in congress are not lacking intelligence, but are simply trying to do too much. It would be impossible for these 535 men and women to each have a thorough understanding of all the industries they attempt to regulate. Although the tech community is up in arms over SOPA right now, how many equally bad laws have been passed that affect other industries? The government is the entity that enables corporations to violate the rights of the people.
Check out the excellent book "Procrastination: Why You Do It, What to Do About It Now" by Burka and Yuen. I discovered it via a HN comment and figure I should repay the favor.
Hopefully an equally (it not more) stupid follow up by the city council would be shot down when coming to a vote. Perhaps McDonald's is banking that lightning won't strike twice?
I tried Eclim a couple times, but didn't like it. Currently I use Vrapper and am content to have the basic motions and marks. I've also heard good things about Viable.
Depending on the work environment this might be good advice. On the flip side, however, I think many people have or remember having coworkers who ask questions any time they get stuck without hardly trying to solve the problem for themselves.
Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.
"Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
"Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff."
Granted, interrupting a peer makes more sense if you actually can't make progress without another opinion on design, rather than just being lazy and using them as a living reference work.
