(1) Mon Jul 13 2009 21:24 Kiwi PyCon 2009 - Call for Participation :

#!/usr/bin/env PyCon
"""
Please, if you think some people interested have might not received this
notification, feel free to spread this eMail as far as the Internet can carry
it.
"""

Dear Python Community:
   """
   Please, be informed that the Call for Participation to Kiwi PyCon 2009
   in Christchurch on 7-8 November, is now open.
   """

We are looking for Talks, Tutorials, Lightning Talks, Demos, Open Spaces and
lots of hall way interaction. We're looking for proposals on all aspects of
Python - programming from novice to advanced levels; applications and
frameworks, or how you have been involved in introducing Python into your
organisation.

We especially welcome first-time speakers; we are a community conference and
we are eager to hear about your experience. If you have friends or colleagues
who have something valuable to contribute, twist their arms to tell us about
it! Please also forward this Call for Papers to anyone that you feel may be
interested.

To fins out more go to the official Call for Participation page here:

http://nz.pycon.org/talks-cfp/call-for-papers/

or get a printable version for your local pin board, your colleague's mail
pigeon holes, etc.

http://nzpug.org/KiwiPyCon/CallForProposals?action=AttachFile&do=get&target=KiwiPyConCfP.pdf

The submission deadline for proposals is in about two weeks already on Sunday,
2 August 2009. So, hurry up! Participators (not Lightning Talk speakers,
though) will receive a reduced rate for attendance of only $10!

See you in Christchurch this year!

Indented:
   Your NZPUG Kiwi PyCon Committee

Mon Apr 09 2007 18:41 some nevow silliness: I have an application (pydoctor) that uses nevow for its html generation. One of the newer classes uses a big "loaders.stan" for its docFactory, and this was getting a bit unwieldy so I wanted to switch to using loaders.xmlfile. But that meant I had to convert the stan expression into a template, which seemed like it would be pretty boring. So I hacked instead, and wrote an implementation of nevow.inevow.IRendererFactory that, when the stan is rendered, produces as output xml suitable for use with loaders.xmlfile.

The (fairly insane in places) code is here. For an example of what it does, it turns this into this. It doesn't support slots or patterns or ..., just those things I needed so far. It says something for nevow that this is even remotely possible :-)

As I've been learning bzr recently, I've made http://python.net/crew/mwh/hacks/stan2xml/ a bzr branch. Try bzr branch http://python.net/crew/mwh/hacks/stan2xml/.

Mon Mar 26 2007 00:31 EuroPython 2007: Call for Proposals: After a some late night CPS wrangling (fortunately mostly not done by me; Paul Boddie is a hero), I'm very happy to announce the EuroPython 2007 call for proposals:

http://www.europython.org/sections/tracks_and_talks/announcements/call-for-proposals

on behalf of all the people involved in organizing EuroPython this year.

Wed Mar 14 2007 12:05 Calling the Python web community: I'm program chair for EuroPython (9th-11th July in Vilnius this year), and I need your help: a huge part of the Python community is involved in web-related technologies but I am not, so I'd like to get some help to make sure we get lots of quality submissions, and to assess the submissions we get. If you think you can help with this, please let me know! Either leave a comment here, mail me (micahel@gmail.com) or best of all, come along to our meeting in #europython on freenode tonight:

http://codespeak.net/svn/user/mwh/ep2007/meeting-agenda-2007-03-14.html

Wed Nov 08 2006 16:09 CET-1CEST Summer of PyPy:

A month or two ago, we ("we" as in the PyPy project) finally sorted out the paperwork for our "Summer of PyPy" program, but perhaps didn't advertise it well enough and are making a second push to make sure everyone knows about it.

The basic idea is to fund the attendance of students at our last appropriate sprint. You propose a project, come to Leysin in January, work on your project, both in Leysin and in your own time and we'll pay for your travel and accomodation. Hacking on an exciting project in the Swiss mountains during the skiing season, what could be better?

For more details, see our c.l.p post.

(1) Fri Jul 28 2006 16:38 CET-1CEST pypy.net:

So today, PyPy Summer of Code student Antonio Cuni managed to compile a version of PyPy that works on .NET and on Mono. It still has _lots_ of rough edges (I don't think it works at all interactively, for example), but:

$ time mono ~antocuni/pypy.net/main.exe -c "print 'hello world'"
debug: entry point starting
debug:  argv ->
debug:  argv -> -c
debug:  argv -> print 'hello world'
hello world

real    0m12.940s
user    0m12.748s
sys     0m0.213s

This is very cool! Watch out IronPython :-)

