Roberto Alsina: FLOSS Decision Making in Action


If you are rea­ding this the­re is a good chan­ce you are in­vol­ved so­me­how in open sour­ce de­ve­lo­p­men­t, or so­ftwa­re de­ve­lo­p­ment in ge­ne­ra­l. One thing lo­ts of peo­ple ask me when they know I ha­ve lea­d ­this sort of pro­jec­ts for a long ti­me is "how do you de­ci­de things?". To whi­ch I ha­ve all sor­ts of bad an­swers like:

  • "I­t's a con­sen­sus thin­g"
  • "It ha­ppens or­ga­ni­ca­ll­y"
  • "So­me­ti­mes it just ha­ppen­s"
  • "A­nar­ch­y!"
  • "You do what you do"

So, now he­re I ha­ve an AWE­SO­ME exam­ple of FLO­SS de­ci­sion making in ac­tio­n, whi­ch is ... all of the abo­ve.

So­me con­tex­t: Niko­la is a sta­tic si­te ge­ne­ra­to­r, so it deals wi­th rea­ding and wri­ting tex­tual da­ta from disk. I­t's al­so an in­ter­na­tio­na­li­zed pro­jec­t, whi­ch su­ppor­ts mul­ti­lin­gual si­tes and trans­lated da­ta. It al­so run­s un mul­ti­ple pla­tfor­ms, like Win­do­ws, OS­X, Li­nu­x, etc.

And to make that mo­re fun, it al­so wo­rks on Py­thon 2.7, and 3.3 or la­te­r. Whi­ch means it has to hand­le two­ ­di­ffe­rent mo­dels on how to wo­rk wi­th uni­co­de da­ta, in the sa­me co­de­ba­se. And tha­t's not fun. So, we ha­ve be­en ­floa­ting around the idea of de­pre­ca­ting py­thon 2.7. And so, when s2h­c_­johan wa­lks in wi­th a uni­co­de ­pro­ble­m...

