Clarification of the Python requirement

blakeohare on 2013/07/26 23:32

The rules state:
- Entries must run using the latest version of Python
- Supporting frameworks and libraries written in other languages may be used

However, it does not specifically say that the original authoring of the code must be in Python. I seek clarification because I've been debating whether or not to create a programming language that can be parsed and reserialized to both Python+PyGame or JavaScript+HTML5, so the final submission for PyWeek would be Python+PyGame, but then I could also post an identical version of my game in JavaScript on my website. 

What are people's thoughts on generated Python? Technically it still follows the rules, but I'm wondering if people consider it still in the spirit of the competition. 

Also, holy short notice, batman! If I were to create such a thing, I'd have 6 days to make and document it, otherwise I'll have to wait for the next challenge. 

(log in to comment)

Comments

richard on 2013/07/27 07:26:

Hm. That's a tricky one. I'll have a think about it...

BTW, are you aware of the Python -> Javascript translators? If you used one of those all you'd need is the pygame -> html5 part...

blakeohare on 2013/07/27 07:59:

I am aware of their existence, but considering the structure of PyGame and JavaScript events are quite different (manually pump event queue vs handlers and timeouts), it seems like a translator without the context of PyGame would only get me part of the way there and there would be an immense amount of finagling. On top of that, the implementation of the pygame modules as html5 equivalents would be a huge bulk of the work anyway such that the translation itself wouldn't buy me too much to begin with. And without type context, I'd be mistrustful of the guesses a converter would make. (JavaScript doesn't automatically do integer division the way Python does, but does automatically convert non string values to strings for string concatenation, to name a few of the differences that are hard to distinguish without a programmer's context). 

Also, I create programming languages for fun about as often as I create games, so creating such a thing isn't too much work for me. 

richard on 2013/07/27 08:28:

If events are an issue then consider pyglet and the pyglet-alike thing for javascript just posted to this board?

blakeohare on 2013/07/27 10:18:

They are only an issue when the converter does not have context of the game loop, which general-purpose translators will not. However, I am avoiding generic translators for the other type-based reasons as well. My proposed solution for this is to use a model where the main method registers an update and render method which Python/PyGame would call in series between event pumping, and javascript would call via a timeout. Not a huge hurdle.

As far as the PyGame vs Pyglet library goes, I already created a js file that implements quite a bit of the major functionality of PyGame some months ago for use in other projects, so I'm actually good to go on that front. 

blakeohare on 2013/07/29 05:27:

Since this was the last weekend before the 30-day deadline and if I had any hope of finishing this, I went ahead and started making it. I was hoping to finish a working prototype before the weekend was over and it looks like I actually managed to pull it off. Whether it ends up being allowed or not, it was still super fun to make and works super awesomely. Also I haven't really created a strongly typed programming language before and it was a fun excuse to. I'm calling it PajamaLang: Python + JavaScript --> P + J --> PJ? no? okay...anyways...

Here's a JavaScript version of a demo game I made using PJ:
http://blakeohare.com/projects/pajamapyweekdemo/
Tested in Firefox, Chrome, and Opera. IE doesn't work, like always. Will work on that.

Here's the PyGame version of it:
http://pastebin.com/mFFm7NZ0

And here's the original PJ code that generated both of the files above. The only tweak needed to switch between the two languages is a command line flag in the translator app. NO POST-EXPORT TWEAKS!
http://pastebin.com/RqLnA8rL

PJ is strongly typed, so even without the benefit of exporting to JavaScript, it still gives you the benefits of type checking at compile time which is always useful for larger projects. 

I'm going to keep chugging away at this. If anyone is interested in testing it out, it should be ready for public consumption in a day or two.