You can get binaries at http://codespeak.net/~antocuni/pypy.net/.

Tue Jul 04 2006 14:30 CET-1CEST europython quote: In the spirit of http://moshez.livejournal.com/83036.html...

Martijn: I'm taking part in the zope foundation battle this afternoon... uh, zope foundation panel.

Well, that's not quite how it went, but the joke is the same :-)

(3) Wed Jun 07 2006 12:25 CET-1CEST EuroPython 2006 timetable + reduced registration:

Over in EuroPython land, the timetable is now mostly completed.

You can register for a reduced rate until this Sunday, so get on with it! :-)

Mon May 22 2006 17:44 CET-1CEST gkrellm client for os x:

A server I fairly frequently run jobs on has a gkrellm daemon on it. I run Mac OS X and it's convenient to be able to see what the load on the machine is to tell whether now or later would be a good time to run a job. I didn't instantly find such a beastie, so I wrote one, after a little playing with telnet(1) and source reading. Extremely simple, requires new-ish Twisted and PyObjC. It would probably be fairly easy to extend to do more complicated things, but it does what I want it to do for now.

Mon May 15 2006 17:49 CET-1CEST things you learn in #pypy:

  [15:42] <arigo> argh, the following is valid Python syntax: assert a is not b - XXX in-progress
  [15:42] <arigo> :-)

Thu Apr 20 2006 11:46 CET-1CEST talking to the accu:

So I'm at the ACCU conference in Oxford. Yesterday I gave two talks; the first was about exception handling with recovery and the second was PyPy - a status report. You can get both sets of slides in KeyNote and PDF and also some sample code for the first talk.

Both talks seemed to be well received and the first even has Guido asking me about writing a PEP...

Sun Feb 19 2006 11:24 CET-1CEST buildbot goes green:

Python fairly recently set up a buildbot at http://www.python.org/dev/buildbot/.

After some effort by many people (not really much from me unfortunately), it's now all green, and hopefully it'll stay that way (test_logging still fails sporadically on solaris, for reasons not yet understood).

However: we have no Windows buildslave. If you care about Python's stability on Windows, please consider setting one up (currently I think the best way to offer this service is to email python-dev and say "I'd like to run a windows buildslave for python").

Sat Dec 10 2005 00:11 CET-1CEST This Week In PyPy for the week ending 2005-12-09:

The first summary that gets posted to my blog before at the same time as it gets sent out as email:

[00:04] Arigo states it is time to merge the PBC branch. Merging henceforth
        commences.
[15:46] Pedronis and mwh discusses the simplification of the backend
        selection of the translator. Some translator planning documents
        checked in later.

[15:45] Stakkars mentions the idea he posted to pypy-dev, that involves
        the substitution of CPython modules piecewise with pypy generated
        modules. Pedronis replies that he has thought of a similar
        approach to integrate pypy and Jython, but that this effort needs
        to be balanced with the fact that the pypy JIT currently needs
        attention.

[14:03] Stakkars asks about the necessity of 3 stacks in the l3interpreter
        that Armin has been working on. One for floats, ints and
        addresses. After remarks about easier CPU support, Arigo replies
        that there is simply no sane way to write RPython with a single one.
[18:26] Gromit asks how ready pypy is for production usage. He is
        interested in pypy as a smalltalk-like environment, since he deems
        objects spaces to be reminiscent of smalltalk vm images.
[18:31] Stakkars states that he believes the project should postpone
        advanced technologies, in favour of getting the groundwork to a
        level where the project really becomes a CPython alternative.

[01:44] Pedronis running counting microbenchmarks, one 4.7 times slower
        than CPython, the other one 11.3 times. Function calling takes
        its toll in the latter.

[xx:xx] Sprint background radiation. Braintone rings like a bell. Not
        much to report.

[17:55] Stakkars guess that RPython may get basic coroutine support, and
        is excited about that.
[18:05] Stakkars votes for having stackless enabled all the time. The
        advantages:
           - real garbage collection
           - iterator implementation without clumsy state machines
[20:19] Rhamphoryncus wonders whether dynamic specialization (e.g. psyco)
        can possibly improve memory layout.
[20:46] Sabi is glad that long long is now supported (courtesy of mwh and
        Johahn). He yanks out his work around.

Tue Dec 06 2005 11:44 CET-1CEST This Week In PyPy for the week ending 2005-12-02:

And finally, my blog is up to date with this week in PyPy.

It's an XP-style meeting that serves to synchronize
development work and let everybody know who is
working on what.  It also serves as a decision
board of the PyPy active developers.  If discussions
last too long and decisions cannot be reached
they are delegated to a sub-group or get postponed.