14:23:16 <s2hc_johan> I don't have a site with sections, but I tested it for the other case
14:35:42 <s2hc_johan> strange it worked for a while broken again, probably because I've got åäö in it now.
14:35:45 <s2hc_johan>
14:36:17 <s2hc_johan> if you wrap data with unicode it works, but I'm not sure that works in python3
14:36:37 <ChrisWarrick> s2hc_johan: how do you wrap it with unicode?
14:36:48 <s2hc_johan> unicode(data)
14:37:05 <s2hc_johan> but is that valid in  python3?
14:37:11 <ChrisWarrick> s2hc_johan: this is wrong on so many levels
14:37:16 <ChrisWarrick> s2hc_johan: please don’t do that, ever
14:37:48 <ChrisWarrick> s2hc_johan: This won’t work in Python 3 either.  You must have an actual encoding, and use the decode method.   try: foo = foo.decode('utf-8'); except AttributeError: foo = foo  # python 3
14:38:02 <s2hc_johan> what do you mean, that is like my standard when I get strnage data in, undoce(data) data.encode(whatever) data.decode(whatever) :)
14:38:23 <s2hc_johan> one of them ussually work
14:39:22 <ChrisWarrick> s2hc_johan: unicode() assumes ASCII, it never works right
14:39:32 <s2hc_johan> true
14:39:40 <ChrisWarrick> s2hc_johan: encode/decode with a specified encoding is fine
14:40:00 <ChrisWarrick> s2hc_johan: but you might need a try/except for Python 3 if it could have Unicode data already
14:40:16 <s2hc_johan> I'm a bit confused in this case since the output comes from json.dumps
14:40:34 <s2hc_johan> thought that would produce a unicode object
14:40:51 <ChrisWarrick> s2hc_johan: not necessarily on python 2
14:41:05 <ralsina_> if isinstance(thing, utils.str_bytes): thing=thing.decode('utf8')
14:41:15 <ralsina_> that works in py2 and py3
14:42:12 <ChrisWarrick> easier to ask for forgiveness imo
14:43:07 <ralsina_> maybe we should have helpers in utils enforce_unicode and enforce_bytes
14:43:13 -GitHub[nikola]:#nikola- [nikola] Aeyoun pushed 1 new commit to feed-previewimage:
14:43:13 -GitHub[nikola]:#nikola- nikola/feed-previewimage 4b79e20 Daniel Aleksandersen: Deprecated RSS_READ_MORE_LINK and RSS_LINKS_APPEND_QUERY...
14:44:58 <Aeyoun> Or upgrade to Py3.
14:45:11 <ChrisWarrick> ++
14:45:47 <Aeyoun> Unicode in Py27 is a nightmare. It tries as hard as it can to kill you at every turn.
14:48:09 -travis-ci:#nikola- getnikola/nikola#6426 (feed-previewimage - 4b79e20 : Daniel Aleksandersen): The build is still failing.
14:48:10 -travis-ci:#nikola- Change view:
14:48:10 -travis-ci:#nikola- Build details:
14:48:27 <ralsina_> ok, let's consider py3-only seriously.
14:48:40 <ralsina_> 1) Is there any distro commonly used with py3 < 3.3 ?
14:48:55 <ralsina_> 2) Do we just stop using py2, or we deprecate slowly?
14:49:15 <ralsina_> 3) Do we just start doing py3-only code, or we actively de-hack the codebase?
14:49:21 <ralsina_> That's my 3 questions :-)
14:50:13 <SteveDrees> Unicode is a nightmare
14:50:53 <SteveDrees> different python versions just changes where the pain point is
14:50:53 <s2hc_johan> which one is better isinstance... or hasattr('decode', ..)
14:51:02 <ralsina_> isinstance
14:51:08 <s2hc_johan> oki then
14:51:10 <ralsina_> hasattr is evil in itself
14:51:26 <s2hc_johan> just going to feed the kids then I'll make another pr
14:51:28 -GitHub[nikola]:#nikola- [nikola] Aeyoun pushed 1 new commit to feed-previewimage:
14:51:28 -GitHub[nikola]:#nikola- nikola/feed-previewimage 4c950ac Daniel Aleksandersen: flake8
14:52:13 <Aeyoun> ralsina_: user survey? pip download data?
14:52:33 <gour> ralsina_: create some poll at website/mailing-list about it?
14:53:18 <ralsina_> dude, I offered free shirts and I got only 10 requests ;-)
14:53:30 <ralsina_> so, how many answers do you expect about that sort of thing?
14:53:43 * gour thought shirts are jsut for devs :-(
14:53:47 <Aeyoun> ralsina_: release a unchanged version on pip that is flagged as py3 only. see how many downlaod it versus previous version in same amount of time.
14:53:51 <ralsina_> gour: go add yourself dude
14:54:18 <ralsina_> gour: TO THE SHIRT LIST! I just notced that sounded very rude :-)
14:54:43 <gour> ralsina_: where it is?
14:54:43 <Aeyoun> ralsina_: or one py27 version number and and one version py3 only version number at the same time.
14:55:17 <ralsina_> gour:
14:55:17 <gour> found it
14:56:00 <gour> ralsina_: wonder if xxl is too large or xl is enough
14:56:00 <Aeyoun> ralsina_: american or european sizes by the by?
14:56:03 <ralsina_> Aeyoun: that reflects how many people use py2.7 by reflex. I know *i* do because it's "python" and not "python3"
14:56:20 <ralsina_> Aeyoun: no idea about sizes to be honest... probably american
14:56:21 <Aeyoun> American sizes are … a big bigger. I’m probably a XS/S american but M european. :P
14:56:28 <Aeyoun> *bit bigger
14:56:39 <gour> ok
14:56:57 * gour submitted request
14:57:17 <ralsina_> So, what I would prefer to do is make people use py3 if they can. And it seems to me that pretty much everyone can, regardless of whether they still use py2 by defect.
14:57:26 <ralsina_> by default*, spanishism leaked there.
14:57:52 <ChrisWarrick> technically, using py2 is a defect
14:57:59 <ralsina_> So, if we all agree that most users *could* run nikola in py3... then let's do it.
14:58:02 <Aeyoun> Agreed.
14:58:15 <gour> sites won't stop working :-)
14:58:26 <Aeyoun> ralsina_: act on data not dev agreement?
14:58:42 <ChrisWarrick> guess we could change our docs/webiste to highlight 3.x
14:58:59 <ralsina_> Aeyoun: the only data we'd need is to know how many people have py2.7 and no py3.3
14:59:14 <ralsina_> not how many are *using* 2.7 instead of 3.3
14:59:38 <ChrisWarrick> micro-survey via ml?
14:59:39 <ralsina_> How about: let's announce that, unless lots of people complaint, we deprecate py2 by end of october
14:59:45 -travis-ci:#nikola- getnikola/nikola#6429 (feed-previewimage - 4c950ac : Daniel Aleksandersen): The build was fixed.
14:59:46 -travis-ci:#nikola- Change view:
14:59:46 -travis-ci:#nikola- Build details:
14:59:47 <Aeyoun> Mac is shipping with Py2.7 and no Py3. BUT MacPorts and Homebrew offer painfree Py3 installs.
14:59:58 <ralsina_> ok, mac is a good point
15:00:25 <ChrisWarrick> it’s not like we have Homebrew/MacPorts/Fink-based install instructions for them…
15:00:27 <Aeyoun> ralsina_: we could add a deprecation message every time `nikola` is run and ask people to bitch in a bug?
15:00:32 <Aeyoun> ChrisWarrick: hehe. ;)
15:00:50 <ralsina_> "I see you have python3 installed but I am running on 2.7 ... dude, what's wrong with you?"
15:00:51 <Aeyoun> Or maybe once per 24 hour rather  than every time its run.
15:01:00 <ralsina_> doit timed tasks :-)
15:01:12 <Aeyoun> ralsina_: "Don’t get in the way of progress! Upgrade to Py3 and save a developer’s mind today!"
15:01:32 <ralsina_> "niec unicode you have there, would be a shame something happened to it.. switch to python 3!"
15:01:39 <ChrisWarrick> ralsina_: hey, let’s start with a Google Docs survey on the ML.  One question: what Python version and OS are you using for Nikola? 2.7/3.3/3.4/3.5; Windows/OS X/[other: linux/bsd distro]
15:01:57 <gour> "Free t-shirt foreveryone switching from py2.7 to py3.3"
15:01:58 <ChrisWarrick> ralsina_: Just don’t require a Google account like you did last time.
15:02:00 <ralsina_> Second question: "Do you have python 3.3 or later installed?"
15:02:03 <Aeyoun> How much code can be removed with dropping Py27? Lowers maintenance cost and increases performance. That is also an important datapoint.
15:02:11 <ralsina_> ChrisWarrick: I needed to know who was asking for the shirt :-)
15:02:21 <ChrisWarrick> ralsina_: good point
15:02:25 <ralsina_> Aeyoun: not all that much, really
15:02:47 <ChrisWarrick> Aeyoun: it would need to start with a huge rewrite to remove all of our pointers in nikola.utils
15:03:00 <ralsina_> Aeyoun: there are a number of tiny hacks, which were a pain to get right but they always amount to one if and/or one decode :-)
15:03:26 <ralsina_> We can just turn a bunch of helpers in utils into noops
15:04:52 <gour> py3-only nikola is going to become v8?
15:05:15 <Aeyoun> gour: seems like a likely outcome. you’re following the discussion live.
15:06:34 <ChrisWarrick> if we do v8, we’ll have to merge the early tasks garbage
15:07:03 <ralsina_> Is it technically backwards-incompatible if we just stop working on py2.7?
15:07:21 <ralsina_> gour: welcome to open source software: behind the code.
15:07:30 <gour> ralsina_: :-)
15:07:35 <Aeyoun> Someone call in a documentary crew!
15:07:43 <ralsina_> Aeyoun: we have logs!
15:07:51 <Aeyoun> Oh, wait. This is already logged for prosperity.
15:07:57 <ralsina_> I am totally posting this somewhere as "this is how decisions are made in FLOSS"
15:08:40 <ralsina_> Ok, who creates the poll and who posts it in the blog, and who makes sure it appears on planet, and who sends it to the list?
15:08:49 <ralsina_> I would do it but I have work to do :)
15:08:51 <ChrisWarrick> ralsina_: I’ll do it
15:08:57 <ralsina_> ChrisWarrick: you rock dude!
15:09:01 <ChrisWarrick> ralsina_: should be really simple
15:09:03 <ralsina_> Ok, we have a plan!
15:09:17 <ralsina_> Let's consider the poll results in ... a week?
15:09:25 <Aeyoun> Let the logs show we’re all in favor of this plan of action. ;-)
15:09:29 <ralsina_> aye
15:09:51 <ralsina_> Also: can I do the "shame on you" thing on nikola build? It sounds like fun :-)
15:10:27 <ChrisWarrick> ralsina_: for the python version question: radiobox vs checkbox?
15:10:28 <gour> ralsina_: you can mention that Nikola (Tesla) was always for innovation ;)
15:10:44 <Aeyoun> "You’re using FIVE YEAR OLD SOFTWARE. Update your system."
15:11:00 <ralsina_> Aeyoun: I am totally getting at least 5 different comments there
15:11:01 <Aeyoun>
15:11:05 <ralsina_> ChrisWarrick: checkbox... maybe 2?
15:11:23 <ralsina_> ChrisWarrick: one for python version, one for operating system
15:11:32 <ChrisWarrick> ralsina_: ?
15:11:38 <ralsina_> ChrisWarrick: two questions
15:11:54 <ChrisWarrick> ralsina_: there will even be three questions (py2/3 used, OS, has py3)
15:11:57 <ChrisWarrick> ralsina_: and checkboxes it is
15:12:02 <ralsina_> right
15:12:05 <ralsina_> awesome
15:14:44 <ralsina_> Copied / Pasted for posterity

