This month we will meet to watch/present some lightning talks and to talk about our participation at the Fórum Internacional de Software Livre (FISL 10).

The meeting will be hold at the SP HackLab, May 23. More details (in pt-br): GruPy-SP wiki.

See you there

After finding out that rbp, lhonda and Luiz Irber (friends from our local Python User Group) were attending too I thought that it’d be a nice event. At least we could talk about GruPy-SP plans…

Anyway, I went to the hotel and after watching the three presentations (speaking about Nokia Serie60, Python and mobile development) the fun really started. 4 hours to develop the coolest mobile application in the world

The prize was two E71 (the “new” Nokia Smartphone) for the “winner” application, so we decided to code in pairs. Me and rbp, after talking about our ideas, decided to write a musical instrument using the N95 accelerometer.

The first two hours of “development” actually we spent trying to find a proper way to transfer files to our cellphones (the S60 SDK is Windows only…). Then, with the “bluetooth easiest method” for transferring the app working, we started trying to find out how to interpret the accelerometer data. It worked as expected. Then we needed to play a sound (as it was a musical instrument). Easy, Python for S60 is very intuitive, the API is very High Level. Looking to the reference guide there was something like:

from audio import Sound
Sound.open(“file.mp3″).play()

Just as I expected… except that there wasn’t any sound coming from the freakin’ phone’s speaker. There was forty minutes left to the end of the competition and all we had was a soundless musical instrument, not very useful.

Ok, plan B. I started looking to some old code in my N95 and found a bluetooth webcam prototype. Rbp had an idea of making the webcam “crash” with a movement (using the accelerometer). And then we made it.

It’s a funny application and, as I said to rbp, as programmers we are great comedians. We presented the webcam in the stage and people seemed to like us (the app or the comedians? I really don’t know )

Well, me and rbp won a Nokia E71 (each), it’s a very nice (and THIN) smartphone, I don’t like phones with qwerty keyboards, but this one is really cool (thin, small and almost comfortable to type).

Thanks Forum Nokia!

Some notes on day two:

• In São Paulo we had two lighting talks before the “official” conference. João (JS) talked about a little script he wrote that uses PyGame to display text from a .txt file in a presentation format. Rbp explained a bit about 2to3 (the Python 2.x [actually x equals 6] to Python 3 conversion tool) and showed some examples.
• First talk. Mark Ramm had some good points. Specially, IMO, about making Django more modular, which means that each part of it doesn’t depend on other parts of the framework. As an example, you can choose to use the Django ORM without using Django. But, please, don’t make it a lot of little packages that you need to grab together to start using the framework. One of the nice things about Django is that it’s simple to start using it (install one package and then django-admin.py startproject)
• Official lighting talks. As always, a great moment on any Python conference. Lots of curious and interesting stuff (and other stuff not so interesting… or not interesting at all [for me, obviously]). Funny moment: People, don’t use GMail over HTTP, there IS HTTPS support
• Schema evolution, three options: DMigration, South and Django Evolution. There are a lot of doubts about each one and I think I need to test all of them to choose one (and hope that they start collaborating to each other and make something really good). But it’s great to see that there is people working on that.
• Last talk was Django’s Future by, obviously, Jacob and Adrian. It was more like a chat between them. Some good ideas and discussions. Then they received questions/requests/suggestions from the public. Things like, dropping old python versions support, python 3 support, documentation, debugging tools, etc. I think that some suggestions/requests were really nice and I hope that Django developers (and the community) take them seriously. This was a great opportunity for developers to receive feedback from the community (users).

That’s it for 2008. Again, I’d like to thank Rodolpho and Google for making it possible to attend to DjangoCon from São Paulo. Congratulations to DjangoCon organizers and to the Django community!

And, of course, thanks GruPy-SP people

Pictures: Rbp’s DjangoCon set @ Flickr

It was 11p.m. Almost sleeping in this blue big puff

Some notes on the first day of event:

• I expected more news from GvR on his talk about GAE (nothing really new).
• David Cramer talk about High Performance was kinda heavy (but good things learned)
• The history behind Django is hilarious (State of Django by Jacob and Adrian)
• It seems Django is getting bigger (contributors) and better (features). Good!
• Really good talk by Malcolm Tredinnick about the Django ORM
• GeoDjango seems very interesting, but it’s not for me (at least now…)
• Cal Henderson made good “feature requests” and “bug reports” live, the unreadable SQL generated by Django scares me a bit… but not that much

In general it was great. I can’t wait for the lighting talks tomorrow (probably the best moment on any Python conference ).

Oh, the snacks @ Google (Sao Paulo) are awesome!

It’s really easy and obvious (it’s always easy and obvious with Python and Django).