Mon Dec 05 2005 17:07 CET-1CEST This Week In PyPy for the week ending 2005-11-25:

Only one more, then I'll be caught up...

Sun Dec 04 2005 13:10 CET-1CEST This Week In PyPy for the week ending 2005-11-18:

Only two to go now...

Sat Dec 03 2005 11:48 CET-1CEST This Week In PyPy for the week ending 2005-11-11:

Number two...

Fri Dec 02 2005 11:58 CET-1CEST This Week In PyPy for the week ending 2005-11-04:

As previously threatened...

(1) Fri Dec 02 2005 11:56 CET-1CEST This Week In PyPy backlog:

For a few weeks now, I've been writing a This Week in PyPy summary of activity in PyPy-land. I've only been posting them to pypy-dev, and they are hopefully suited to being a bit more widely read than that. This blog gets onto Planet Python which probably has an appropriate readership, so I'm going to post future summaries here. But first I'm going to spam Planet Python with the summaries I've already written :) (one a day sounds about right :).

Thu Nov 03 2005 15:24 CET-1CEST PyPy 0.8.0:

We released PyPy 0.8.0 today. No huge changes over 0.7.0 which was the first release capable of building a free-standing Python implementation, but quite a bit more polish and speed (both in the translation process and in the resulting executable). Take it for a spin! Find bugs! Have fun!

(7) Fri Oct 21 2005 13:58 CET-1CEST job!:

As of a few hours ago, I am now paid to work full time on PyPy. Yay!

Sat May 21 2005 18:09 CET-1CEST whoa!:

Long time no update. Oh well.

I seem to be accumulating some fairly major CPython changes in my tree of late. Here are the ones I remember:

• new-style exceptions (this one just needs some documentation and can then probably go in).
• removing the abuse of ob_size for longobject.c (this possibly needs some polishing, but first I'd rather know if it's generally considered a good idea).
• changes to the packing of floats to just copy bytes on platforms that appear to use IEEE-754 formats (this needs review, ideally, though I'm tempted to just check the blighter in)
• changes to marshal to use a binary format for floats (shouldn't go in until the above gets in, although it's not strictly dependent on it)
• some hacks towards restartable exceptions (I only did this in the last couple of days, and noone knows about it yet :)

I guess it would be more useful to try and check some of these in (or abandon the idea) before creating too many more...

(2) Sat Oct 09 2004 14:51 CET-1CEST not messing up, AOP, PyPy:

Saw a link on Advogato to an Alan Cox interview about writing better code.

Nothing terribly exciting, but he stresses the point that the quality of tools and interfaces has a large impact on the quality of code. People will always make mistakes; we shouldn't make it easier to foul up than it has to be.

He also talks about automated verification tools, using the example of checking a lock is released on all code paths out of a function. There's a gap in the market for a similar tool to check the reference count manipulations in CPython. Although reference counting is conceptually simple, it's a classically bad interface in some ways: no matter how careful people are, there just will be reference counting mistakes in new C code in each major release cycle of Python. I've written some tools to watch for reference leaks while running the regression suite, and so long as you run these fairly often (not every day, they're pretty slow) it's not that hard to find and fix the bugs -- because you can be pretty sure they'll be in new code. I'm not sure automatic verification is the right solution, though.

A better solution, perhaps, would be to not write the reference count manipulations at all: if you write the code in Pyrex, say, and you trust the author of Pyrex, you can be confident that the generated C code will get this right. You're exchanging a wide-spread, fairly simple problem for a localized, harder problem that someone else has already solved. This has to be a good thing.

So, AOP. One reasonable definition of AOP is "a set of tools and techniques to make programming on the Java platform more bearable". I'm interested in the other one: the idea that each decision involving writing a piece of software should be reflected in as few places as possible. The AOP crowd usually use logging as their example. This is a crap example, IMHO -- memory management is a much better one (unfortunately, it's not one the AOP crowd's tools can do anything about AFAIK). The decision to use reference counting in CPython's implementation is emphatically not localized -- it's reflected tens or hundreds of times in almost every C file in the source. Another example is that the seemingly less contentious decision for a function call in Python to be implemented as a function call in C makes implementing interesting control flow -- coroutines, restartable exceptions, etc -- very much more difficult.

So, what can be done? Well, one idea is to take a specification for the Python language and from that generate an implementation. Hopefully, this generator can be designed such that aspects such as memory management model, allowable control transfers and even target platform are localized in the AOP sense. Now, how do you specify the Python language? Well, you could write a Python program that implements the Python language... which brings us to PyPy.