The­re you go, half an hour la­te­r, we ha­ve a plan to (ma­y­be) de­pre­ca­te it.

Now go vo­te he­re: Should Niko­la su­pport py­tho­n2.7? Gi­ves us da­ta to de­ci­de!

Juanjo Conti: Audio de la charla El rol del programador en el equipo creativo (Manuel Quiñones)


El rol del programador en el equipo creativo o Scripting en Python para software de diseño una charla de Manuel Quiñones en el marco del Encuentro de Gráfica Libre que se llevó a cabo ayer.

Juanjo Conti: import_twitpic (plugin para Nikola)


Revisando qué contenido viejo subido a otros sitios podía importar en mi nuevo blog, me di cuenta que en mi segunda era de subir fotos tomadas con el celular mientras ando [1] mis fotos, por pura casualidad, se estuvieron guardando en Twitpic (descanse en paz).

Afortunadamente el sitio (que fue comprado por Twitter y dejado en modo read-only) te deja exportar tus datos. Me bajé un zip que adentro tenía una carpeta. La carpeta tenía todas las imágenes más un archivo de texto con la fecha de publicación de cada una y su texto.

Armado con esto y mi experiencia haciendo el plugin import_goodreads cree import_twitpic.

Este es su README:

This plugin imports Twitpic pics (including twitted text) as new posts.

