So .. who thinks flash + Galcon = win?  I don’t know yet, but I’m giving it a try.  I’m not actually developing the flash version.  An awesome friend of mine has been doing the time on this one.  Though I’ll probably be doing the LAMP end of the deal.  At present the game is non-networked, but we’re been considering the possibilities.  A TCP/IP edition of the game could be made, but I wonder if that would end in tears.  TCP/IP isn’t ideal for gamedev IMO.  Flash doesn’t support UDP as-of-yet.

This isn’t the first time Galcon has reared it’s head from within the browser window.  (See my earlier blog posts …)

I haven’t decided exactly what I’m going to do with this once it’s completed.  Probably a few things.  Throwing it on facebook is an obvious one.  Throwing it on galcon.com is another one.  Maybe mixing it with something like The Maze of Madness is another one.  Or maybe something else!

One idea that I have that would be really cool would be if the tinypy vm were ported to ActionScript using Alchemy* .. and then somehow people would be able to script Galcon on the web and share it with their friends..

*I don’t know if you caught that .. but I think my weekend just got booked

Alas, I’m not going to be able to make PyCon this year .. Because I’m a finalist in the IGF Mobile competition  And the GDC is happening the same week as PyCon.  Oh well, can’t do everything.  I wish I could go to both, PyCon was a blast last year!

That said, some of us tinypy folks might do a tinypy sprint at the same time as the PyCon sprints.  So if there are any people at PyCon who want to sprint on tinypy, get in touch and we can all work together in #tinypy somewhere.  Further news about this sprint will be available in the tinypy mailing list.

tinypy has progressed a bit since I last posted about it.  It’s probably sandboxed and it now has meta methods.  If there are some serious smart VM coders who are interested, we could use a hand.  tinypy is as fast as python for some tasks, but for other things it is around 1/2 the speed of python.  It also uses more memory than python.

Hey,

So .. I’m thinking about proposing a talk about tinypy at pycon.  Not quite sure what I’d want to say about it.  So, here’s my “ask the web” question:

What do you want to hear me talk about tinypy?

I could talk about anything from how I made it, why I made it, what good it is, how to use it, to .. err .. I dunno.  Whatever

If no good talk ideas come together, I’ll probably do a lightning about it again, and maybe an open session.

I also want to do a Galcon tournament of sorts again at some point :)  That was great fun last year!

-Phil

I’ve learned a lot about python by implementing tinypy. Today I was thinking over my re-work of classes, objects, and inheritance in tinypy (not in trunk yet). I noted how in tinypy, I will be able to change the class of an object via a function call (a-la lua):

class A: pass
class B: pass
x = A() # x is an instance of A
setmeta(x,B) # x is now an instance of B !!!

So I thought to myself, I wonder if python can do that. Well, it can, and as per usual, its solution is quite elegant:

class A: pass
class B: pass
x = A() # x is an instance of A
x.__class__ = B # x is now an instance of B !!!

So, lesson of the day — you can dynamically change the class of an object in bigpy. Which, actually, I’ve sometimes wanted to do, I just didn’t realize I *could* do it.

Man, could I have even thought of a title that sounds dustier? It just screams “Get ready for the boring lecture of the year folks.” I should totally re-name this post to something like “putting your brain through a blender .. FOR FUN!” Or maybe I should have gone the pretentious route and named it something like “Analysis of modern programming meta-method paradigms.” Actually, that sounds even dustier than my original title. At least my original one falsely implies that there is some competition going on in this post by my use of the “vs”.

Here’s how python does it:

class X:
    def __get__(self,k): return “OK”

Here’s how tinypy does it:

class MetaX:
    def __get__(self,k): return “OK”
class X:
    def __init__(self): setmeta(self,MetaX)

Okay .. so .. the python way is WAY more readable. Nice So let me remember if there was a good reason for doing it a different way in tinypy … I think the answer is “maybe” ? Here’s what I can come up with:

• In tinypy dict == object, which means a.x == a['x']. (I’m not sure how that’s relevant, but it does mean that I have no need for a __getattr__.)
• lua does it that way! (I have copied many other lua design decisions, so why not copy another!)
• It’s faster? (In a sort of, if only tinypy were as fast as python is to begin with kind of way.)
• It was easier to hack together in an afternoon! (Well, actually .. looking at the python code, I think the python way might have been easier.)
  

So what did I gain by going the lua route instead of the python route? I’m not entirely sure .. but it sure seemed like a good idea at the time.

A few days later …

With a bit of effort, I’ve come up with a few more reasons why I did this in tinypy:

• Not only are dicts objects but they can also be classes. This is done by having a __call__ meta, so if you have class X: .. X() calls getmeta(X).__call__. This is relevant because if the class itself had a __call__ method, how would you define your class so that it knows to create your object with a __call__ method? (Probably by having a __new__ method that isn’t copied to the object.)
• The one way the previous point is relevant, is that the object __new__ would probably have to be smarter than how I create objects currently. It would have to realize that __new__ methods don’t get copied into objects.
• Also, I would probably have to internally track what is a class vs what is an object. So I know when I do something like X.test(self) .. and my class X has the unbound method of __get__, it knows not to try any meta magic.

Okay .. those aren’t great reasons. The nice thing about tinypy being .. tinypy .. is that if this continues to bother me for the rest of the day, I can probably try out the implementation in a couple hours. If you want to see the current meta implementation, it’s in subversion.

Anyone care to comment on the whole lua vs python style meta-methods stuff? I’m pretty sure I’m not sure at all what I think about them!

Here it is: http://tinypy.googlecode.com/files/tinypy-1.1.tar.gz

tinypy is a minimalist implementation of python in 64k of code.  If you want to get involved, be sure to join the mailing list!

Thanks loads to everyone (allefant, Seth, Krzy, Rockins, Dean) who helped get this release together

The highlights are:

- works in VS now
- math module
- better setup.py
- a million bug fixes

Enjoy!
-Phil

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

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

So I’m getting the feeling I should host tinypy somewhere greater than just in my blog. What a pity, the blog suited me so well. I dunno, I guess some people have unreasonable demands. (If I were feeling clever, I’d link all the words in that last sentence to other people’s blogs who’ve bugged me about this. But I don’t think there are actually that many.)

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.