Tuesday, March 13, 2012

PyCon retrospect

Ok, so, this was the first time I've been on PyCon and I must say it was pretty nice.

Initially, it started out kind of lousy for me: United seems to have 'misplaced' my bag and I only got it back in time to check it back to Brazil, so, that sucked. On the other hand, to balance things, I won a Kindle DX in raffle from http://www.truecar.com :)

Mainly, it was awesome talking to so many great names of the Python world... Meeting people face to face does make a great difference (some things are simply not as well expressed in an e-mail).

On the PyDev side, it was pretty nice seeing many people using it while hacking away during the conference and even having some people asking 'how can I help to make PyDev better?'.

I guess I wasn't properly prepared and mostly, my answer was: read the devs guide to grab the code/compile, find an itch to scratch and mail me about it so that I can help you find yourself there... Some things can be done in Java, some in Jython, depends a lot on what you want to do.

Aside from that, documentation-wise, I guess the major issue would be having some section explaining how to configure each major library on how to work with PyDev (most work out of the box, but some need minor adjustments such as adding a token to the forced builtins and some may even require more than that), so, if someone is willing to help working on the PyDev documentation in that topic, that would be a great help (and I guess that if someone doesn't have an itch to scratch and still wants to contribute in code, there are things I can point to that need to be done and are relatively simple to get started).

On the scientific computing side, I liked Numba (https://github.com/ContinuumIO/numba), which seems to be a pretty nice idea... it's still in its early stages, but I think it could be a nice substitute for Psyco (but with knowledge about numpy types and maybe a bit more strict -- if I did understand it properly)... I'd much rather use something as Numba for speedups than Cython (as the Cython code is only 'close' to Python, but doesn't really run on a Python interpreter) and Pypy is just not an option right now...

Although Pypy seemed strong in the conference, I must say that it'll probably be a long, long time until I'll be able to use it in production... I really use lots of code in C/C++ bindings, so, this is a killer CPython feature which I'm not sure Pypy will ever be able to provide (and the 'current' workaround of porting a library to RPython as is being done in Pypy/Numpy doesn't seem to be really feasible).

One thing I thought was a bit strange was the lack of projects with Python in mobile platforms, as I was guessing it should be straightforward to compile Python to Android/iPhone (so, I'm guessing the issue is probably the lack of proper multi-platform bindings on that area). In contrast, Python seems very strong on the server-side and scientific computing fields.

And I think Python 3 does deserve a special note here: I think Guido left it pretty clear (as much of his keynote talked about the subject) that Python 2 is really deprecated, so, although it's currently the production version that's most widely deployed/used, people have to really start getting used to the idea that a port to Python 3 is the way to go -- although in the real world, I still do expect this to take quite a few years (probably more than was initially expected by the Python-core folks). The fact that Guido made this topic such a big portion of his keynote, does make me feel like many of the Python lovers were against this move and the actual response from the community on this respect has been mixed, but regardless of that, the direction that Python-core is going is 100% on Python 3 (maybe doing something here or there to help in easing the port or having a shared Python 2-3 codebase).

And, there are still have some talks I'll see later at: http://pyvideo.org (because many interesting talks took place at the same time).

5 comments:

Python on mobile platforms may be about to get more interesting, but not because of Android. The PlayBook has a complete Python 3.2 install inside, and I'm working on integrating that with the Qt stuff that's also being made a core part of the system. It's a bit soon to point to it and say "tada!" though, but there's lots of room for novel ideas here. (There's actually a Python 2.7 inside as well, but it's used for system stuff and completely locked down, so not accessible to developers in any way.)

The PyPy developers would prefer that libraries get ported to pure Python rather than RPython or interface with the library through ctypes. Parts of Numpy are being ported over to RPython so that they can add special support to the JIT for Numpy arrays. Most libraries on the other hand would not have a need for additional JIT features.

Yes, I do get that they'd like things ported to pure Python/RPython/ctypes, but on my case, there's a big codebase which uses a lot of Boost::Python to interface with C++ already, so, porting that C++ -> Python is definitely not an option, and changing Boost::Python to use a ctypes interface where C++ is used doesn't seem a proper replacement (and there are also many 3rd party pre-requisites, such as proper Qt/vtk bindings). I'm still keeping my fingers crossed in that they'll tackle this sometime in the future -- but I won't be holding my breath until then :)