This plugin:

  • Creates post as a rst file using the tweet text and the figure directive
  • Copies images to images/POSTS_OUTPUT_FOLDER/POST_SLUG/
  • Uses original tweet date as post date
  • Uses "Twitpic: DATE" as title
  • Adds "Twitpic" as tag plus the ones passed as arguments
  • Adds mentionds as hashtags as tags, but if the site already have a similar tag it use that (to avoid "ERROR: Nikola: You have tags that are too similar")

Note: Twitpic export is a folder cotaining all your images plus a tweets.txt file.

Tiene dos mejoras que eventualmente voy a migrar a import_goodreads y, con suerte, a otros:

  • agrega el parámetro --tags para definir tags extras a agregar a los posts que se crearán
  • antes de agregar un tag, se fija si antes no existe uno similar. De ser así, usa ese.

En la etiqueta Twitpic se puede ver el resultado luego de ejecutar el comando:

nikola import_twitpic -o posts/twitpic/  -t "Desde el camino, Fotos" dumps/twitpic/
[1]La primera era fue con un Nokia 6132 y mucho ingenio.

Juanjo Conti: import_goodreads (plugin para Nikola)


Ayer creé un nuevo plugin para Nikola como parte de mi esfuerzo por centralizar en este nuevo blog estático, distintos contenidos creados a lo largo de los años en distintas plataformas web.

