It supports Python 2.5, 2.6, 2.7, 3.1, 3.2 and 3.3, as well as Jython and PyPy.
Version 1.0 adds a couple of bug fixes, mainly related to giving better error messages when deducing the time zone fails.
I’ve gone through my modules on the CheeseShop and made sure the information about them is up to date. Most importantly, I’ve marked the following modules as “Development Status :: 7 – Inactive“:
- calcore: This is a module that Martijn Faassen and me write that has the Python core of a calendaring system. It was pretty nice, but only ever used by Nuxeo.
- collective.portlet.quote: Shows random quotes in a portlets, chosen from quotes in a folder. I developed this for project at Jarn.
- megrok.genshi: Genshi template support for Grok. Mostly it was used as use case for making Grok support other templates. I don’t think nobody ever used it, though.
- p4a.calendar: This module, originally by Rocky Burt (I think) once contained views for p4a.plonecalendar, but the project since a long time uses dateable.chronos instead.
I don’t think anyone is actually using these packages any more, but if you do, please tell me and you can take over maintenance.
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.