I should probably turn on drafts for NewsBruiser. I apologize to anyone who read this entry while I was still rewriting it..

Fri Sep 03 2004 16:37 CET-1CEST Nevow vs ZPT/TAL:

I've played a bit with Zope's Page Template and TAL system for generating HTML, and quite like them.

The rest of Zope is a bit large and scary, though, so for my latest time wasting project, I've been using Nevow and Twisted (another reason for this is that this project is an overgrown IRC bot :-).

Nevow templates look a bit like (and are somewhat inspired by) ZPTs, but at least on some levels, they are really quite different. The process of instantiating a ZPT is more or less like evaluating a function (i.e. side-effect free process):

ZPT x Data ----> output

With Nevow it's a bit different; a stan DOM is built out of your template and then mutated into the output.

I didn't appreciate this difference at first, but once I did found Nevow a fair bit less baffling.

I still think I prefer ZPT/TAL in some ways, but that might just be familarity. Also, Nevow is flexible enough that I can probably steal the features of TAL I like.

Thanks to dialtone on #twisted.web IRC for setting me straight!

Wed Aug 18 2004 13:08 CET-1CEST Verifying history:

From http://www.rtfm.com/movabletype/archives/2004_08.html#001055:

$ cat md5b.py
import md5, array

a = array.array('B', [0xd1, 0x31, 0xdd, 0x02, 0xc5, 0xe6, 0xee,
                      0xc4, 0x69, 0x3d, 0x9a, 0x06, 0x98, 0xaf,
                      0xf9, 0x5c, 0x2f, 0xca, 0xb5, 0x87, 0x12,
                      0x46, 0x7e, 0xab, 0x40, 0x04, 0x58, 0x3e,
                      0xb8, 0xfb, 0x7f, 0x89, 0x55, 0xad, 0x34,
                      0x06, 0x09, 0xf4, 0xb3, 0x02, 0x83, 0xe4,
                      0x88, 0x83, 0x25, 0x71, 0x41, 0x5a, 0x08,
                      0x51, 0x25, 0xe8, 0xf7, 0xcd, 0xc9, 0x9f,
                      0xd9, 0x1d, 0xbd, 0xf2, 0x80, 0x37, 0x3c,
                      0x5b, 0xd8, 0x82, 0x3e, 0x31, 0x56, 0x34,
                      0x8f, 0x5b, 0xae, 0x6d, 0xac, 0xd4, 0x36,
                      0xc9, 0x19, 0xc6, 0xdd, 0x53, 0xe2, 0xb4,
                      0x87, 0xda, 0x03, 0xfd, 0x02, 0x39, 0x63,
                      0x06, 0xd2, 0x48, 0xcd, 0xa0, 0xe9, 0x9f,
                      0x33, 0x42, 0x0f, 0x57, 0x7e, 0xe8, 0xce,
                      0x54, 0xb6, 0x70, 0x80, 0xa8, 0x0d, 0x1e,
                      0xc6, 0x98, 0x21, 0xbc, 0xb6, 0xa8, 0x83,
                      0x93, 0x96, 0xf9, 0x65, 0x2b, 0x6f, 0xf7,
                      0x2a, 0x70]).tostring()

b = array.array('B', [0xd1, 0x31, 0xdd, 0x02, 0xc5, 0xe6, 0xee,
                      0xc4, 0x69, 0x3d, 0x9a, 0x06, 0x98, 0xaf,
                      0xf9, 0x5c, 0x2f, 0xca, 0xb5, 0x07, 0x12,
                      0x46, 0x7e, 0xab, 0x40, 0x04, 0x58, 0x3e,
                      0xb8, 0xfb, 0x7f, 0x89, 0x55, 0xad, 0x34,
                      0x06, 0x09, 0xf4, 0xb3, 0x02, 0x83, 0xe4,
                      0x88, 0x83, 0x25, 0xf1, 0x41, 0x5a, 0x08,
                      0x51, 0x25, 0xe8, 0xf7, 0xcd, 0xc9, 0x9f,
                      0xd9, 0x1d, 0xbd, 0x72, 0x80, 0x37, 0x3c,
                      0x5b, 0xd8, 0x82, 0x3e, 0x31, 0x56, 0x34,
                      0x8f, 0x5b, 0xae, 0x6d, 0xac, 0xd4, 0x36,
                      0xc9, 0x19, 0xc6, 0xdd, 0x53, 0xe2, 0x34,
                      0x87, 0xda, 0x03, 0xfd, 0x02, 0x39, 0x63,
                      0x06, 0xd2, 0x48, 0xcd, 0xa0, 0xe9, 0x9f,
                      0x33, 0x42, 0x0f, 0x57, 0x7e, 0xe8, 0xce,
                      0x54, 0xb6, 0x70, 0x80, 0x28, 0x0d, 0x1e,
                      0xc6, 0x98, 0x21, 0xbc, 0xb6, 0xa8, 0x83,
                      0x93, 0x96, 0xf9, 0x65, 0xab, 0x6f, 0xf7,
                      0x2a, 0x70]).tostring()