Hoy, luego de algunos ajustes, lo mergiamos.

Este es el README:

This plugin import Goodreads read books from Goodreads RSS to an existing site.


  • uses the date the user ends to read the book as post date
  • includes user review
  • includes user rating
  • includes a link to the original review
  • uses author name, book title and "Goodreads review" as tags
  • writes output by default in posts/

To Do:

  • include book cover (dowloading the image)
  • add parameters to customize tags and content generated

Estaría bueno que no tenga código repetido con otros plugins: sí.

Estaría bueno que tenga más parámetros: sí.

¡Pero para ser la versión 0.1 está bastante bien!

El resultado en este blog se puede ver en el tag Goodreads review.

Marcos Dione: ayrton-0.5


I forgot to mention: last night I finally got to release ayrton-0.5. This has a major update to the language, thanks to our new parser, craftily thieved out of pypy. Other similar changes might come soon. Meanwhile, here's the ChangeLog:

  • Much better command detection.
  • CommandNotFound exception is now a subclass of NameError.
  • Allow Command keywords be named like -l and --long-option, so it supports options with single dashes (-long-option, à la find).
  • This also means that long-option is no longer passed as --long-option; you have to put the dashes explicitly.
  • bash() does not return a single string by default; override with single=True.
  • Way more tests.
  • Updated docs.

Get it on github or pypi! You can always find everything about ayrton in its GitHub page.

python ayrton

Hernán Grecco: The state of the PyVISA ecosystem (and more)


Yesterday we released several packages of the Python Instrumentation Ecosystem. You can upgrade to PyVISA 1.8, PyVISA-py 0.2 and PyVISA-sim 0.3  by:

pip install -U pyvisa pyvisa-py pyvisa-sim

For those of you who are new to instrumentation in Python, PyVISA is a Python frontend for the VISA specification that enables controlling all kinds of measurement equipment through GPIB, RS232, USB and Ethernet among others interfaces. If you are familiar with VISA instruments in LabVIEW, Matlab, C or .NET you already know how it works and you can make use of PyVISA as a nice Pythonic API to write your programs. If you have never done any instrumentation, Python and PyVISA is great combination to start.


As I mentioned before PyVISA is a frontend for the VISA specification, but what does this means in terms of software? PyVISA can connect to multiple backends, which are the ones doing part of the hard work. We currently have 3:

ni: is a wrapper to the NI-VISA library, which is the de facto standard implementation of VISA. It is feature complete but requires that you install the proprietary library provided by National Instruments. This is the default backend and is bundled with PyVISA. (Notice that we provide the wrapper, you need to install NI-VISA yourself as explained in the PyVISA docs)

py: is an implementation of the VISA specification using popular python packages to talk over the different interfaces: PySerial, PyUSB, linux-gpib and socket (which is inside the Python standard library). It is almost feature complete for Message Based Instruments (ASRL, USB, TCPIP, GPIB). It is available through the PyVISA-py.


sim: allows you create simulated instruments using simple text files. It is great for testing and off-line developing of complex instrumentation applications. It is available through the PyVISA-sim.

As always, these releases would not have been possible without our awesome community that provides code, bug reports, testing and support.

Finally I would like to mention that PyVISA is great but is kind of middle level. For complex applications you want better abstractions that allow you to forget about how the voltage is asked to a particular Voltmeter. For that purpose, I created Lantz a few years ago. It provides a very nice way to write drivers that encapsulate instrument specific information to then use them in scripts and GUI apps. It is not a replacement for PyVISA. Lantz builds on top of it to do the low level communication.