First, you’ll need the admin.py file in your app directory.


from django.contrib import admin
from myproject.myapp.models import MyModel

admin.site.register(MyModel, MyModelAdmin)


The add_view method is called when you try to add an entry using the admin. There are other interesting methods you should look too, for customizing the admin behavior (change_view, delete_view, etc).

Another way to customize things is to write your own ModelForm, but it’s beyond the scope of this post

Thanks to Google (I think specially to Rodolpho) DjangoCon will be transmitted to Google’s Office in São Paulo while the conference is held in Mountain View.

Cool

I’m definitively going! So, Saturday and Sunday (September 6th and 7th) @ Google’s Office, see you there!

So, if you are in Brazil or planning come near September 18th, 19th and 20th, don’t miss the chance to meet the awesome guys from Python Brasil community

Some finished tasks:

• throw() method on generators
• close() method…
• faking 2.5 behavior for IMPORT_NAME and IMPORT_FROM opcodes
• changing the default value for magic attribute of PyCode objects
• changing the magic number that goes in .pyc files compiled by PyPy
• fixing tests and more tests…

From those changes the only one I would like to comment is the change of both magic numbers.

First, they have different values and meanings in PyPy. The magic number for .pyc files (defined in pypy/modules/__builtin__/importing.py) is the number that identifies the bytecode “version”. It’s used to know if the interpreter should use the .pyc file or should recompile the .py. PyPy’s value is different from CPython’s one. As we are changing some opcodes (as IMPORT_NAME, mentioned before) this number had to be changed. The old value in PyPy was 1024 (or 1024 + 2 or 1024 + 4 or 1024 + 2 + 4, depending on some command line options), the new value is 1034 (or ….). We are just using the same policy CPython uses to change the value, add 10 to the old value.

Now the PyCode magic attribute. This value is the CPython magic number (the one explained above)., the old default value was the value from CPython 2.4 (62021). Some checks against this value are made through the code to decide if the bytecode should be interpreted one way or another. One example is the IMPORT_NAME opcode. In Python 2.4 IMPORT_NAME did not have the level parameter, this parameter is new in 2.5 because of the absolute import feature. So if the bytecode represented by a PyCode object is 2.4, when we visit a import statement we should not try to pop the level value from the stack (because it’s not there), but if it is 2.5 we should! So we check the magic value. The problem is, the default value was 2.4 but we changed the opcodes to behave like 2.5, so those checks were not working. The solution was to change the magic default value to 63231 (2.5c2 value I think), so now our bytecode interpreter is (almost?) compatible with 2.5 bytecode. And our compiler is generating 2.5 compatible bytecode as well.

To go to the Round 1 the coder just needed to achieve 25 points. For each problem there were two kinds of input, a Small and a Large one, the correct answer for the small input counts 5 points and the correct answer for the large input counts 20 points, so the only way to go to Round 1 was solving at least one problem for both inputs. I did it for problems A and B. Of course I’ve solved them using Python

Problems.

The first problem was to minimize the number of switches a central engine should make between multiple search engines. You receive a list of search engine names and a list of query, each query is the name of a search engine. The search engine shouldn’t search for itself or the universe will “implode” (or something like that ). Well, the basic way to solve this is to always switch to the last next engine in the queries list.

The second problem was to optimize the number of trains that should be in station A and in station B at the start of the day. This given the time that each train leave A and reaches B (and vice-versa). My solution here was to create a list of coming trains (actually of time that the train would be prepared to leave) for each station and then popping out them when a train that should the station leaves after one came (so you reuse the train).

Well, that’s it. Now let’s get ready for Round 1

Today I’m working on PEP 342 – “Coroutines via Enhanced Generators”. I’ve finished to implement the .send() method and all the stuff it should do “behind the scenes” (e.g. push the value into the frame stack).

Last week some other PEPs and small changes were supported as well.

PEPs 308 (conditional expressions) and 343 (with statement) were already supported, I just needed to write tests and remove a SyntaxWarning for conditional expressions. PEP 352 (BaseException and raise “string”) is now supported as well.

Some changes were made to Grammar2.5 because pyparser could not read it the right way. Those changes were already present to Grammar2.4. The main problem is that when the parser finds a rule that has alternatives (like, ‘is’ | ‘is’ ‘not’ ) and the first alternative matches (imagine it trying to match ‘is not’, it will match ‘is’) it doesn’t look for the other alternatives and then fails (because there is no rule that matches a ‘not’ after an ‘is’). The solution in that case is to change the order (which doesn’t make much sense, before looking the parser’s code), so the rule should be ‘is’ ‘not’ | ‘is’.

Next steps: check PyCode magic number and finish PEP 342