jackdied
Software Engineer, Engineering Manager, UI/UX Frontend (http://www.getcurata.com/careers)
Small Django/Python shop. We make a curation product and have actual customers who pay us actual money (crazy concept, I know).
As part of the engineering team you will work on a bit of everything: front end, NLP pipeline, database, devops, support. And if you're a bowler you can join a bunch of us in the Wednesday night league at Lanes & Games.
Most python users have never heard of anyone other than Guido. That's fine because people who contribute to open source projects don't do it for the fame, and that's reasonable because you can't be expected to memorize the names of all the people who wrote the tools you use. That said, it can be frustrating being not Guido (Brett gets heaps of credit inside the community but zero percent of Guido's name recognition).
1st story: my first PyCon I went out to the smokers deck and introduced myself (this was '02 or '03 - I'm not sure we even had name badges). The other guys turned out to be Tim Peters, Christian Tismer, and Alex Martelli. Python jackpot.
2nd story: I told that first story to a random lunch table of people at PyCon last year (as a rule I eat lunch with no one I know at cons) and the collective reaction was: who?
So yeah, don't feel bad about not knowing who Brett is (but do buy him a beer if you run into him). And definitely don't get involved in open source for the fame. [Bonus trivia: Gustavo also has a commit bit, as do a couple other people in this thread]
At least two automated trading firms sent contingents to PyCon last year so you won't be alone (I think both were state-side). As for microbrews? Although it started with states that had odd blue laws for liquor licenses (limited regular licenses but unlimited for on-premises brewing) you can now find micro-breweries in every major city and most minor ones. PyCon always has a beer BoF group.
See PyCon talks in Boston Wednesday
If you want to get this past python-dev you'll need to explain the benefits, here's a start:
1) Lower cognitive load: Users can understand blocks but the extra naming/reference is one too many things for their brain stack to handle.
2) More descriptive: with blocks the first line says "I'm about to define a function for use with X" instead of the existing way which says "I'm defining a function. Now I'm using that function with X."
3) Show me: take a chunk of an existing project (stdlib is best) and rewrite it with the proposed block syntax. You get to cherry pick the example so if the new version doesn't read much cleaner than the old version maybe the idea isn't so hot.
I'm -1 on the idea but if you want to change my mind you have to make an argument that doesn't start with "In Ruby..."
Oh wait, it doesn't? In that case this link is off topic, and very creepy.
As for python 3.0 being 10% slower than 2.5 - that means that it is is just 1.9 times faster than Ruby instead of a clean 2x? And the backwards incompatible version took just two years instead of infinity like Perl and two years instead of the UNK for Ruby? Python 2.5 benefited from a corporate sponsored "Need For Speed" sprint where twenty of the core devs went on a paid vacation with a mission to just sprint on speed issues. There hasn't been a corresponding sponsored event for 3.0.
A huge amount of volunteer time has been spent on backwards compatibility issues. When the Python 3.0 issue was first floated the Twisted and Django folks had lots of worries about the transition and supporting two versions (2.x and 3.x). Hundreds of hours were spent on the email lists and PyCon dinners hashing out the details. Thousands of hours were spent adding warnings and best practices docs to 2.6 as well as on the "2to3" translation tool.
Time will tell but there will certainly be lessons learned from the Python 3 release.
The old behavior didn't effect server sized systems and typical workloads but it did piss off some embedded apps.
The author might have had more luck finding Marx if he hadn't been looking for him in the Economics Dept.
PBS made "Free to Choose" into a series back in the 1980s. You can find all the episodes on YouTube.
NB: python bitwise operations are not super fast like in C. They don't get optimized down to single CPU instructions but instead are looked up like regular type methods (e.g. __str__ and __add__). An "ob[~0]" won't kill you even in a loop but don't bother translating simple math into bit-twiddling because it won't help (and might hurt if it inflates the number of operations).
2) Superdelegates are supposed to make the kind of calculations you are suggesting. They have a big advantage in that they vote last so they know the most up-to-date breakdowns of the individual states. Superdelegates are immune to the cross-party registration (Rep voting in Dem primary) and are more likely to listen to actuarial opinion - you could provide the same info to the voting public but it wouldn't change votes much. That's the theory of Superdelegates anyway.
/farker but not a tf'er
ASPN cookbook recipe for a simple SSL server http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/4424...
The MeTooCrypto package from the Chandler project http://chandlerproject.org/bin/view/Projects/MeTooCrypto
You could be non-secretive without being interactive or not taking opinions. But that seems like burning PR early for a product you will be releasing soon anyway.
Do talk with people who's opinions you already value. But you aren't Microsoft so pre-announcing a product won't intimidate others into not competing with you and it won't whet potential customer's appetite. Make something you know you would use and then see how others like you respond.
"You can't run a linear system on a finite planet indefinitely." I'm going to drop that one at a cocktail party and count how many people nod versus sigh.
Edit: but the dtrace part is very good. Around the 1 hour mark he starts demonstrating using dtrace to instrument the python parser. Good stuff.
An anecdote on bad linear search: in the 90s I worked on a system in C++ that made heavy use of inheritance and other C-plus-plus-ery. There was a bunch of file opener classes each that found files in a different way (regexp, straight path, glob). They differed only in a method named match. The base class called match on every file name in the directory until it returned true. That was fine for regexps but even if you opened a file _by name_ it took N/2 syscalls to readdir to find it! This worked OK until someone created a directory with 10k entries on a production box. Ouch.
Look at duels.com (a simple player-vs-player game). On each page it needs to know your stats/equipment and that of the person you are dueling. In an SQL database you might store the person/stats in one table, the inventory in another, and the fight record in yet another. In SimpleDB the stats and inventory could be in one domain with fight record in another.
SimpleDB or even dumb file-per-player based systems don't pay the overhead for allowing arbitrary queries so they scale better. Your SQL store will be slowed down by the weight of inactive players and their inventories and all the indexes and data they have lying around. Using in-memory caching (like memcached) is a popular way to pay the SQL cost less often while keeping the arbitrary-query ability on the back end.
And of course don't forget that SimpleDB is hosted by a farm of machines tweaked and maintained by someone else. Your MySQL setup will never be that cool.
Edit: and as for XML,if you add that to SQL, well now you have two problems.
I'm simultaneously creeped out and impressed by the Comcast commercials that offer to target ads by age, sex, voter status, and other demos. They cross compiled all sorts of databases to get that info.
Mutt doesn't have a fancy UI but it is fast. It has no problem handling the 150k+ in my inbox (mostly unread). I know some people that swear by pine and for all the same reasons. YMMV.