It turned out that I was not the only one thinking and coding in these direction. And I have always felt that dividing the community among many projects is a waste of time and energy. Particular in this type of projects in which the community is not as large the numerical programming and there is already an established standard.

That is is why triggered by his contribution to PintMatthieuDartiailh and I have decided to work together. He did some awesome instrumentation related coding in eapii and HQCMeas. Other people joined these initial conversations and a python instrumentation initiative that we have called LabPy was bornWe have created an organization in GitHub to host Lantz and other projects with a common goal: making instrumentation better in Python.

Matthieu has been championing the refactoring of Lantz, putting the best of the different toolkits together in a cohesive package. I have no doubt that Lantz 0.4 will be even better than 0.3

Join us at

Marcos Dione: I-got-myself-a-parser


So, only two days later I already have not only (what looks like) a full parser, which has already landed in develop, I also implemented the first big change in the grammar and semantics: keywords are allowed mixed with positional parameters; in case of command execution, they're converted to positional options; in normal function calls they're just put where they belong.

In the future there will be more restrictive checks so the Python part of the language does not change, but right now I'm interested in adding more small changes like that. For instance, as I said before, allowing the options to have the right amount of hyphens (-o, -option or --option), because right now I have code that prefixes with -- to anything longer than 1 character. The alternative would be to have another _special_arg to handle that. And while I'm at it, also allow --long-options. This is only possible because there's an specific check in the code for that. Unluckily this does not mean I can do the same trick for executable names, so I still lack absolute and relative commands, and you still have to write osmpbf-outline as osmpbf_outline. Maybe I'll just depart a little more from the grammar and allow those, but I have to deep think about it (that is, let the problem be in the back of my head for a while). What I can also do is to allow to use several times the same option (git ('comit-tree', p='fae76fae7', p='7aa3f63', 'a6fa33428bda9832') is an example that comes to mind) because it's another check not really done by the grammar.

In any case, it's quite a leap in the language. I just need to test it a little more before doing the next release, which surely will be the 0.5. I'll keep you posted!

ayrton python

Marcos Dione: breaking-off


Having my own version of the python parser has proven, so far, to be clumsy and chaotic. Clumsy because it means that I need a special interpreter just to run my language (which in any case uses an interpreter!), chaotic because the building of such interpreter has proven to not work stably in different machines. This means that currently it only works for me.

Because of this and because I wanted even more control over the parser (who said allowing to write things like rsync(--help)?), I decided to check my options. A friend of mine, more used to playing with languages, suggested using pypy to create my own parser, but that just lead me a little further: why not outright 'steal' pypy's parser? After all, they have their own, which is also generated from Python's Python.adsl.

In fact it took me one hour to port the parser and a couple more porting the AST builder. This included porting them to Python3 (both by running 2to3 and then applying some changes by hand, notably dict.iteritems -> dict.items) and trying to remove as much dependency on the rest of pypy, specially from rpython.

The last step was to migrate from their own AST implementation to Python's, but here's where (again) I hit the last brick wall: the ast.AST class and subclasses are very special. They're implemented in C, but the Python API does not allow to create nodes with the line and column info. for a moment I contemplated the option of creating another extension (that is, written in C) to make those calls, but the the obvious solution came to mind: a massive replacement from:

return ast.ASTClass ([params], foo.lineno, foo.column)


new_node = ast.ASTClass ([params])
new_node.lineno = foo.lineno
new_node.column = foo.column
return new_node

and some other similar changes. See here if you're really interested in all the details . I can only be grateful for regular expressions, capturing groups and editors that support both.

The following code is able to parse and dump a simple python script:

#! /usr/bin/env python3
import ast

from pypy.interpreter.pyparser import pyparse
from pypy.interpreter.astcompiler import astbuilder

info= pyparse.CompileInfo('', 'exec')
p= pyparse.PythonParser(None)
t= p.parse_source (open ('').read(), info)
a= astbuilder.ast_from_node (None, t, info)

