The second edition of Porting to Python 3 is now available as paperback as well as PDF!
Porting to Python 3 is the most complete source available to help you with making your Python code run on Python 3.
It’s available as paperback from many channels:
- Directly from Createspace
- Amazon: .com, .co.uk, .de, .es, .fr, .it
- On other Amazons (but via resellers)
- If you want to more than ten, contact me: firstname.lastname@example.org
It’s also available as PDF! When you buy the PDF you get three PDF’s, adapted for screen/print, tablets and phones.
The book gets right to the point, without a lot of fluff and filler – Doug Hellmann
A concise, well-organised and complete reference – Richard Jones
Update: After another bug report I realized I didn’t have a check that there are distributions uploaded to the Cheeseshop. This despite being a pet peeve of mine that people don’t upload distributions to the Cheeseshop. So I released 1.4, with an additional check for this.
Pyroma rhymes with aroma, and is a product aimed at giving a rating of how well a Python project complies with the best practices of the Python packaging ecosystem, primarily PyPI, pip, Distribute etc, as well as a list of issues that could be improved.
The aim of this is both to help people make a project that is nice and usable, but also to improve the quality of Python third-party software, making it easier and more enjoyable to use the vast array of available modules for Python.
Pyroma 1.3.1 fixes a small bug and improves the integration with zest.releaser for a smoother release experience.
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?