[ home | blog home | recent activity | guestbook | plugins i'm using (19) ]
Last night, I spent a few hours going through all the videos from PyOhio 2010, added metadata from the PyOhio site, added notes about video issues, and approved all of the videos except one which I'm talking with Carl about.
It looks like PyOhio 2010 was a really great conference: the talks are really great, you can feel the energy in the rooms from the people who attended, the questions are interesting, and the videos from the conference are fantastic. Also, I'm a huge +1 on using the headset mics--they absolutely make a difference in being able to hear the presenter throughout the video.
Here are three sessions I watched all the way through:
Sessions from PyOhio 2010 are in the PyOhio 2010 category. Take some time today to browse the sessions and watch the ones that interest you.
Also, I'm sitting on videos for two other conferences: DjangoConf EU and Kiwi PyCon. I'm hoping to get to them in the next couple of weeks. I did PyOhio 2010 videos last night because Carl needed someone to spot-check them to make sure the uploads were good.
This is the July status report for Python Miro Community. This site indexes videos from around the Internet related to Python. In particular, we focus on indexing conference session video and videos from our more prolific Python user groups.
In the last month, we've finished approving all the PyCon 2010 videos. They're all in the PyCon 2010 conference category.
I spent a few hours adding metadata to and approving videos from PyCon AU 2010. There are some really great ones--definitely worth looking at. They're all in the PyCon AU 2010 conference category.
PCF released a new version of Miro Community with some bug fixes and a widget that allows you to embed videos on other sites. I haven't played with that yet, but it sounds useful.
I'm still working on recategorizing things per Carl's suggestions from last month.
That's it for this status report. Any thoughts, questions or concerns--let me know.
I was going through the videos tweaking tags and other metadata when I noticed that Python Miro Community has no videos that cover pygame.
pygame is a library for writing games. It has a huge community and it's a great way to introduce people to Python programming. I'd love to see some pygame material on the site.
If you know of video tutorials for pygame that could be added to the site, please submit them.
If you'd be interested in creating a video tutorial for pygame, let me know and we can work on it.
I spent 20 or so hours over the last few weeks working through the moderator queue for Python Miro Community and making changes to the site. We've almost posted all of the PyCon 2010 videos--I think there are three or four more still in the queue including one of the lightning talks.
I've created a bunch of bugs in the Miro Community bug tracker for bugs that I've encountered and enhancements that would make the site and curation of the site better. Miro Community is a Free Software project, so I'm hoping to find free time to fix/implement some of those.
Carl Karsten is now a curator on the site--that makes two of us. He's been a huge help so far. Having someone to bounce ideas off of makes it a lot easier and he brings a lot of enthusiasm to the site. Right now we're coordinating things through email and we're tentatively going to use the pycon-av mailing list for PMC discussion. If we need to switch to another mailing list, then we'll do that.
At Carl's suggestion, we added a new category of categories for Python user groups. The three groups we have listed now are ChiPy (Chicago, IL), BostonPy (Boston, MA), and PyAtl (Atlanta, GA). The PyAtl videos are mostly from last year--I need to catch up with a PyAtl member to find out what's going on. There are only two BostonPy videos now, but the group is interested in doing more. The ChiPy videos are fantastic. Additionally, Pior from Montreal-Python is working on getting their video workflow working--I really look forward to seeing their sessions.
I've been tagging videos that I think are good for Python beginners with the tag "python-basics". At some point in the near future, we're going to move some/all of those videos into a Learning Python category. There's a large amount of decent introductory material for Python out there ranging from videos on YouTube to tutorials at PyCon. I think this category will make it easier for people new to Python to get their feet wet quickly and easily.
On a slightly related note, the Universal Subtitles project recently launched an alpha demo of their system. I'm looking forward to this project reaching a stable status since I'm planning to use it on PMC to add subtitle/transcription to all videos on Python Miro Community. The project is in Django and it's Free Software. If you're interested in this work, they sure could use the help.
That's it for this status report. Any thoughts, questions or concerns--let me know.
I spent a few hours with the Python Miro Community site today re-applying the template changes I made to the theme to the new version of the theme. Miro Community has released two versions since I tweaked the theme, so I was playing catch-up. I'm putting my edits into version control this time around so I don't lose them again (stupid stupid stupid).
One of the things I want to do with Python Miro Community is to build playlists of videos covering a specific theme for helping people come up to speed with those areas: testing in Python, basic Python programming, advanced Python programming, ... I've been faking this using tags, but it's pretty suboptimal because I can't control the order the videos get listed in on the tag listing page. Dean created bug 12627 for implemnting playlists/series. This would also fix the problem I have where YouTube duration maximums force a single "video" to span several YouTube urls and thus be several separated videos. Anyhow, looks like that isn't going to get implemented for Miro Community 1.0.
I started slogging through the queue. We've got 80 videos or so in the approve/reject queue right now. A bunch of them are PyCon 2010 related. A bunch are from Carl's blip.tv feed and are from ChiPy and other things. 50 or so are from a Plone feed that Nate Aune sent me. I'm going to make a concerted effort to get through the queue over the next couple of weeks.
Even though I'm behind in the queue, I encourage people to submit new videos. Some of the best material comes from Python user groups--I'd really like to see more groups videoing their sessions, posting them online, and submitting them to PMC. Don't let ChiPy and PyAtl outshine everyone else!
You can find Python Miro Community at http://python.mirocommunity.org/.
Quickly is an application that makes it easier to start new software development projects by filling in a lot of the skeletal structure from a set of templates. I've read about it a bunch on Jono's blog in the context of his push for "opportunistic developers".
Chris Webber and I have been throwing together web applications most of which have the same basic structure: WebOb, Jinja2, simplejson, and routes with some glue and stuff in between.
I spent some time building a Quickly template for this structure. The results of this are at http://gitorious.org/quickly-webber-app.
It was kind of a pain in the ass. There's no docmentation that I could find on creating templates for Quickly, so I had to look through the ubuntu-project template and read through the Quickly code. Even then, I bumped into a few gotchas.
~/quickly-templates/ directory rather than as a
project and schlepping things in and out like I did
I was using the Quickly that comes with Ubuntu Karmic which is 0.2.6. Ubuntu Lucid has a newer version, but I didn't want to fiddle with trying to get it to install on Karmic given that it's got dependencies that aren't readily available in Karmic.
After talking with Chris, he suggested I redo it with Paste templates. There's a good explanation at http://pylonshq.com/docs/en/0.9.7/advanced_pylons/creating_paste_templates/. It'd be interesting to see if I could build a set of templates that works with both Quickly and Paste.
Anyhow, the project is there if it's interesting to anyone. Email me or comment below if you have questions, comments, concerns, whatever.
Update 5/2/2010 - Didier (Quickly dev) says there is documentation for creating templates at http://www.didrocks.fr/index.php/post/Build-your-application-quickly-with-Quickly%3A-Inside-Quickly-part-6.
PyCon 2010 is over and the PyCon AV crew is working on taking the video they've recorded, editing it, and posting it. As they post it to the Pycon blip.tv feed, I'm pulling it into Python Miro Community. You can keep track of my status here (RSS).
I sent an email to the Cambridge Python Meetup (Cambridge, MA, USA) asking if they still record video and if so, where it gets posted.
Nate Aune sent me a link to the PloneTV feed. I'm in the process of pulling those videos in.
One thing I've noticed while curating Python Miro Community is that the quality of the image and audio make a huge difference in the usefulness of the video after the event. It's a huge project with a lot of finicky bits to reliably create great video.
Many many props to Carl Karsten, the PyCon-AV team, and all the other people out there doing this work. It allows these presentations to live beyond a moment in time and reach a much larger audience.
If you're one of the lucky people going to PyCon 2010, you might want to spend some time coming up to speed on some of the talks being given.
Interested in the GIL? David Beazley is giving a talk on the inner workings of the Python GIL. He's given several GIL-related presentations before: Asynchronous vs. Threaded Python, Mindblowing Python GIL, and Changes to the GIL in Python 3.
Interested in documentation? Wesleay J. Chun is giving a talk on writing books using Python and Open Source Software. This will likely talk about Sphinx. Take some time to watch Brandon Rhodes talk about Sphinx at PyAtl.
Interested in PyPy? Maciej Fijalkowski is giving a talk on the speed of PyPy. Take some time to watch the PyPy status talk from PyCon 2009.
Don't go to PyCon unprepared!
Today I'm releasing Python Miro Community. This site is a Miro Community focused on Python. It brings together videos from Python conferences, local user groups, screencasts, and tutorials.
I'm working on it in my spare time because:
This site helps on both fronts. The first in that it collects video into one place without re-hosting it. The second in that I'm curating the site and through better descriptions and tags, the video becomes more findable.
It's not finished--it's an ongoing project that I'll continue to work on. My ultimate goal is to connect with Python video producers like Carl Karsten (whose work is phenomenal), conference A/V people, local user group A/V people, and all those people out there making screencasts, tutorials and project status videos to make sure Python Miro Community stays relevant and continues to helps creators and consumers.
It's free. I'm doing this in my spare time, Participatory Culture Foundation (the non-profit behind Miro) is providing the server and resources to host the site, and the video on the site is available for free on the Internet.
Spend some time today to take a look at the site, browse the PyCon 2009 and DjangoCon 2009 videos, spend some time honing your Python skills with either the Python basics or Python advanced tracks, follow along with the ChiPy or PyAtl local user groups, and see what's out there.
Love it? Hate it? Let me know in the comments.
Thank you to Carl Karsten and Steve Holden for their help pulling this site together!
PyBlosxom uses Sphinx for documentation
now. I was having problems with using -- for em-dash and it not
showing up like an em-dash in the HTML output.
The docutils FAQ says to use the actual unicode character for emdash. I don't really want to do that because I'm not sure about what happens when the source files are opened up by a non-unicode-friendly text editor.
Turns out that doesn't matter because Sphinx allows -- for
en-dash and --- for em-dash. Is this something that should
get added to the Sphinx documentation?
Today I read You can't crowdsource software. The title sums up what it's about.
I've had this experience with Miro. We occassionally get patches from non-PCF people but most of the work is done by PCF developers. We've spent a lot of time and effort over the last few years on getting more code contributors and reducing the barriers to entry. We haven't had much success.
However, there's a lot of other "stuff" that goes into developing an application and the article only focuses on code. Some of this "stuff" can be successfully crowdsourced without a lot of effort. For example, Miro crowdsources all of our strings translation work through Launchpad.
I work on another project called PyBlosxom. We have a core group of developers (right now this is me) who do the bulk of the core code work. I do some plugin work, but the bulk of the plugin work is done by users of PyBlosxom many of whom have never touched the core code. For PyBlosxom, plugin development is crowdsourced.
The article suggests that it's a waste of time to help bring new contributors come up to speed and contribute because they often don't contribute much. That conclusion really concerns me. How can we get more people helping out if we're not working on getting people to help out?
Jono Bacon wrote an article titled Project Awesome Opportunity which talks about a few projects that are reducing the barriers to contributing and making it a lot easier. It's very Launchpad-centric, though.
OpenHatch is a startup working on building the next generation of contributors and connecting contributors to projects that need help. They're wrestling with how to effectively fix these problems, but without tying the fix to a project development silo (e.g. Launchpad, GitHub, ...). I think that's really important.
I think systems like these will reduce the effort in getting contributors and make it easier to crowdsource code contribution.
And if you, dear reader, are looking for a project to help out on that's written in Python and need someone to mentor you, let me know.
February 5th, 2010: I should clarify I think the article is fine. I don't think the conclusion that code contribution doesn't crowdsource well is poorly formed or anything like that. Just that the implications suck.
Spent a while figuring out how to get Miro to handle media keys in Gnome. My current understanding (and this could be entirely wrong) is that as of 2.18, Gnome handles the multimedia keys. In order for your application to respond to multimedia keys, you have to connect to the signal through dbus.
My biggest problem is that my web searching revealed a lot of bugs, but no documentation. I did finally find Handling multimedia keys in GNOME 2.18 and then worked out the rest. I still have no clue where to find the documentation for it.
Here's what I got working:
import logging
import dbus
from miro import app
class MediaKeyHandler(object):
def __init__(self):
self.bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
self.bus_object = self.bus.get_object(
'org.gnome.SettingsDaemon', '/org/gnome/SettingsDaemon/MediaKeys')
self.bus_object.GrabMediaPlayerKeys(
"Miro", 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')
self.bus_object.connect_to_signal(
'MediaPlayerKeyPressed', self.handle_mediakey)
def handle_mediakey(self, *mmkeys):
for key in mmkeys:
if key == "Play":
app.widgetapp.on_play_clicked()
elif key == "Stop":
app.widgetapp.on_stop_clicked()
elif key == "Next":
app.widgetapp.on_forward_clicked()
elif key == "Previous":
app.widgetapp.on_previous_clicked()
def get_media_key_handler():
try:
return MediaKeyHandler()
except dbus.DBusException:
logging.exception("cannot load MediaKeyHandler")
If you see problems with this, let me know so I can ammend the code.
Between the end of 2003 and mid-2007, I played in a D&D campaign that was really fantastic. The campaign ran its course and our stalwart crew of awesomeness saved the world and then we went our separate ways.
During that period of time, I kept copious notes in a MoinMoin wiki of our adventures. It was always a hope that I'd take these notes and do something with them.
I played in another campaign in 2007 and used InkScape to do a comic of the first session or two of that campaign in the style of Order of the Stick. It was a lot of fun, but took forever to do each panel. I decided it'd take me a long time to do 4 years worth of sessions in comic form.
So I started a book version. I wrote a Python script (which I've since lost) that converted MoinMoin format into restructured text. Then I threw the whole thing together with Sphinx. This allowed me to edit in restructured text, compile a LaTeX document, and then generate a PDF from that. Plus I got to spend some quality time with Sphinx to see how well it generates manuals.
That worked really well except for some minor issues.
First, I needed to set the paper size in the resulting PDF. To do that, I
set the latex_preamble in the conf.py file to:
latex_preamble = '\\usepackage[papersize={6in,9in}]{geometry}\n' \
'\\setcounter{tocdepth}{1}'
That creates the PDF in the size I needed: 6in x 9in.
Second, I needed to fix some images so they were in a table with text. I ended up writing the LaTeX for that by hand.
Third, I didn't think the chapter headings really fit with what I wanted to build, so I changed the fncychap style to Lenny.
While I was editing the LaTeX directly, I ended up changing some of the front matter and removed the index (didn't need an index to a novel).
It took me a year to put the book together. It's around 240 pages or so. Today I finished it up, created a Lulu project for the book and had a bunch of copies printed for the others in the group. Feels good to have that done. I'm looking forward to getting a copy in the mail.
I use a four space indent which causes problems when indenting
if statements that span multiple lines. For
example:
if (a
and b
and c):
if_block_here
The problem is caused because if is two characters
and therefor if ( is four characters--which matches
the four space indent. I end up with code where I can't easily
distinguish if statement from the if block.
After talking about it with Paul and Chris and working out what the specifics of the problem are, I decided to use double parens. The above with double-parens looks like this:
if ((a
and b
and c)):
if_block_here
That satisfies PEP-8, doesn't change the semantics, and fixes my problem. It is a little goofy to use double parens, but it's a good enough fix until I get around to fiddling with the code that does automatic indentation in python-mode.
I'd be interested in other ideas that don't involve using \
at the end of lines if they're out there.
I was reviewing something and learned that Python saves the original
sys.stdin,
sys.stdout,
and sys.stderr
as
sys.__stdin__,
sys.__stdout__,
and sys.__stderr__ respectively. That's pretty handy to
know. Works in at least Python 2.5 and up--I didn't test earlier
versions.
I threw together a VLC renderer for Miro on gtk-x11 based on the VLC renderer code we use for Miro on Windows. It took an hour or so to get it working.
I'd love to toss it in into Miro, but it's got one major problem and one minor one.
The major problem is that VLC handles mouse events rather than letting them bubble up to Miro. When you double-click on the a video, VLC handles the double-click and switches the video to fullscreen (or out of fullscreen). It'd be better if Miro handled this--then it could show the media item details bar. Also, VLC handles mouse movement. Miro needs to handle this, too, so then it can show the item details bar.
The minor problem is that VLC doesn't have libvlc_video_track_count
in versions prior to 1.0. I'm not sure how else to figure out if a media file
has video tracks in it. Because of this, the sniffer code is pretty ham-fisted
if you have earlier versions of VLC.
The code is at http://bluesock.org/~willg/download/vlcrenderer.py if you're interested in fiddling with it. There's documentation at the top of the file that walks through installing and using it.
I'd love to get some help fixing it. Adding support for VLC and dropping support for xine on gtk-x11 would make things a lot easier for us Miro devs.
During the Miro 2.5 development cycle, I've been working on getting better developer documentation cobbled together. It's a huge task that'll take us a while to do.
The initial focus of this developer documentation is two-fold:
This is important because it makes development easier for core developers, but it's even more important because it'll make it easier for casual contributors to figure out where everything is and how it works.
This is in addition to the documentation found at the Miro Development Center (aka our Trac wiki). Some content will move from the Miro Development Center to the developer docs, but we'll have both for a long time to come.
The first pass for developer documentation for Miro 2.5 is at http://pculture.org/wguaraldi/miro/2.5/developer/. It answers such questions as:
There's a lot more to do, but it'll get better over time if people spend time on it.
For those interested, I'm making heavy use of Sphinx. You can see the source from the developer documentation by clicking on the "Show source" link on the left hand side. The source for the documentation is in our svn tree at https://develop.participatoryculture.org/trac/democracy/browser/trunk/docs/developer.
I spent a few hours throwing together a new tags plugin that makes use of the new commandline features of code in PyBlosxom trunk (which will be PyBlosxom 1.5). Then I spent a while adding tags to all my entries.
I'm still mulling over my choice of tags, but I imagine I'll hone it into a set I'm happy with over time.
Also, I used :: as a tag separator, but I think I'd recommend
something that doesn't require a shift key to enter. Perhaps ;; or //.
Tag information is stored in two dicts that are pickled and thrown in a file. It seems to be pretty fast to load for my blog (~500 entries). I picked pickle because it was easy, but if it turns out to be a problem, I'd be game for other storage formats.
I've been waiting for tags support before I did more blogging. Now that I've got tags support, I plan to move my work blog here. That'll make things easier and get me off WordPress.
I finished up some additional work and I'm at a testing stage for PyBlosxom. I want to do some more testing and some documentation then it'll be ready for testing releases.
Also, I spent a couple of minutes upgrading my blog to use 1.5 in trunk. Bumped into bunch of weird issues with the comments plugin, but otherwise it was really smooth.
Participatory Culture Foundation is the non-profit organization I work for working to build a distribution system for video and audio on the Internet that has no bottlenecks, no filter points, uses open standards, and Free Software.
Most of the software that we write is written in Python. Miro, an Internet video player, is written in Python and runs on a variety of platforms. Miro Guide and Miro LocalTV are both systems that are written in Python using Django. Miro Fullscreen is written in Python using Clutter.
Python has made it possible for a very very small group of us to tackle such a large project with very limited resources.
Earlier this week, we launched our Adopt a Line of Code, a fundraising campaign to help us fund the work we're doing. No one has ever done a fundraising campaign like this before. We think it could be a good model for other Open Source and Free Software projects to raise funds.
Take a moment to check out the Adoption Center and adopt your very own line of code! Support us in our work to make video open for everyone.
It's been a long time since the last status. PyBlosxom 2.0 had been stagnating for a year and I decided to move it out of the way, put it out of its misery, and start new progress with the PyBlosxom 1.4.3 tag. I scaled back the vision and now I'm working on PyBlosxom 1.5.
I've pulled in some of the changes that were destined for 2.0 and added some new ones:
In the very near future, I plan to overhaul the website and fix project infrastructure issues.
That's where things are. Hoping to have an April release of PyBlosxom 1.5.
I spent the greater part of today adding remote control support to the Miro Fullscreen project. I thought I'd do a write up on it because there are a lot of pieces involved and it took me ages to figure it out and I'm paranoid I'll forget.
Quick caveats:
Requirements
I installed three packages: lirc, python-pylirc, and gnome-lirc-properties.
sudo apt-get install lirc python-pylirc gnome-lirc-properties
LIRC
lirc has a web-site at http://lirc.org/. I had no idea what I was looking at while wandering aimlessly through that site. I think the important pages are these:
.lircrc file format
python-pylirc
The only useful site I could find for this project was at http://pylirc.mccabe.nu/. It says that Paul Hummer took over the project and moved it to http://pylirc.ironlionsoftware.com/, but that's a dead link. I found Paul's blog at http://theironlion.net/blog/. He uses tagging on his blog, but there's only one article tagged as pylirc2 at http://theironlion.net/tag/pylirc2/. I couldn't find anything useful about pylirc, the project, its status, or what's going on. Paul suggests he was going to add LIRC support to Entertainer, but it doesn't look like he ever did that.
Anyhow, so I ended up going with the documentation on http://pylirc.mccabe.nu/ and that seemed to work out ok.
gnome-lirc-properties
I don't know if I really needed gnome-lirc-properties.
The .lircrc file
So you install the three (or two--depending on whether gnome-lirc-properties is really needed) packages and you create a .lircrc file like this:
begin
prog = mirofullscreen
button = MUTE
config = n
end
begin
prog = mirofullscreen
button = VOL_UP
config = Up
end
begin
prog = mirofullscreen
button = VOL_DOWN
config = Down
end
begin
prog = mirofullscreen
button = UP
config = Up
end
...
where prog is the string you pass to pylirc.init, button comes from the remote control lirc file and config is the string you add handling for in your application.
the Python code
The sample code at http://pylirc.mccabe.nu/?/article/articleview/Documentation/1426&themex=public gave me enough of an idea on how it worked to implement the code in Miro Fullscreen.
In closing
Hope that's useful to someone at some point.
The sordid story
I, too, was contacted by Packt Press to review Expert Python Programming by Tarek Ziadé. I finished reading the book months ago, but didn't get around to writing the review.
Then I saw the review from some person I don't know and the reply from Tarek. Tarek then went on to work through all the "bugs" and put out a new revision of the book. I still didn't get around to writing a review.
Then I saw Orestis' review. This review is pretty comprehensive. I think it covers a lot of the things I was going to say, so I'll just fill in the gaps.
The short review
The book is pretty good. It's really aggressive in that it's trying to cover a lot of ground and as such some of the chapters don't get very deep. Even so, I think the book does achieve it's mission:
There are two things I wish had been different. The first is that every chapter should have ended with a "further reading" section that listed books, magazine articles, urls and other resources that further cover the topic. That would have really helped people the book is targeting.
The other thing I wish had been different is that many of the urls used throughout the book are "fragile": they're really long, have a lot of funky bits in them, and if the owner of that site moves anything around, the url becomes a dead link. I'm not really sure how to fix this, but maybe books should have bit.ly-like links in them that redirect through the book's web-site to the url in question. When the resource at that url goes away, then the book author can change the web-site to summarize what was there or provide a different link.
If you're interested in the book
If you think that's interesting, check out the Tarek's blog entry about the book and sample chapter.
If you still like it, then it's probably worth buying or waiting for Packt Press to send you an email to review it. ;)
If you're writing code like this:
try:
foo = somevar.getBlah()["xyz"].split(".")[-1].decode("ascii", "replace")
except:
pass
Please stop! You're killing the rain forest!
In Miro, we've got long strings that are displayed in the user interface. I think the code that defines these strings is messy and hard to parse. For example:
def some_func():
description = _("""\
This is a really long description that has multiple sentences and a few \
things that need to %(getfilledin)s and it goes on and on and on and on \
and I'm not really sure what's the best way to format it so that it's happy \
in editors and easier to parse.""") % {"getfilledin": blahblah}
PEP-8 doesn't address this, which is fine. I was curious to see what other projects do.
I overhauled the PyBlosxom web-site so that it's now being statically "compiled" using PyBlosxom's static renderer. The whole thing is checked into SVN, too. That's a huge improvement from the previous situation, but the web-site could use user-interface and navigational work.
In doing that, I did a lot of futzing with static rendering using the code in trunk and fixed some issues. I also thought through the filelist implementation and re-worked it so that it handles sorting and truncating better. The results are really nice and I think it fixes all the major problems previous versions had.
GHOP was a big help. PyBlosxom had several tasks that were worked on and the results speak for themselves:
It was a huge help that these people did for PyBlosxom. I haven't fully absorbed their work yet, but it should happen before PyBlosxom 2.0 is released. Many thanks to those of you who helped out and many many thanks to Google and the GHOP, PSF, Titus, Doug, Georg, Leslie and all the others who helped make this possible. Thank you!
There are a few big things that still need to be done for PyBlosxom 2.0. I'm moving through it slowly and methodically. I was hoping to have it done by the end of December, but I'm thinking now it's going to be the end of March or thereabouts.
I released PyBlosxom 1.4.3 with better support for WSGI and Paste and
support for template variables of the form $(foo). More
information on the
PyBlosxom web-site.
I'm working on improving the PyBlosxom testing situation and in the process
of doing that ran into a problem with
nose (version 0.10.0) and
coverage (version 2.77).
Both installed with easy_install.
When running:
nosetests --verbose --with-coverage --cover-package=Pyblosxom --include unit nosetests --verbose --with-coverage --cover-package=Pyblosxom --include functional
I bumped into the problem described here (nose.python-hosting.com) and here (code.google.com). The solution is to either:
coverage.py from /usr/bin, or
/usr/bin/coverage.py to /usr/bin/coverage
I work for Participatory Culture Foundation as a developer on the Miro internet video player.
Today we released Miro 1.0. For most of the projects I've worked on, the 1.0 mark is exciting to reach, but also somewhat of a downer because it really requires you to hone the list of all possible things you could do down to a small finite list. Inevitably, there are things people will want to do that 1.0 doesn't do. Still, it's a huge milestone for the project. We're already working on post-1.0 development and making changes to decisions that didn't turn out as well as we had hoped.
A good portion of the work we do is in Python with lots of interaction between Python and libraries written in C and C++. For example, we use a lot of Pyrex to speed up critical sections.
Miro is a great product to continue to push open standards for video distribution and consumption on the Internet. I regularly watch GoogleEDU videos through Miro and I'm hoping other Python-related channels will be available as well. At some point, I'd like to create my own Python-videos channel and aggregate good Python-related video content. There's a lot of screencasts and tutorials out there....
I'm hanging out on #pyblosxom on irc.freenode.net
more often now that I'm hanging out on irc.freenode.net
for work during the day. Zeth was on today and pointed out that if
you're running PyBlosxom with
Paste, then the default configuration
doesn't allow for css and image files to be served.
This weekend, I wrote a media serving plugin for PyBlosxom which solves
this issue, but I decided to spend some time to write a WSGI application
to do the same thing and use Paste's urlmap to handle
the routing. It took 10 minutes to throw together and it works nicely.
I'll clean it up and throw it in the Trac instance tomorrow. Over time,
I'm liking WSGI more and more.
I mentored Z who was working on pyblosxom-webfront which is a web-based interface to your PyBlosxom blog.
Overall I'm pretty happy with the project. I had a pretty crazy May and June that definitely affected the first half of the project, but Z and I had a few chats just before the second half and ironed most of the issues out.
While he was working on webfront, I rolled out PyBlosxom 1.4 (and 1.4.1 and 1.4.2) which have support for Paste. Paste makes writing plugins and testing them _so_ much easier. Z also worked out some problems with making complex plugins. We should look into refactoring the comments plugin accordingly.
From here Z says he'd like to continue working on webfront and maintaining it. There are a bunch of things that it's missing, but it's a good platform to build on and it was a good experience to work with him to get there.
Thank you Google!
I'm really late to the PyPi party. Both of the projects I've worked on over the years are in PyPi, but neither are up to date and neither support easy_install.
Figured I'd update them now. Three things I bumped into while working on Lyntin:
That last one is kind of interesting. You can see the scores and the Cheesecake log output.
It's been 17 months or so since the last PyBlosxom release which for a small project is probably too long a period of time. Real life is a harsh mistress sometimes.
Changes:
w00t!
I quietly released an RC2 for PyBlosxom 1.4 today after merging in Yury's
patch for Paste support and merging in Steven's work for WSGI support.
It's really awesome to be able to do paster serve blog.ini
and have things work. At a minimum, it'll be a lot easier to test
PyBlosxom--no mucking about with web-server configurations needed anymore.
We've finished moving all the documentation from docbook to reST format. It still needs a lot of work, but we're making measurable progress which is really cool. Also, the documentation is easier to work with and maybe that reduces the amount of energy it takes for people to help out.
PyBlosxom 1.4 should be released soon. Very soon. Will it be perfect? No, but it's a huge milestone for the project. That's pretty exciting in the grand scheme of things.
06/24/2007 - Fixed "server" to "serve". I keep typing paster
server ... which is wrong.
S and I decided to get a wedding photographer in addition to allowing our guests to take as many photos as they wanted of all aspects of our wedding (except when we were getting dressed [and ... undressed]). There were a few reasons for this one of which being the several horror stories we've heard about people's digital media dying causing them to lose all pictures of their wedding. Ick.
The problem is that there are a fajillion pictures and it's really hard to order them into a single consistent timeline. The wedding photographer we had1 had four cameras and took some 800 pictures. My dad took another 100 or so. Other people took a bunch, too. Right now I'm working with 1200+ pictures all of which are pretty big (between 5 MB and 10 MB each). It's not feasible to tweak them all by hand to order them. I didn't want to leave them unordered--my soul shudders at that thought. I needed a way to do batch processing to reorder pictures from a bunch of cameras into a nice timeline.
More after the break...
Blake poked me via email and suggested I put together some ideas for a PyBlosxom GSoC project under the PSF umbrella a couple of months ago. It was a hectic time, but I threw some ideas together based on items we had in the TODO list (many of which are pretty stale at this point). I'm happy to say that we had a great proposal for building a web front end for PyBlosxom--a tool that I think a good portion of PyBlosxom users would be happy to have.
I'll be mentoring this project over the course of the summer. Z has already started working on things and I think this will turn out nicely.
As a side note, this is a huge motivator towards finishing up a release and getting out a new version of the PyBlosxom manual. On the flip side, I'm getting married in a week so I'm finding it difficult to allocate time to get the work done. Wedding planning is intense. They should use wedding planning to teach project management courses--talk about shifting requirements and general project insanity. ;)
Someone posted my article Cleaning Up PyBlosxom Using Cheesecake onto programming.reddit which was a bit of a surprise to me.
I'll keep track of the entry and the comments that it generates in case there's any feedback that would be useful for making the article better.
I saw Titus' Strangling your code and growing your test harness: ... entry and that's the process we've been using for adding a test system to PyBlosxom. We're still on step 2 or 3, though. We have unit tests for a portion of the tools module in and working but that's it. We need a setup/teardown code for testing a request on a basic blog for n variations of "basic blog". Getting there....
A few days ago, I saw on Grig's blog that Titus created a mailing list covering Testing in Python. I joined the list and it's been very educational. So far the posts have been in the "Hi--my name is _____________ (name) and I use ______________ (framework) and ___________ (framework) and ____________ (explanation for which framework gets used for which specific purposes)." Then this spawns a conversation with thoughts and insights and lots of applause. There have also been questions regarding how to use some of the frameworks and which framework would suit some need the best.
While I'm following the mailing list, I'm taking notes so that I can finish up this round of adding testing to PyBlosxom so that I can do a release this week. We're using nose and I'm using a similar structure that Cheesecake uses since I have some familiarity with their project.
It's a neat list so far. I'm glad Titus put it together--it's definitely solving my immediate needs.
My semester break is drawing short and I didn't get much of what I wanted to get done done. I merged Lance's documentation fixes in, I'm fiddling with a new pyblcmd script, and I'm cleaning up things I started, but never finished.
Ryan is going hog-wild with getting the comments plugin to a better place.
I was thinking of switching the web-site to use MediaWiki and in doing so solve a bunch of issues we have, but I think I'm going to wait on that for a while. In the meantime, I do plan on doing a web-site update and make it look more like some other Python-project web-sites. In the process of doing that, I think I may move it over to be statically rendered.
That's it for this status report--trying to keep it short and sweet while getting across that some things are happening, but it's slow going.
Many thanks to Lance and Ryan and all the other folks who have been putting time and energy into PyBlosxom over the last few months. You guys rock!
I got a few comments from people who were interested in how I used Cheesecake to clean up PyBlosxom. I tossed around making it a series of blog entries but then decided to write it up as a technical article: Cleaning Up PyBlosxom Using Cheesecake.
I think it came out nicely, though parts of it are too "wordy". I really liked writing the article using Trac's wiki system. My only problem with Trac's wiki system is that the documentation for writing wiki macros needs a lot of help.
I'm going to update some of the PyBlosxom plugin writing tutorials I wrote a couple of years ago and put them in my trac instance, too. I still have work to do with PyBlosxom, but it's coming along very nicely. I'm working on unit tests and functional tests now.
I've been following Cheesecake development with the hope that it'd be a tool that would help me fix PyBlosxom's shortcomings, make it easier for people to use, and make it easier for people to develop. It has certainly been all that and more.
I've been going through the various kwalitee measures that Cheesecake does to understand them and I've been making adjustments to PyBlosxom's source code and project infrastructure. I've made a lot of changes so far, discovered some latent bugs and code problems, documented undocumented code, fixed existing documentation, and started writing tests.
It's a huge effort, but it's a lot easier with tools like Cheesecake, nose, pylint, and coverage. Additionally, the blog entries at AgileTesting and articles at Living in an Ivory Basement have been helpful. Also, I've been shamelessly copying the infrastructure of the Cheesecake project. That's made it a lot easier to get my head around various bits.
At the moment, everything is local. I'd start checking things in but SVN at SF is really flakey (though the SF site status page doesn't mention any SVN issues).
I see the next version of PyBlosxom having some bug fixes and new features, but generally it's going to be a release focusing on cleaning up the codebase and the infrastructure.
Out of curiosity, while I'm in the process of cleaning up the codebase is it interesting to anyone for me to write up more detailed blog entries covering up how and what I'm doing? It might help by giving outlining a gameplan for cleaning up other Python-based projects. If that's something you're interested in, toss a comment on the blog or email me at willg at bluesock dot org.
I just discovered the Python Sidebar and I'm not sure how I got along without it.
I finally released the contributed plugins pack for PyBlosxom 1.3. To be honest, I really wanted to get around to testing everything more, but it's a big project and I never made the time to do it. Rather than sitting on it forever, I decided to release it now. It's vaguely possible that someone out there will download it, discover that the plugins they're interested in are terribly tested, and help fixing the real problem which is that the only testing we do on the PyBlosxom project is anecdotal testing ("well, it works for me...") by setting up some kind of magical testing framework.
More details on the PyBlosxom site.
I applied a few patches that I've received over the last month or so. I'll hopefully release the contributed plugins pack--there have been a lot of updates since I last released it (ages and ages ago).
Next step is to fold some more documentation into the manual and figure out to handle contributed plugins better. Need to figure out how to fix the problem that the ones I don't use on my blog are of unknown quality and different versions of the different plugins work with different version of PyBlosxom. I'd also like to re-organize the plugins into categories that make more sense.
At one point I was planning on building a page on the web-site tracking things that need to be done for PyBlosxom. Now I think I'll just put the list in a TODO.txt file in Subversion along with everything else. It occurs to me we probably had one at one point, but I probably deleted it.
I'm building a wedding site that contains mostly static material but has some material that's reminsicent of CMS and some material that's database-driven, too.
I surveyed the scene of Python web-frameworks and settled on Pylons for various reasons but mostly because:
I've spent 40 minutes or so fiddling with the site so far with only a
few minor issues which required me to go poking through documentation.
One of the issues is that I have a series of templates in my templates/
dir and I uncommented out the commented out code in the
template.py controller so it's like this:
from weddingwww.lib.base import *
class TemplateController(BaseController):
def view(self, url):
from pkg_resources import resource_exists
if resource_exists('weddingwww', url+'.myt'):
m.subexec(url+'.myt')
else:
m.abort(404, "File not found '%s'" % url)
That doesn't seem to work as I'd expect. For example, if I go to
http://localhost:5000/meeting, the url parameter
ends up as meeting but the resources_exist returns a false
even though there's a meeting.myt file in my templates
directory.
After fiddling with this and trying to figure out where pkg_resources is defined, I just commented the code out and changed it to this:
from weddingwww.lib.base import *
class TemplateController(BaseController):
def view(self, url):
m.subexec(url+'.myt')
which obviously does the wrong thing if the file doesn't exist.
SourceForge 1 now has Subversion access to project stuff so I migrated the CVS repository of all PyBlosxom things over to Subversion. Then I tested it out to make sure it works. So far it seems much easier to deal with in the grand scheme of things. I'll probably write more when I find something to kvetch about. :)
[1] For some reason, I keep typing "SourceForget"--not sure why.
Bunch of bug-fixes for things I didn't catch the first time around.
Changes:
It's a good release. Many thanks to Norbert (current Debian packager), Joey, Joerg, and the many people who upgraded to PyBlosxom 1.3 despite the fact we have no regression or unit testing system [1]--they are brave people.
[1] - This is a bad thing--we should fix this.
Norbert took over Debian packaging and has sent me a plethora of fixes, questions, and errata most of which I've applied, replied to, or at least thought about. Martin has also sent in several issues that will be fixed for PyBlosxom 1.3.1. Additionally, I went through all the bug reports on the SourceForge bugtracker and dealt with them.
In the process of doing all that, there were a bunch of bugs with 1.3 that got fixed. I also fixed Joey's problem regarding num_entries behavior. I'm re-thinking how some of PyBlosxom works (or doesn't work) and I've gotten all excited about making some changes.
I've done another huge push on the manual fixing a bunch of minor issues and folding documentation that existed in other places into the manual in the proper places. The manual is in docbook format and when I compile it (or whatever the verb should be) into a PDF, it clocks in at 76 pages. It's definitely the longest manual I've ever written. As time goes on, it gets more and more comprehensive. I hope people use it if only because I've spent days writing, honing, editing, and cursing it.
Next week some time (time-willing), I'll do another pass at overhauling the web-site and fixing the massive problem with plugins that we have. The issue is that I don't want to be doing contributed plugin packs--it's a pain in the ass and none of them are tested except the ones I use. On top of that, over the years people stop hosting their plugins which has caused some of the entries in the registry to become obsolete. I'm going to switch how I do things, ditch the registry plugin, and change the system so that the site hosts all the plugins that are offered. I'm also going to enforce some rules regarding things plugins need to have in order to be added to the registry.
Many apologies for the length of time that this has taken me to complete.
Changes:
Plugins that work for PyBlosxom 1.2 should continue to work with 1.3.
Overall, I'm pretty happy with it. It's not everything I originally set out to do, but it's a good amount of work for a release. Many many thanks to everyone who helped out.
You can download it from the PyBlosxom website.
I'm releasing PyBlosxom 1.3 release candidate 1. w00t! A lot of work has gone into this and it's taken way way way too long to finally get it out. My apologies to everyone who's been waiting and such.
Changes between 1.2 and 1.3
Pertinent to users:
We added a "blog_rights" property. This holds a textual description of the rights you give to others who read your blog. Leaving this blank or not filling it in will affect the RSS 2.0 and ATOM 1.0 feeds.
If you set "flavourdir" in your config.py file, you have to put your flavour files in that directory tree. If you don't set "flavourdir", then PyBlosxom expects to find your flavour files in your "datadir".
The flavour overhaul is backwards compatible with previous PyBlosxom versions. So if you want to upgrade your blog, but don't want to move your flavour files to a new directory, DON'T set your "flavourdir" property.
Moved the content that was in README to CHANGELOG.
You can now organize the directory hierarchy of your blog by date. For example, you could create a category for each year and put posts for that year in that year (2003, 2004, 2005, ...). Previously URLs requesting "2003", "2004", ... would get parsed as dates and would pull blog entries by mtime and not by category.
Logging works now. The following configuration properties are useful for determining whether events in PyBlosxom are logged and what will get logged:
It's likely you'll want to set log_file and log_level and that's it. Omit log_file and logging will fall back to stderr which usually gets logged to your web-server's error log.
Pertinent to developers and plugin developers:
Nothing that I know of. Everything should work pretty much the same.
Download, comments, et al
Download it at http://www.bluesock.org/~willg/download/.
It's been locally tested (my blog has been running the version in CVS for over a month now), but not globally tested. While I'm pretty confident that it should be ok for most people, I'm sure there are some issues that have fallen through the cracks of our total lack of regression testing and unit testing environment.
As such, I heartily encourage anyone still using PyBlosxom to set it up locally and run it through the steps that your blog entails and let me know this week whether there are any issues.
If I don't hear from anyone by Saturday, I'll just release it at my leisure.
The future
This is it for me. This release fixes a bunch of flavour issues that needed fixing. It also includes a much better version of the manual and some work has gone into making it more Python-standards compliant.
Over the last 9 months, the world of web-application development and Python web-application development has changed radically. I'm a little tempted to re-write PyBlosxom using Paste, but I don't think it really helps our "typical user" much and I'm not sure it makes sense given that there are a variety of other weblog applications out there that are well-established and have more momentum.
As such, I'll be helping with minor bug fixes and that's it.
Happy new year!
My blog has been going up and down a lot over the last few days as I'm getting the kinks out of some code I re-wrote in PyBlosxom and searching for other issues. I've successfully transitioned to the new included RSS 2.0 feed without disturbing any of the planets that I'm on. Things are looking good so far. Release soon!
I re-wrote blosxom_path_info_handler and cleaned it up a lot. The adjustments also allow people to create categories that look like dates (and previously would get interpreted as dates and screw things up).
I'm going through the documentation, the bug list, and a couple of other changes I want to make. I'll also tackle any low-hanging fruit that's on my todo list. Otherwise, I consider PyBlosxom 1.3 pretty complete. If all goes as I plan, it'll be out before Christmas in some form.
I've been running my blog on the latest code and keeping track of all exceptions that get thrown and any other odd issues and things seem to be going well. As such, I'll be preparing to do a release candidate soon and then start the mildly painful process of re-writing the appropriate sections of the PyBlosxom manual.
I'm also taking some time to run Cheesecake against the codebase. The results so far are somewhat of a bummer:
[cheesecake:console] Detailed info available in log file /tmp/cheesecake_sandbox /pyblosxom-1.3.tar.gz.log [cheesecake:console] A given package can currently reach a MAXIMUM number of 560 points [cheesecake:console] Starting computation of Cheesecake index for package 'pyblosxom-1.3.tar.gz' index_unpack .................. 25 (package untar-ed successfully) index_unpack_dir .............. 15 (unpack directory is pyblosxom-1.3 as expected) index_install ................. 0 (could not install package in /tmp/cheesecake_sandbox/tmp_install_pyblosxom-1.3) index_file_announce ........... 0 (file not found) index_file_changelog .......... 10 (file found) index_file_ez_setup.py ........ 0 (file not found) index_file_faq ................ 0 (file not found) index_file_install ............ 10 (file found) index_file_license ............ 10 (file found) index_file_news ............... 0 (file not found) index_file_pkg-info ........... 10 (file found) index_file_readme ............. 15 (critical file found) index_file_setup.py ........... 15 (critical file found) index_file_thanks ............. 0 (file not found) index_file_todo ............... 0 (file not found) index_dir_demo ................ 0 (directory not found) index_dir_doc ................. 25 (critical directory found) index_dir_example ............. 0 (directory not found) index_dir_test ................ 0 (directory not found) index_docstrings .............. 70 (found 264/382=69.11% modules/classes/methods/functions with docstrings) index_pylint .................. 68 (average score is 6.77 out of 10) =================================== ABSOLUTE CHEESECAKE INDEX ..... 273 RELATIVE CHEESECAKE INDEX ..... 48 (273 out of a maximum of 560 points is 48%)
So, 273 out of 560... Could be worse, but should be a lot better.
The code seems to be working nicely so far. There's one piece I still want to code before a PyBlosxom 1.3 rc release. I still have to go through the manual, update the content, and do some more work on organization. It's likely I won't get to work on it until the end of the semester, so that puts the next release some time at the end of December.
I re-re-wrote the flavour template code for the upcoming PyBlosxom 1.3 release. It works like this now:
This allows you to put all your flavour files in a flavour directory that you specify in your config.py file.
This allows you to put all the flavour files in a taste.flav directory (for example, html.flav, happygoodness.flav, rss20.flav, atom10.flav, ...).This allows you to override individual template files from the default flavours. For example, if you wanted to add RSS enclosures, you can put a story.rss file in your $datadir/, $flavourdir/, $datadir/rss.flav/, or $flavourdir/rss.flav/ directory (depending on how you set things up) with the enclosure markup in it and PyBlosxom will pull the default rss templates and use your story.rss template.
This allows you to override individual template files depending on what category the user is looking at.
This makes it easier to package and distribute flavour packs because they can all sit in a single directory all by themselves.
There should be no backwards-compatibility issues with the new code between PyBlosxom 1.2 and 1.3.
NOTE: The code needs to bake a bit. I tested a lot of combinations of things, but I'm still finding occasional issues. This blog is using the latest code, so if you find any issues, write a comment below (assuming that's not broken) and I'll fix the issue.
I have one more big thing on my list of things to do for PyBlosxom 1.3. After that I'll probably release an RC1. Depending on school work, that could happen in the next few weeks. If you want to see the code now, get it from CVS (instructions for CVS access here).
I was talking with Josh the other day and he told me that I should take the time to learn Subversion and switch over rather than investing more time to tame my projects with CVS and CVSTrac. So I spent a good portion of today moving my PyBlosxom plugins (the ones that I wrote and/or maintain on my own) to a Subversion repository and Trac.
There are a couple of things that will take getting used to, but overall I've been able to replicate everything I did with CVS in Subversion.
I'm still making modifications to the setup, but I'll be hosting all my PyBlosxom plugins work at http://www.bluesock.org/~willg/cgi-bin/pybltrac.cgi/. I've allowed anonymous ticket creation for feature requests, bug reports, and the like. If you're sitting on issues, patches, and things of that nature, feel free to submit them.
I've been following (very loosely) Ian Bicking's (ianbicking.org) paste progress and it's really amazing stuff. Today, I bumped into his screencast on Ajaxy exception catching. That was really cool and I could see how it could be immensely helpful with debugging/fixing PyBlosxom plugins.
I'm adding "investigate porting PyBlosxom to paste" to my todo list for winter break; paste looks seriously awesome.
I'm going to release the PyBlosxom contributed plugins pack 1.2.3 for PyBlosxom 1.2 in the next couple of days. So if anyone is sitting on any fixes that need to go on, let me know soon.
This has a few fixes here and there--some of which are cosmetic. It also has a behavior fix for the comments plugin so that comments are shown if you have ?showcomments=yes in the querystring as well as when the specific story is viewed.
Prior to today, I was maintaining all my PyBlosxom plugins by hand... which was kind of stupid, but I hadn't really gotten around to investigating better solutions.
However, that day has come! I've pulled them all into a CVS repository and set up CVSTrac to manage documentation, bugs, features, and allow people to see version history for all of them. I'm in the process of going through all the plugins, adding CVS tags, updating copyright dates, fixing documentation, adding notes in regards to where the plugin is maintained and all that.
I aim to make the end result more organized for me and users looking for plugins and also require less effort to maintain.
I merged all the changes I've made in the PYBLOSXOM_1_2 branch back into HEAD. Now I'm in HEAD and I'm going to do PyBlosxom 1.3 work until I'm ready to release. At that point, I'll make another branch for PyBlosxom 1.3 fixes and such.
I've got the following items in my todo list for PyBlosxom 1.3:
Why make this PyBlosxom 1.3 and not another minor 1.2 revision? Well, it has to do with the adjustments needed to fix bug 1202107. PyBlosxom checks the content-type to see if it's xml and if it is, then it escapes the $title and $body variables which drives everyone trying to do an xhtml or other xml output crazy. The only ways to fix the issue is to do a hack on the hack or introduce a backwards-incompatible change. Given that I'm more interested in the latter, I figured it's better to bump the version so that it's clearer that the user will need to make some adjustments to their PyBlosxom configuration when they upgrade.
[1] $title_encoded, $body_encoded, rfc822 date, iso8601 date,
and possibly other stuff
[2] If you want to help with building flavours, let me know.
8/6/2005 - I added bug 1252678 to the list of bugs to be fixed in PyBlosxom 1.3.
Wow! Martin wrote up a howto for installing PyBlosxom on Debian for multiple people.
There's a series of things here I don't really know about (e.g. what kinds of things should go in /srv?). At some point, I'd like to fix PyBlosxom so it's more "standard" in terms of installation and configuration for web applications.
Here's the link for configs/pyblosxom which walks through installing a single software installation on Debian for multiple people.
Joseph pointed out a problem where IE 6 won't display a cached page when it gets a 304 from the conditionalhttp plugin. (The issue is at the bottom of the email.)
I did some poking around and discovered on Wednesday that this happens on his blog as well as on my blog with IE 6 on Windows XP. On Thursday, I was no longer able to reproduce the problem on my site, but Joseph's was still broken. I don't know off hand what changed with my site, though I did do an apt-get update Wednesday night.
Anyhow, the 304 response from my site (which seems to work fine now) is (note the server line is wrapped):
HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:32:26 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4 \
PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d DAV/1.0.3
ETag: "1119536230.43"
Last-Modified: Thu, 23 Jun 2005 14:17:10 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
And from Joseph's site (which is still not working):
HTTP/1.1 304 Not Modified Date: Thu, 23 Jun 2005 14:37:15 GMT Server: Apache/2.0.46 (Red Hat) Connection: Keep-Alive Keep-Alive: timeout=5, max=100 ETag: "1118428239.0" Vary: Accept-Encoding,User-Agent =bunch of funky non-printable characters here=
Looking at responses from other requests to Joseph's server leads me to believe that pages are gzipped. I'm not sure if that's part of the issue or not.
My site: http://www.bluesock.org/~willg/blog/
Joseph's site: http://reagle.org/joseph/blog/
I'm running PyBlosxom 1.2.1 with the contributed plugins pack 1.2.2 with conditionalhttp. I think Joseph is as well. I have no idea if this is affecting anyone else--no one else has complained on the mailing lists or anywhere else that I've checked.
Anyone have any ideas as to what might be happening?
This is the third release of the contributed plugins pack for PyBlosxom 1.2.
Here's the list of changes between contributed pack 1.2.1 and 1.2.2:
GeneralThanks to Steven, David, Joseph, Matej, and Nathaniel for their contributions and help.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
Find the contributed plugin pack here (contrib.1.2.2.tar.gz).
This is the second release of the contributed plugins pack for PyBlosxom 1.2. In terms of functionality, there were a bunch of fixes to the comments and trackbacks components and I overhauled pycategories. Beyond that, there were a lot of license changes (or in most cases license applications) and some documentation changes. In general, this release is a huge milestone for sorting out the big mess that was the contributed plugins.
Bravo to Wari, Ted, Steven, Blake, Bill, and everyone else that was involved in pulling this together.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
Find the contributed plugin pack here (contrib.1.2.1.tar.gz).
Seems like it's ok so far. So I released it rather than continuing to sit on it. I've done a lot of work on the manual to cover the areas that were covered poorly or not covered at all. There's still a lot of material to cover, but we're definitely making measurable progress in that direction.
Steven Armstrong did a lot of work to get mod_python, WSGI, and Twisted supported. I'm not sure why anyone would use WSGI or Twisted, though, since they don't appear to make much difference in how fast PyBlosxom works. mod_python definitely helps, though. Steven has some runtime statistics here.
This feels like a good release. We met some goals, we didn't sit on it forever, the documentation is an order of magnitude better than it was for the previous version (though it has a long way to go, still), and we fixed a bunch of bugs.
Having said that, it's definitely not necessary for people to upgrade. I think if your blog works and you don't need to futz with it to get additional functionality, leave well enough alone.
I'm almost done the next version of the PyBlosxom manual. At the suggestion of Steven, I converted the manual thus far from html to docbook. I still need to do a lot of work in terms of indexing and adding warnings and notes and various other indicators like that. I'm busy re-writing chapters to reflect issues people are having on the pyblosxom-users list.
I think I've worked between 20 and 30 hours on it over the last week and a half--it's almost like another part time job.
We're going to try to push out PyBlosxom 1.2 in the next week or two. Steven did a lot of work fixing up static rendering and also fixing the architecture pieces that caused PyBlosxom to kind of suck when used in various frameworks like WSGI, Twisted and mod_python. I'm also going to do another round of documentation content.
We're going to push fixing the file handling to the next version. We want to allow for index caching and also reduce the number of times PyBlosxom walks your blogdir for entries. Both of these new abilities will significantly reduce the time it takes for large blogs to render. Getting there....
The plan is to have these changes in before Ted's talk at PyCon.
Got the notice from Network Solutions today stating that unless I renew right this second, the domain name is free again for anyone's taking.
I had worked with George to get Planet PyBlosxom up and running, but he seems to have paged out and hasn't responded to the last few emails I've sent.
It was an interesting thing to run for a year.
In lieu of other solutions, I'm going to start releasing contributed plugins plugin packs. This one should work with PyBlosxom 1.1.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
If this works out, then I'll continue releasing contributed plugin packs that match up to PyBlosxom.
Find the contributed plugin pack here (contrib.1.1.tar.gz).
02/23/2005: Changed the url. Decided to do an actual "release" and store it on the PyBlosxom site.
Steven's been doing development on PyBlosxom to allow for other frameworks than plain CGI. The architecture changes he's making solves some other issues as well. The problem we've bumped into is that one of the things he wants to do requires us to change the minimum Python version from 2.1 to 2.2.
Details here.
Bill noted that it's likely that PyBlosxom won't work in 2.1 as it is now anyhow. I'm not sure--I don't have Python 2.1 anymore.
So the question is would it be ok to change the minimum requirements. Some folks who cannot change the version of Python they have will have issues with this (obviously), but is it a good idea anyhow? Is the world at a place where it's common to require at least Python 2.2 a for projects?
A while back, I adjusted the comments plugin locally so that it would allow me to have plugins that change the template type they use from "story" to other things. A couple of months ago, I sent Ted an email with which pieces go in which templates. Figured I'd stick that here in case someone is looking for it.
This is only for the "story" section. The head template goes before and the foot template goes after this example. This also only works with the latest version of the comments plugin that has the template stomping code removed.
<div class="news"> <- story.html <h2>$title</h2> | <div class="content"> | ... | </div> | links | </div> <- <div class="comments"> <- comment-story.html <div class="comment"> <- comment.html Posted by $blah at $blah | $blah | </div> <- <div class="comment"> <- comment.html Posted by $blah at $blah | $blah | </div> <- <div class="commentform"> <- comment-form.html form stuff here. | </div> | </div> <-
I finally got around to releasing PyBlosxom 1.1. The big change is that I'm only planning to work on and maintain the core--I'm hoping someone will come along and pick up maintenance for all the contributed plugins. I haven't figured out what the contingency plan will be. I might maintain that too, but whine about it very loudly until someone gets tired of me whining. I'm also slowly getting through working on the documentation. I noticed that the wiki that I'm basing a portion of my documentation on disappears every now and then. So... I'm thinking that's a good sign that I should finish up quickly.
George called me up and offered to take Planet PyBlosxom off my hands. I want to pass off all the little things to other people in the PyBlosxom community so that:
In the meantime, I'm working on finishing reading Dive Into Python. It's one of those books I wished I had read years ago. I got a hard-copy from my parents for Christmas. I've put a halt on coding until I'm done.
I was checking my apache logs and noticed there are dozens of feed readers pulling my RSS data. They're not pulling index.xml--which is the RSS 2.0 nicely-rendered data, but rather the RSS 0.9.1 flavour that comes by default with PyBlosxom.
The problems with this are two-fold. First, I don't have num_entries set in config.py. So every time someone requests the RSS 0.9.1 feed, they get all of my entries. It's around 340K or so. I'm amazed no one ever complained about this. If they had, I would have told them to get the other feed--the one I advertise--instead.
The second problem is that I didn't have the conditionalhttp plugin running. So every time someone requested the RSS 0.9.1 feed, they get all my entries--even if I haven't added any new ones since the last time they requested it.
I couldn't adjust the num_entries property in my config.py file, though, because it would mess up my paging plugin. So I tossed things around a bit and decided to add this code to my config.py file:
import os
query_string = os.environ.get("QUERY_STRING", "")
if query_string.find("flav=rss") != -1:
py['num_entries'] = 20
This code checks to see if someone is grabbing the RSS flavour of my blog which is my unadvertised-I-wish-no-one-would-request-it RSS 0.9.1 feed and set the num_entries property to 20. Otherwise, it doesn't get set.
Then I tossed in the conditionalhttp plugin which does the whole last-modified thing further reducing the amount of bandwidth I'm burning away pointlessly.
I gave Bill Mill CVS checkin permissions the other day. He's interested in working on the static rendering and the problems of storing metadata. The former (static rendering), I'm psyched to pass off to someone who will work on it and fix the various issues it has. At a bare minimum, I'm psyched to pass it off to someone who wants to think about it.
The latter (metadata) is something we need to figure out how to deal with and soonish. The pyblosxom-users and pyblosxom-devel mailing lists have had several people pop up with their own ideas about what constitutes metadata, where it should be stored, how it should be stored, and how to access it. But few, if any, of the proposals seem to be in-line with the PyBlosxom mission. Though maybe it's not clear what the mission is. That's a topic for another entry.
Bottom line is that I'm going to hold off on releasing pyblosxom 1.1 for a few days in case Bill wants to change things.
Bill Mill's weblog is here. He talks a bit about metadata in entries and del.icio.us-style keywords.
Also, SourceForge is finally getting around to updating their web-servers and are planning to install a version of Python greater than 1.5.2. When that happens, I'm going to re-do and move the PlanetPyBlosxom web-site. I'm hoping Wari will approve moving the PyBlosxom main site as well. If he does that, then I want to merge the two sites, fix our problems with documentation, and centralize everything under one big project web-site that's agnostic of the people involved. That's a bit project. It may be that I'll wait to do pyblosxom 1.1 release until after the "big move".
A while back, several people offered to help out but I severely lacked the resources to sort everything out to take that offer. I'm hoping to make development much easier for people who want to hop in, implement a feature they need, and hop back out again and also make room for growing PyBlosxom beyond its blosxom roots.
So that's the update. Any thoughts or comments, leave them below.
I think I've removed over 100 spam comments from my blog in the last 48 hours. I'm a little tired of it, so I added a few obvious words to my word blacklist and then I went and modified the comments plugin to allow for "draft" status.
Then I wrote a small script that goes through the directory, finds all the comments in draft status, prints each comment to the screen and asks me what I want to do with it. That'll prevent comments from getting published without my manual approval.
It's interesting to note that many/most of the comment spam are comments on my entries on comment spam. Amusing....
I finished taking the GRE so now I'm going to start the long process of moving everything in /contrib to the registry, moving the flavours to the registry, and then going through the steps to release PyBlosxom 1.1.
We'll do an RC and wait a week for people to speak up about issues. That puts a PyBlosxom 1.1 release around the end of October. Things that will be in the release:
We're also removing the contrib directory and all the flavour examples. This is probably going to be controversial, but I don't think we have enough polish to continue distributing them with PyBlosxom and it'll be easier to distribute fixes and such if they're separate from the PyBlosxom release.
It's getting to be a drag when the nicest comments I get from my blog are comment spam for a casino site. "Thanks for the great work!" "That entry was really helpful!" "It's really nice to have people like you around!"
If I were a less self-confident person, I'd filter out the actual spam part (usually the web address) and leave the rest of the comment be. I'm sure these spam folk mean everything they say.
I'm going to spruce up the comments plugin that comes with PyBlosxom. I'm going to merge the changes I've made locally with the contributed version:
I may incorporate the changes that Jesus did or at least figure out how to make that a plugin kind of thing.
Also, there should be a way to kick back messages to the user who just did stuff with the comment form. Then we can kick back messages when comments are rejected and accepted for better usability.
09-27-2004: Updated "John" to "Jesus"--I totally got his name wrong. Oops.
Brett discovered some issues with booklist as it interacts with comments. So this fixes those issues.
You should note that if you're using booklist and comments, you should have at least 2 books in your list. Otherwise comments sees it as a single entry, decides to show comments for it, and then stomps on the property in the entry that dictates which template to use. That's a bug in comments that needs to get fixed.
Get it on my pyblosxom plugins listing
Fixed encoding issues and some other things. Thanks Aslak!
Get it on my pyblosxom plugins listing
There are a few people doing analysis on the tools.Walk chain with the hope of slimming it down because it's one of the corner issues with PyBlosxom scaling up to thousands of entries. I don't really have time today to look at them (I'm at work right now), but I will (hopefully) soon and hopefully this spawns a discussion that results in better PyBlosxom code.
There's been a flurry of email on the PyBlosxom mailing lists over the last month. I'm totally buried at the moment, so I haven't had time to go through them and figure out what it all means in the grand scheme of things.
I updated the todo list with everything in my head right now (though I'm sure there's other things floating around that aren't on that page).
Robert Wall is working on doing analysis on PyBlosxom and coming up with some code to fix issues he's uncovering.
Hopefully, his work and the work of others will result in some big fixes to PyBlosxom that will (hopefully) simplify the architecture, reduce the number of performance issues, and open up more possibilities.
I also finished up work on Planet PyBlosxom which I had been threatening to do for a while now.
Lots of progress, though. I wish I had more free time to help grease the skids a bit.
It's really neat to watch skilled project managers step up to the podium and in a few paragraphs walk through what's happened, what the options are, why he/she is choosing a specific option, and then examine the process through which they arrived at that option and suggest ways of fixing the process itself. I've always loved to work for project managers that are highly aware of the immediate problems as well as the processes and machinery we're using to solve those problems and can actively tweak both.
Anyhow, Guido has written up his thoughts on the J2 proposal and seems like they're sticking with the <at> proposal. I honestly don't even know what decorators do--so I don't really know enough to care one way or another. I really hope some day soon I get some time to Dive into Python and catch up on some of the language features I'm really missing out on. It'd help my projects out a _bunch_.
Fixed a bug where categories with four letter names were getting picked up even if the name wasn't all digits. Thanks Ludvig Omholt!
Pick up the new plugin here: my pyblosxom plugins.
I decided to release my old set of flavour templates on the flavour registry and in so doing totally foobarred all the times on all the files of my blog. I recovered most of them (because I have a mirror that's usually off by a few days), but then I had to guess on the times for the latest four entries.
So that sucked. Given what I just went through, I'm beginning to think it's a terrible idea to use the timestamp on the file as the mtime. Blech.
I didn't expect either of these entries to drum up the response they did. I've gotten emails and comments from both entries that were way cool.
As a result, I've finally gotten around to building the flavour registry, I decided I'm going to see what's up and whether I'll work through a 1.1 release for PyBlosxom. We're working through what to do in regards to the filestat callback and possibly moving caching. I started investigating what would be involved in building a regression testing framework (which would double as a performance testing framework as well).
It's been a good couple of days. I really appreciate the advice and encouragement I've gotten. Thanks!
David Ascher started using PyBlosxom and there are a couple of other users who look like they're just starting to use it as well. I think that's fantastic--especially given that the project is on life support right now.
Life support? What makes me say that? Well, I've been threatening to do a 1.0.1 release for months but never did it. Development has all but stopped because there aren't any active developers. Back when I released 1.0, I told people I wasn't going to touch it for 6 months because I was really burned out on this project and I had too many other things going on. So then nothing happened except a mild trickle on the mailing lists.
I'm not sure what to do. I can't really take on another project and push it through the motions. PyBlosxom has documentation, but it's mediocre and has large gaps and it's spread across two sites one of which I don't think most people get to. The debian maintainer for the PyBlosxom package needs help updating the package, but I don't know enough about packages to help and haven't had the time to work on it. There has been some interest in a flavour registry, but it seems that there's only interest from a "we want a flavour registry" perspective and very very little to no interest from a "I'd like to contribute to a flavour registry" perspective. Blah blah blah.
There are a bunch of issues and no one to solve them. I'm really hesitant to throw my energy at this project again. Part of me wonders if I should just start solving some of the smaller problems that need to get solved (lack of testing infrastructure, lack of centralized documentation, ...) and then go from ther step by step. Seems so overwhelming.
Not to mention that my life is a mess right now--I'm still moving and I've got a list of promises I haven't fulfilled dating back to two or three years ago. Then I got bitched out on one of the projects I work on for being an elitist egomaniac. I just want to help identify and fix problems to make things better/easier/faster/more useful! Is that so wrong? I'm just one man! Gah!
I got a comment from David Ascher on this entry which pointed out some issues with the wbgamazon plugin. After a few minutes, I fixed the problems listed and released a new version.
I've blogged for so many months now that the Archives listing on the side was getting pretty long. I don't really want a long list of months and years there, so I was looking for options.
Ned Batchelder lists his archives by year. For each year, there's a summary page by month which lists the dates and titles of all blog entries for that month. I really liked this idea, so I wrote my own archives plugin to use it. It's not exactly the same--the output is slightly different. It's good enough for me, though.
I noticed that almost all the comment spam I get has the word "casino" in it. I added some code to the comment plugin to check the comment for the word casino and if the word is there, I ditch the comment. That seems to work very nicely (in the last 24 hours, it's ditched 7 bad comments and no good ones) though it's a short-term fix.
Long-term, I have a few thoughts. I may re-write portions of the comments plugin so that it saves comments originally in an "approval" stage. Then I'll write a command-line program that allows me to approve or reject all the comments in the "approval" stage one by one. That'll be pretty easy to deal with though it introduces a time-delay between when a comment is created and when it is posted.
Alternatively, I could just write a command-line program that goes through all the comments since the last one I "approved" and allows me to go through them one by one and weed out the bad ones.
Still, given that my blogs aren't related to casinos in any way, using "casino" seems to be a good filter.
Turns out it was creating garbled yucky stuff that hosed my RSS 0.91 feed. I fixed it so that if it thinks it's outputting to an RSS feed, it just returns rather than doing the transformation.
I should look into making this a postformatter--that would be better.
Ahhh--just got hit with my first comment-spam experience. That kind of sucked but was pretty easy to deal with since Ted organized comments as separate files.
If it happens again, I'll have to think about how to deal with it. Maybe switch to a comment approval process or something.
I got a bunch of really helpful responses from my previous entry and I'm pretty sure that my problems were two-fold: my code was missing some stuff (the code I posted and what I actually had were different--go figure) and my testing program had a bug (or two or three).
Anyhow, my knowledge of file locking on Linux (and possibly other Unixs) is pretty abundant now (or so I think). This helped to fix a problem I had at work as well (not the file locking part, but the thing I needed file locking for helped me at work).
Python has the fcntl module which has a flock and
lockf. I'm not entirely sure what the difference is, but
there are man pages on both functions as the Python versions call their
C counter-parts.
There's a good article on file locking that might be located at /usr/src/linux/Documentation/mandatory.txt (though it wasn't on my system--a Google search helped me out) that's pretty interesting. Also, there's explanations of file locking between processes and the issues involved in Advanced Programming in the Unix Environment and Linux Application Development.
My specific issue was with Exim and PINE. Both have documentation as to how they lock mbox files before playing with them--things a Google search reveals without much effort.
Anyhow, I'm pretty sure my code works now. I'll do some more sophisticated testing this weekend to make sure everything is kosher.
Thanks to Chris, Jason, John and Lance for their help.
![]() |
Linux Application Development |
![]() |
Advanced Programming in the Unix Environment |
I wrote my own web-mail client (bluemail) because I wanted a web-mail client that would work along-side PINE and figured I'd just roll my own in Python. I work on it from time to time--mostly when someone requests new features. Right now I'm trying to implement deleting of items in a given folder.
The problem I'm having is a file locking issue. When the user clicks on the INBOX link, it opens up their inbox file (an mbox file in /var/spool/mail/) as the user. That works super. I parse out the mbox and display a bunch of email one-liners. The problem comes in that I can't seem to open the file as r+, lock it, parse it into email, change some of the email (whether by deleting the email from the mbox file or changing the attributes of the email [i.e. marking the email as having been answered]), then write the changed file back to disk without the possibility of having another process (our MTA, for example) slipping in and changing the file beneath me.
Right now, I open the file like this:
import fcntl
f = open("/some/file", "r+")
fcntl.flock(f, fcntl.LOCK_EX)
That should work fine (as far as my research has told me). I did notice some places that say that LOCK_EX only works when you open the file in "a" or "w" mode, but I've got it opened as "r+" which means I'm going to update it later, so I'm puzzled.
Anyhow, using the code above doesn't seem to lock the file. I can run the above code thereby "locking" the file and then in another process open the file, read the file, and write to it. That indicates to me that it's not really locked.
Any ideas how I can resolve this? I need to be able to open a file for reading and updating and lock it so that other processes can't change the file between my read and update cycles. I'm running the code on a Debian GNU/Linux box with Python 2.3.
I think I may release 1.0.1 this weekend depending on what else is going on life-wise. I tossed a feeler email out to the dev list in regards to what else should be fixed for 1.0.1, but didn't get anything back--which isn't surprising as people are pretty busy these days.
So... to do a release or not--that is the question. Is there anyone reading this blog who has things that they'd like to see for a very minor fix-it point release that's doable by one man who only has a bit of free time (unless they're interested in sending in a patch)?
I've noticed while working on PyBlosxom that bugs can literally be reported anywhere. Not only that, but people get annoyed (really annoyed) when you don't respond to their bug report which was reported using a method that I never would have dreamed of. We've had reports in all the following places:
It takes a huge amount of time to check all these places--many of which come and go. It really puzzles me why people don't try to be more social and send bug reports via channels that other projects typically use (bug trackers, mailing lists, and IRC). I've been trying to coerce people into a few standard channels, but it's really hard on a project like this and there's a lot of resistance.
Bottom line is that this kind of thing really affects the project's quality. There are bugs out there that I will never trip over that someone else did but because they chose to whisper it into their pillow at night rather than tell someone about it, the bug won't get fixed and will trip someone else up.
I thought blogs were supposed to be social tools to enhance communities and promote discussion.
Anyhow, we can only do the best that we can do.
We've cleaned up a lot code and documentation and fixed a lot of bugs. We've stabilized the API and added static rendering. In short, this should be a pretty solid 1.0 milestone for PyBlosxom.
I encourage people to upgrade. When you untar the distribution tarball, read through INSTALL and README. These files will walk you through installation and upgrading from 0.9.
Download it at https://sourceforge.net/project/showfiles.php?group_id=67445.
Personally, I'm glad we finally pushed out 1.0. I'm not sure it's a perfect release, but it's good enough for a 1.0 milestone and I feel good about releasing it at this point. It's hard to push a project through to a release when there's not much feedback from testing and usage of previous alphas and release candidates. I think at some point you just have to bite the bullet and push it out and see how it does.
Cheers to the PyBlosxom development crew!
I'm releasing pyblosxom 1.0 RC1 right now. I overhauled the callback documentation in the ReadMeForPlugins file and read through other documentation and I think we're good enough for a 1.0 release now.
The RC1 is at http://bluesock.org/~willg/dev/pyblosxom/pyblosxom-1.0-RC1.tar.gz.
Feel free to download it and test it out--it's very much like alpha1 with a few differences:
That's about it, I think.
In the tar.gz file is an INSTALL file which details installing PyBlosxom. There is also a README which talks about differences between 0.9 and 1.0 (which will help you upgrade an existing PyBlosxom installation).
Let me know what you think. I plan on doing a 1.0 release in the next few days. Probably Thursday.
I keep bumping into circular import problems. While some say it's a symptom of bad design, I'm not wholly sure I agree. Some systems are just really complex. Not everything can be refactored into a pretty little UML diagram.
Anyhow, there's a link on daily python url to Victor Ng's blog entry on his experience with circular import problems with Python. The comments of that blog entry are wonderfully enlightening.
I added the Request object to the locals for eval_python_block. I also did away with the "printout" kluge I had--you can use print now.
If you used an old version and are upgrading to this version, you'll need to convert all your "printout" function calls to regular print statements.
Find it in my plugin index.
Yay--it's released! Now I can sleep at night again and dream of iplementing static rendering.
I decided the registry plugin needed to allow users to see all the pending submissions and details therein. So I made some changes:
Get it on my pyblosxom page.
This is a better columnize function. Though I'd be curious to see which one was "faster" to process. Next rainy day I get, I'll benchmark them.
There are some minor tweaks, but more importantly, I added the ability to evaluate python code blocks in the static page. Find it in my plugin index.
I whipped up a plugin that changes the renderer to the debug renderer if there's a "debug=yes" in the querystring. It's not wildly exciting, but it works nicely and I can debug things without necessarily taking my entire blog down.
Get it at my plugin index.
I've been in some kind of neat motivational kick the last few days to update my plugins. This time, I've overhauled the registry plugin that Wari uses for the Pyblosxom web-site.
Changes:
Anyhow, if you were one of the one or two people that were using it, this is definitely worth updating to. If you need help reconfiguring it or if you have problems, let me know.
It can be downloaded at my pyblosxom page.
(snuck it in just before the end of the year--yay!)
I was poking through other peoples' blogs and bumped into one that mentioned a bunch of things I should do to my booklist plugin to fix it. One of which involved switching it from hard-coded html to use pyblosxom flavours. So I did that work and some other neatening up and released it. Get it on my pyblosxom page.
So I've been lurking on python-dev for almost a year now. I think it's been a year--might be more. I forget. My friend just sent his first post to python-dev. This is what he said:
I'd like to suggest "outer v" for this. The behavior could be to scan outward for the first definition of v. If the only outer-scope variable is at module-level, then the behavior would be the same as "global v". Or if everyone is comfortable enough re-using the keyword "global", then I also like "global v in f".
It was pretty exciting. So I asked him how he felt. To this he responded, "naked".
Josh discovered a page on the Python wiki that talks about Large Python Projects. Turns out that Lyntin is one of three listed. There are probably a lot of other large Python projects out there so that doesn't really mean quite what we think it means. Anyhow, they list us as having 11,856 lines of code back in July of 2002.
Josh and I then used their pycount.py script to figure out how many lines we have now and discovered we have 14,024 total lines (listing here) of which 6,157 lines are actual code, 4,649 are doc-strings and 1,171 are comments. That means that 41.5% of our code-base is documentation. That's pretty cool. How many projects can say that about themselves?
I re-wrote my calendar utility (which tells me what my schedule looks like when I log in) in Python. This is good because I haven't touched Perl in some time and I wanted to add some other formats to it (like handling "second thursday" and "*/15") and I wasn't looking forward to figuring out what I wrote many years ago.
I also re-wrote my logger at work. It's not really a logger--it's more of a log extrapolator. It takes all these fun bits and puts them in places where I can glance over them quickly and guess at what happened rather than reading all the gory details and know enough to write a thesis.
Then I wanted to add a calendar to pyblosxom. So I adjusted the code to handle drop-in plugins and threw together a pycalendar thingy. It's not great but it works and it's not half-bad for an hour of coding.
All contents Copyright 1996 to 2010 Will Guaraldi Kahn-Greene.
This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.