print (ast.dump (a))

The result is the following (formatted by hand):

    ImportFrom(module='distutils.core', names=[alias(name='setup', asname=None)], level=0),
    Import(names=[alias(name='ayrton', asname=None)]),
    Expr(value=Call(func=Name(id='setup', ctx=<class '_ast.Load'>), args=None, keywords=[
        keyword(arg='name', value=Str(s='ayrton')),
        keyword(arg='version', value=Attribute(value=Name(id='ayrton', ctx=<class '_ast.Load'>), attr='__version__', ctx=<class '_ast.Load'>)),
        keyword(arg='description', value=Str(s='a shell-like scripting language based on Python3.')),
        keyword(arg='author', value=Str(s='Marcos Dione')),
        keyword(arg='author_email', value=Str(s='')),
        keyword(arg='url', value=Str(s='')),
        keyword(arg='packages', value=List(elts=[Str(s='ayrton')], ctx=<class '_ast.Load'>)),
        keyword(arg='scripts', value=List(elts=[Str(s='bin/ayrton')], ctx=<class '_ast.Load'>)),
        keyword(arg='license', value=Str(s='GPLv3')),
        keyword(arg='classifiers', value=List(elts=[
            Str(s='Development Status :: 3 - Alpha'),
            Str(s='Environment :: Console'),
            Str(s='Intended Audience :: Developers'),
            Str(s='Intended Audience :: System Administrators'),
            Str(s='License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)'), Str(s='Operating System :: POSIX'),
            Str(s='Programming Language :: Python :: 3'),
            Str(s='Topic :: System'),
            Str(s='Topic :: System :: Systems Administration')
        ctx=<class '_ast.Load'>))
    ], starargs=None, kwargs=None))

The next steps are to continue removing references to pypy code, and make sure it can actually parse all possible code. Then I should revisit the harcoded limitations in the parser (in particular in this loop and then be able to freely format program calls :).

Interesting times are arriving to ayrton!

Update: fixed last link. Thanks nueces!

python ayrton

Facundo Batista: PyCamp 2015, en La Serranita, Córdoba


Como casi siempre a Córdoba, fuí y volví en micro (porque en el colectivo en general duermo pasablemente bien, entonces aprovecho la noche, y no pierdo medio día "para viajar"). Esta vez, por otro lado, fuí un día antes, porque tenía que hacer un trámite en Córdoba Capital, así que estuve el jueves hospedado en la casa de Nati y Matías, trabajando durante el día, jugando juegos de mesa durante la noche.

El viernes a la mañana hicimos el viaje hasta La Serranita con los chicos. Llegamos a media mañana, y ahí se dió la situación de siempre, que es muchas veces esperada: saludar y abrazar a viejos amigos que uno no puede ver tan seguido (y a cuatro o cinco nuevos que uno todavía no conoce :) ).

El grupo recién reunido, charlando sobre las propuestas

Como quedaron planeadas las actividades

El lugar estuvo muy bueno. Quizás me podría quejar que el salón principal era demasiado ajustado, y que las comidas eran en una hostería a cuatro cuadras de distancia, pero el resto estuvo más que bien. No sólo las instalaciones (habitaciones, parque, quincho, etc, etc), sino la atención humana. Un lujo.

Hasta buena internet tuvimos en este PyCamp, ya que estábamos en la red vecinal abierta que Nico Echaniz y amigos montaron en La Quintana y ciudades aledañas. Eso sí, notamos que cuando teníamos problemas con lo que era comunicaciones el tema estaba en el router que estábamos usando (y eso que terminamos poniendo uno muy bueno). Decidimos que había que invertir en hardware un poco más pro (no algo "de uso hogareño bueno" sino algo "profesional")... veremos cuanto cuesta, pero creo que vamos a gastar unos mangos ahí, ya que nos queda no sólo para el PyCamp sino para otros eventos.

Una terraza dos niveles más arriba que la sala de laburo

Pequeño parque en uno de los niveles

