svg.path is a collection of objects that implement the different path commands in SVG, and a parser for SVG path definitions. It supports Python 2.6 to 3.3.
It’s main use is to parse an SVG path specification and then you can extract points on that path. You can also easily manipulate the path, but 1.0 doesn’t contain support to render paths back to SVG specs. I hope to get time for this in the future, contributions are welcome.
svg.path 1.0 fixes a bug when handling path specifications that use no spaces and have negative numbers.
svg.path is put into an svg.namespace to allow for other modules using the same principles that can handle other parts of the SVG spec. I currently have no need for anything than the path bit of the specifications, but other modules are welcome there as well. Please contact me to make sure the API follows the same principles so that the modules are easily inoperable.
collective.blog.*, or just blog.star for short, is a suite of blogging modules for Plone. It is primarily designed for integrators. Most people who use Plone for blogging also uses Plone as a customized content management system, and they have specific requirements and their own skin, custom content types and other integrations. It turned out that other Plone blogging products make a lot of assumption about how you are to use it, what you want from a blog, and how your site is set up. The blog.star modules are modular, make few assumptions and reuse already existing technology as far as possible.
blog.star 1.2’s main feature is that it now supports Plone 4.3. This has in some cases required quite big changes. For example, collective.blog.feeds will under Plone 4.3 rely on Plone 4.3’s built-in Syndication functionality. collective.blog.view also has quite substantial changes.
Language support is also vastly improved, but many of the latest features has created new strings which remain untranslated, help with updating translations and adding new translations are appreciated.
It’s been far too long since I released a new version of blog.star, which is entirely because of lack of time. If somebody is interested in taking over maintenance, email me.
Version 2.1’s main feature is that it adds Plone 4.3 support.
Once again I have been contacted by a consulting firm who asks if I can help them with some specific problem. Some quick poking reveals that the problem is that they are trying to develop a site in Python with Plone, and that they don’t know either Python or Plone. However, since they know ASP or PHP, they simply have assumed that they can do this, because it has to be the same, right? It’s just the same principals but another language?
Well, no it isn’t. And the end result is that they have problems, because they are doing things they should not be doing. And the way to fix those problems, is to stop doing it.
I’ve told them that they have two options:
- Hire somebody to teach them Python and Plone and Plone development, which will probably encompass at least two weeks of education for all of their developers, and even after that they will be very inefficient and it will take a long time to make the site.
- Cut their losses, tell their customer that they can’t do it, and take the hit of not getting paid for the effort they have put in so far.
I’m sure this hurts, but it’s true. Python is not like PHP or ASP, and Plone is not a web framework, it is a content management application. You can’t start using either without some investment in learning the technology. And there is another lesson here too: When a company tells you they can implement a complex website for a pittance, be prepared that what they come up with is no good. Assuming they come up with anything at all, that is.
Hire a contractor who knows the technology that is selected and is recommended by other people who also knows the technology that is selected. Yes, that will cost more. You won’t be able to hire the $25 per hour guys. But trust me: It is cheaper in the long run. Quality pays, and this is true also for contractors.
I’ve been thinking a lot about this lately, and I realize this is probably a question that can only be answered by actually trying, but still, I think it’s an interesting discussion to be had.
To what extent would it be useful to make a web application, such as a CMS, massively parallell? (or for that matter, concurrent, see comments)
And with that I mean, would it make sense to break the typical one thread per request model? Could we break it up so that fetching from the database is made in different threads or processes than rendering the template? Could the rendering be split up into smaller bits, so that parts of the template could be rendered while the data is still being fetched from the database? Are there other things that could be split up and made parallel?
You can now buy Porting to Python 3 as PDF, and enjoy it even when you are offline!
You’ll get a ZIP file with three PDF’s, one made for a typical computer/laptop screen and printer, with nice big margins. It will print well on both A4 and Letter paper. Another PDF is formatted to fit well when reading on a tablet, and the last one is made as small as possible, so you can read it on your smartphone.
All three PDF’s for the low price of $12.
I have definitely never been so ambitious about a conference ever before, and to a large extent this as came out nicely. In fact in my huge list of ambitions I only failed in one thing.
I wanted to use impress.js for my presentation. But already in September it was clear to me that I didn’t want to write the HTML directly, as I did when preparing an earlier version of the talk for PyCon PL. I wanted to use ReStructuredText. And I wanted to position the slides somewhat automatically. This ambition lead to the following for goals:
- Create a presentation software that uses ReStructuredText to generate impress.js-style presentations.
- Create a library to handle SVG paths.
- Update Pyroma so tests run on Python 3.3, so I can use it on the software I make.
- Update my talk to use ReStructuredText, and make the slides more useful by themselves.
All of these goals were fulfilled.
- The presentation software is called Hovercraft! and 1.0 was released the 22nd of February. Three main presentations and one lightning talk used Hovercraft! during PyCon, which I declare a success!
- The SVG path library that Hovercraft! uses for it’s most complicated and likely least useful feature: Positioning along SVG Paths, is called, unsurprisingly svg.path.
- Pyroma was updated for Python 3.3. It also got some cleanup and now installs hooks for zest.releaser, so it will run Pyroma on the package before releasing.
- I updated my talk to use ReStructuredText, and it now has better slides. It also available on video.
If you really want to see somebody use Hovercraft! in a useful way, check out Chris Withers talk “Things to make writing tests easier“, where he is using the pan and zoom features to increased pedagogical effect, which is absolutely awesome! Look for example at 5 minutes into the talk.
I have also the last few months been writing a Python Enhancement Proposal on getting full time zone support into Python 3.4. It was important to get that PEP reasonably finished before PyCon, as I intended to implement it during the sprints. The idea here was that I would more or less merge pytz into the standard library, with just a bit of refactoring. And this is the ambition that I failed to achieve. Mostly the failure is related to the way pytz works around some limitations in the datetime library. Since we are now enhancing the datetime library, we don’t want to work around those limitations, but we want to instead fix them. Doing that the simple way turned out to be impossible, and the result is instead that timezone support needs to be more or less reimplemented from scratch. The three days I was sprinting ended up with me diving deep into both pytz and also dateutil.tz, comparing them and deciding what needed to be done, so that I now have a plan.
An implementation of the time zone support for Python 3.4 will therefore have to wait a bit, although I still aim to have it done by the first Python 3.4 alpha, which is planned for August.
Now, doing a good presentation and implementing a PEP are reasonable goals for a PyCon, even if it’s a bit over the top to have to write your own presentation tool for it. But I didn’t stop there, oh no! I also decided to update my book on Porting to Python 3. So both leading up to and during the conference I would sit and go through the changes needed to update it for Python 3.3, and on Sunday of the conference I released the second edition of the book! I had hoped to do the release during a lightning talk but competition for those were so tight that it was practically impossible to get them. So I released it during a countdown in the green room instead, with the event captured by David Kua.
The book is now 14 pages longer, includes examples for Unicode-aware sorting and how to deal with the changes in the CSV API and many minor improvements. It is currently only available as HTML, but I hope to get time to make PDF versions in the near future. Perhaps it will even be available in paper again. Only time will tell.
The Plone RV
The last ambition of mine was to also have fun! This was made much easier thanks to the Plone Community having a strong presence on this years PyCon. This was to a large extent thanks to the amazing Spanky and Liz, who not only manned a Plone booth in the expo hall and held a Plone poster session, but also rented an RV, so that us Plonistas could avoid the amazingly boring Santa Clara (the conference center was great, but it is a mile long walk even to the closest restaurant) and instead go into San Francisco every night, and back to PyCon in the morning!
This impeded on my contributing to evening activities such as the Porting to Python 3 clinic, and evening sprinting, but on the other hand, the trips in the RV were a hoot. I’ll probably opt for a hotel room in the future anyway, they are warmer, and it’s less competition for the shower.
Sometimes making a release of a software makes it used, and people come with bug reports and suggestion for improvements and the end result is that you make a lot more releases very quickly.
I wrote Pyroma, a module to check the quality of your Python modules packaging, just before PyCon 2011, and during the sprint I extended it to be more useful. It didn’t get a lot of attention so that was it. I run it from time to time on my own packages, to make sure they are OK.
Then, yesterday, almost two years later, I decided to run it on Hovercraft! to make sure the package data was good. But since I’ve developed Hovercraft! primarily using Python 3.3, and I never even ran Pyroma under Python 3.3, so I decide to first make sure the tests for Pyroma run. They don’t. This turns out to be just testing-errors, but still. I fix the tests and decide to release 1.0. It has after all been stable for two years. Mostly because only I used it.
Well, this time it got re-tweeted a bit, and it immediately turns out it doesn’t work with Twisted. I add some support for that use case and release 1.1 just hours later.
More tweets shows up check-manifest, a new package from Marius Gedminas that checks that the files specified by MANIFEST.in matches the ones checked into the VCS, which is usually what you want. Someone says that the release software zest.releaser should do these checks. Turns out zest.releaser has hooks for that, and Marius adds check-manifest to them, so when you now call fullrelease, check-manifest is called. Well, that’s a great idea, so I now add a hook for pyroma as well! And 1.2 gets released, just the day after 1.0 and 1.1. :-) Well, it happens.
Anyway, the end result of this frenzy is quite nice. If you now install zest.releaser, check-manifest and pyroma, you get a triple whammy of:
1. A software that will make releases quick and painless.
2. A check that your MANIFEST.in file is correct before the release is done.
3. A check that the release-tag will have sane metadata before uploading to PyPI.
All by just typing “fullrelease” and pressing enter a couple of times. :-)
Well, I like it.
Pyroma checks your Python packages friendliness to packaging tools and other Python tools. Some of the things it looks at is if you have filled in all the meta data you should fill in, that there are tests and that they pass.
New in Pyroma 1.0 is official support for Python 3.3 (it worked before, but wasn’t tested) and a test that the packages version complies with PEP-386.