• Breakfast: yogurt + 1 cup grape juice
• Lunch: one corndog + 1 cup water
• Afternoon: 20 minute workout *
• Dinner: something modest + 1 cup milk

Drops around 1/2 lb per day if I actually do it.  I usually don’t exactly do that, so I’m probably at a 1/4 lb rate right now.  At any rate, 10 down, 5 to go.  Gotta keep my body at least moderately comparable to my blog pics.

For fun, see the Corndog Patrol Flag.

* Usually about 150 jumping jacks, 7 pull-ups, 45 push-ups, and 120 sit-ups.  At a separate time Nan and I walk Cuzco the goat around the lake.

… So I’ve got that tinypy project sort of taking off. It’s got a SOC student (thanks google & PSF) and a bit of interest. So far most of the open source projects I’ve done haven’t generated more than a couple patches — in their lifetime. With that in mind, I’m not entirely sure what is a good way to accept patches and run a project, since I don’t have loads of experience in it. I’m a “solo” dev in my day job as well. I want to do a decent job of managing the tinypy community without having to work too hard.

Do I take whatever people give me and patch it as-is and just figure, well, someone else will fix it?
Obviously not. Especially not for tinypy where “good” and “concise code” is of such large value to the project. And with the SOC coming up, “secure code” is also very important, as well as testing.

Do I be really strict and keep rejecting a patch until it’s “perfect”?
Maybe? I remember submitting a patch to one project ages ago, and it got rejected without much good explanation. I’ve also submitted others successfully. Not quite sure what the balance is.

Do I take the patch and apply it and then fix things up myself?
Maybe? If it is easy to fix … but then again, why should I have to do all the work? I don’t really have that much spare time (all evidence to the contrary.)

How do I grow the project (in general) without it turning into a monster?
Stick to my guns on the 64k code limit*? Maybe not, since things like VC support, security, etc, are going to take up *some* bytes. Not to mention, tinypy could use a few batteries … At the same time, I’ve gotta draw the line somewhere.

Obviously some common sense is needed here, but sometimes I run a bit short on that. Advice / links to good articles would be swell at this point. I could google this sort of stuff, but I think having the context of responses from a community I know would be much more valuable here.

-Phil

* on that point, I think having the 1.0 source always in the “featured downloads” might be a good idea. Even if the project gets bigger, people can still check out the “classic version.”

For example, (at present) tinypy doesn’t have support for decorators.  I’ve always liked decorators, so I made this code (a zip of main.py, deco.py***, and test.py) so that if you have a main.py:

import deco
import test

When the deco module is loaded, it cleanly**** adds decorator support into the tokenize, parse, and encode modules of tinypy.  Then when the test module is loaded, it is able to use decorator syntax.  Yay!  This mostly thanks to the top down operator precedence implementation in tinypy.

So now, if say, you have some crazy idea for how the $ operator should be used in bigpy, you can go ahead and use metaprogramming to add it into tinypy and show all your friends how awful your new syntax looks and have a working proof-of-concept!  Yay!

* feel free to enlighten me
** it’s got a mailing list now, join in on all the fun!!
*** only 611 bytes :)  They were pretty simple to implement, since they really just mean: “given ‘@a \n def b …’ do ‘def b … \n b=a(b)’”
**** Since all the language features are stored in dictionaries, it’s “pretty easy” to add new symbols / operators.  (Or remove features, or whatever!)

• linux (LAMP stuff)
• e-mail server
• has excellent uptime
• can manage backups
• has excellent support
• can manage security
• is able to deal with a crisis (say, a backhoe digs up their fiber, they are able to get your server running somehow within half a day)

Which I suppose aren’t really extravagant demands, but anyway .. I’d appreciate any recommendations you can offer.  The hosting is for a U.S. based company, so we’ll want a host with data centers here.

Please don’t bother responding with a rec if you haven’t personally been with said host for at least 3 years.

Yep, that’s python+pygame alright ..

If you’re interested in tinypy in any way, be sure to go to the site then navigate to the google group from there and join in the fun.  I suppose I could have direct links from this post, but then you’d miss out seeing my new swell site

Share and enjoy!
-Phil

Anyway, my options are as follows:

• use the project management software I’ve written for my health-care company. Pros: I wrote it, so it must be better than anything else. Cons: I’ll have to maintain it when I find out otherwise.
• use google code. Pros: People know how to use it, and it’s pretty clean looking and they host it for me. Cons: I don’t get to host it. But I guess I could set up the first few pages of the tinypy site on my own server to make myself feel good.
• use trac or something. Pros: I’d get to host my whole project myself. Cons: I’d have to host the whole project myself and learn some new software and maybe set up some stuff.

So .. all my aimless thoughts aside, since this isn’t really about me. (If it were, I’d just blog about it every now and again and leave it at that.) It’s about you, since there is interest in the project it needs to be easier for people to poke at. What setup do you think* would be the best?

* it probably doesn’t matter what you think, because after writing this post, I think I’ve already made up my mind. Writing down stuff like this helps me think things through. But since you’ve bothered to read this far, you might as well put in your 2c.

Reasons to become a SOC-python-tinypy mentor:

• you want to help out tinypy - if multiple projects get accepted, it would be great to have some people helping me out!  I don’t think I could mentor them all.
• you want to help out python - the more mentors python has, the more projects will be sponsored :)  This will increase the odds that tinypy gets some slots.
• you want to help out students - this is the Summer of Code, after all!  It’s a great opportunity to help new coders get some great experience.
• you want to help out open source - the SOC gets students involved in Open Source :)  Several of the students who have contacted me say this is the first time they’ve been interested in Open Source.

Qualifications for mentors:

• you aren’t a student.
• you know python and C reasonably well.
• you want to help out!

How to join:

• contact me, so I know who wants to be a tinypy mentor.
• join the python mentor’s mailing list.
• join the Google SOC mentors as part of the PSF.

Thanks!
-Phil