for i, (c, d) in enumerate(zip(a, b)):
    if c != d:
        print "%-3d %02x %02x"%(i, ord(c), ord(d))

print md5.md5(a).hexdigest()
print md5.md5(b).hexdigest()
$ python2.3 md5b.py
19  87 07
45  71 f1
59  f2 72
83  b4 34
109 a8 28
123 2b ab
79054025255fb1a26e4bc422aef54eb4
79054025255fb1a26e4bc422aef54eb4

(2) Sat Aug 14 2004 16:28 CET-1CEST src/Doc/ext:

Python's Extending and Embedding the Python Interpreter manual is a bit of a dog's breakfast. There's a lot of good info in there, but a lot of authors have hacked at it from time to time and it shows (I'm one of them). Also some parts are getting a touch out of date, and I don't think there are enough examples.

So, I'm attempting to rewrite it.

Comments welcome! (via email or NewsBruiser, I don't mind).

(4) Wed Aug 04 2004 14:09 CET-1CEST The Python's Progress:

This is somewhat inspired by the decorator kerfuffle, yes.

While thinking the decorator issue is a kind of ultimate bike shed, it did start me thinking: will I actually use this feature? I don't really know, yet.

"It is tough to make predictions, especially about the future."
         -- Yogi Berra

The obvious consequence of using the decorator syntax is that it ties my code to 2.4 or later. Will I consider that a problem? History suggests I will for a while and then I'll gradually feel less need to make my code work with 2.3 or before (I'm not really talking about code for specific projects here).

This set me thinking: what features of newer Python's have seemed handy enough to make it worth breaking compatibility with previous versions? Here's a list from recent to ancient of what I remember (or predict):

• 2.4 (guessing): decorators, Decimal
• 2.3: 'substring in string' -- this really surprised me, but it's actually pretty handy, using generators without a __future__ statement, occasionally assignment to __name__ of new-style classes
• 2.2: new-style classes, generators, iterators
• 2.1: nested scopes (try writing test cases for unittest.py without these!)
• 1.6/2.0: string methods, unicode
• 1.5.2: too long ago to remember

Am I missing things?

It's interesting to look at some code that I wrote recently (to parse a fairly stupid text based format): although it superficially looks like 1.5.2-era Python, it's actually very different. In particular, the advent of the iterator meme and to a lesser extent 'substring in string' make a certain kind of almost awk-like programming much easier.

(Also: python 2.0 should have been 1.7, 2.1 should have been 1.8 and the big 2.0 probably should have waited for 2.2. But never mind :-)

Thu Jul 29 2004 17:24 CET-1CEST Brackets:

Back when I learnt Python (1998 or so), it was most frequently compared to perl. Nowadays, it's most frequently compared to Java. This is

1. interesting
2. cool!

(1) Thu Jul 01 2004 17:52 CET-1CEST Things I'd like to be doing:

I'm supposed to be finishing my PhD, of course.

However, there's a few things that sound much more fun:

1. Really getting to know Zope/Plone, or something similar, and using them to write a new site for SDA.

2. Related to the above, I have some ideas about optimization that might apply nicely to ZPTs.
3. Sundry NewsBrusier/reST/emacs integration things. I have some crazy and not-so-crazy ideas that shouldn't be that hard to implement.
4. Working on PyRepl to the point that it is fit for inclusion into the Python standard library. I am really sick of readline.

I'd estimate about 5 weeks, 6 weeks, 2 weeks and 4 weeks (in order) full-time hacking for each of these. Ain't gonna happen. Sigh.

Wed Jun 30 2004 16:53 CET-1CEST GNU readline can suck it:

Man, does GNU readline sometimes get under my skin.

The problem today is, as it has been for a while, SF patch #960406.

I've been working fairly hard on the patch lately and thought I was making good progress, but today I hit two nasty problems: one is that my re-entrancy guards can cause the interactive top-level to go utterly insane and the other is that the 'alternate interface' to readline that the patch uses to keep control of the event loop appears to go on holiday when the user types Control-r.

Either of these would be pretty bad; to find both today is pretty disheartening. I wonder how close to being suitable for inclusion in the Python stdlib I could have gotten pyrepl in the time I've spent on this patch...