If I were going to OSCON, I’d certainly go to this talk. But I’m not planning on it, so …

… 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 the sake of this post, I’m going to pretend to know what metaprogramming* is.  Yeah, so tinypy** totally has that.  At least, since the parser and compiler in tinypy is written in tinypy, you are able to modify those modules on-the-fly and add new features into the tinypy language.  (Not that you’d want to, but certain other languages get so uppity about being able to do that, I figured I’d plug for tinypy here.)

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!)

$ history|awk ‘{a[$2]++} END{for(i in a){printf “%5d\t%s\n”,a[i],i}}’|sort -rn|head
269   ls
253   cd
182   kate
50   cp
48   svn
43   mkdir
23   mv
21   grep
16   gqview
13   python

A client of mine hosted with cihost recently had an outage.  (Which hasn’t ended.)  They want to move their dedicated server elsewhere.  Any suggestions?  I’ve done plenty of googling for stuff, but really, personal rec’s carry way more weight for me.  We want a host that:

• 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.

1. The only bit I remember from that conversation is all the stuff about Canadian global domination.  Let me tell you, if Mike Fletcher has his way, we’re doomed!  (Maybe we’re doomed either way, but be sure your passport is ready when we have to head north!)
2. I remember peaking into the pycon-dev room at one point and Doug was giving a lecture on menu structures in websites.  He said the pycon navigation was stored completely independently of all the modules used by pycon.  I think that’s great.  I’ve been thinking about it ever since.
3. I do most all my dev at home on my linux system.  My laptop last year was loaded with XP and I found it painful to do work on at pycon.  So this year, the day before pycon, I loaded it up with Ubuntu.  Which was a mistake.  It *sort* of worked, in a kind of the network didn’t exactly always work and the video driver didn’t always work .. and then it got worse .. but I won’t name names 😉
4. Which brings me to two happier points, which are points 5 and 6 in this list.
5. Sean was quite swell and set me up a personal hard-line during the sprints when I needed to get some work done :)  Yay!
6. I was told about PyPE, which is a nifty python editor for windows :)  I’m having to do some win32 dev lately (see previous post), so having that on hand is great!  I like it.  I was able to do about 5 hours of dev on it this evening, and I think the main complaint I had was I was using a laptop keyboard.  If you like kate, this is the editor for you.

Hmn .. maybe someone did ..

Yep, that’s python+pygame alright .. 🙂

Yay!  Go to tinypy.org and spend the rest of your day basking in the glow of the new tinypy website!  Yipee!  Thanks to everyone who told me not to re-invent the wheel on this one.  I spent a large bit of the week thinking about doing that, but eventually I gave up the idea because I was feeling kind of worn out.  So I just threw together a google code and google group and slapped a website in front of it all.

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