A nivel proyectos y Python: lo de siempre... se hacen mil cosas, desde laburar en proyectos estables hasta delirar con cosas nuevas, se mejoran cosas arrancadas de antes, se agregan funcionalidades, se empiezan proyectos que se terminan en esos cuatro días, se arrancan cosas que luego duran mucho tiempo, etc... pero lo más importante no pasa por ahí.

El núcleo del evento es humano. Charlar con gente que conocés de siempre, y podés delirar ideas, proyectos nuevos, o simplemente charlar. Y conocer gente nueva. Pibes que están haciendo cosas locas o no, con laburos copados o no, con vidas interesantes o no. Pero charlar, compartir tiempo, ver como las otras personas encaran un proyecto, qué aportan, como ayudarlos, como transmitirles experiencias.

El programar Python es casi una excusa para que todo lo otro suceda. Y digo "casi" porque sí, claro, lo que se programa y hace está buenísimo también :D

En el comedor, almorzando

En la sala principal de laburo (no era grande, pero no era la única)

En ese aspecto, yo estuve principalmente con dos proyectos. Por un lado filesync server, recientemente liberado open source, con un cambio muy grande que empecé el jueves mismo estando en la casa de Nati y continué intermitentemente durante los cuatro días de PyCamp.

El otro proyecto en el que invertí mucho tiempo es fades que desarrollo principalmente con Nico. Es que se enganchó mucha gente que le gustaba lo que fades ofrece, y aportaron un montón de ideas buenísimas. ¡Y no sólo ideas! También código, branches que mergeamos o que todavía tenemos que revisar. Ya iremos metiendo todo, y queremos hacer un release en las próximas semanas. Estén atentos, porque fades ahora hace cosas que te vuela la peluca :D

Pero no sólo trabajé en eso. También porté Tritcask a que trabaje simultaneamente con Python 2 y Python 3 (arranqué sólo con esto, pero el 70% del laburo lo hicimos juntos con SAn). Y estuvimos buscando cómo hacer para detectar cuanto de un subtítulo matchea con las voces de un video, de manera de poder determinar si está bien sincronizado o no. Y estuve haciendo algo de código asincrónico usando asyncio. Y estuve charlando con SAn, DiegoM, Bruno y Nico Echaniz sobre una especie de Repositorio Federado de Contenido Educativo. Y estuve ayudando a gente a trabajar en Python mismo durante un cortito Python Bug Day (Jairo solucionó un issue y medio!!).

Camino al río

Recorriendo la vera del río, saltando de piedra en piedra

El mejor asado de un PyCamp, ever

Y tomé sol. Y tuve en mis manos una espada de verdad por primera vez. Y caminé por el costado del río saltando de piedra en piedra. Y comí un asadazo (entre el centenar de kilos de comida que ingeríamos por día por persona). Y conocí La Serranita. Y charlé mil. Y usé un sistema de realidad virtual. Y jugué a muchos juegos de mesa.

Y abracé amigos.

Facundo Batista: Se viene se viene el PyCamp 2015


La semana que viene (casi ahora ahorita) arranca una nueva edición del mejor evento de programación del mundo mundial.

Esta vez se hace en La Serranita, Córdoba.

Hay un montón de propuestas de varias personas, yo en particular propuse armar una especie de verificador de subtítulos (la idea es verificar si un subtítulo matchea con el video... o mejor dicho, con el audio... lo básico es encontrar si en el momento del subtítulo hay alguien hablando, con eso uno ya se asegura que el subtítulo está sincronizado), trabajar un poco en Encuentro y fades, y armar un Python Bug Day (para trabajar un rato en Python en sí, cerrar algún bug del lenguaje propiamente dicho... mucho código del lenguaje es en C, pero también hay mucho en Python mismo, y hay algunas cosas que son sencillas).

Aproveché y preparé/actualicé instrucciones de "cómo configurar/inicializar/arrancar con el proyecto" tanto para Encuentro como para fades. Para Python en sí no hace falta, ya que hay clarísimas instrucciones en la Python Developer's Guide :)

Ya les reportaré como fue todo :)