openpyxl 1.5.0 released

It has been almost one full year since I started this project, and it has now reached a state where it is well suited for production, and intensively tested by an increasing number of people around the globe.

The most recent additions I’m the most proud of are the optimized reader and writer, that become stable in this version. It took around 6 months to get them working properly (the reader was the hardest actually), and now they’re here !

You can read and write workbooks of any size, with low and almost constant memory consumption (which is not the case with Excel actually).

I’m also really happy that people keep sending patches and asking for features, so the project continues to live, even when I’m not fully available to work on it.

You can get the latest version of openpyxl either with easy_install:


easy_install openpyxl

or from the official website.

Advertisements

openpyxl turns 1.1

After two weeks of intense activity around openpyxl, I’m releasing version 1.1 today. This new version brings support for dates and number formats.

Several bugs have been fixed, thanks to the careful testing of two new contributors, Jonathan Peirce and Yaroslav Halchenko, both working on the PsychoPy project.

Thanks guys for boosting my morale, providing valuable advises and patches !

Many thanks goes to Marko Loparic for his support and enthusiasm 😉

You can get the sources for the latest version here http://bitbucket.org/ericgazoni/openpyxl. I expect a lot of bug reports with this new version, as it is stable but not extensively tested yet, and that the number of possibilities have seriously increased with the introduction of number formatting.

Keep in mind that the memory footprint is still high, but that it is the target for milestone 1.2. It should perform reasonably well if your needs are moderate (<100.000 cells), but if you want to add more data, then it might start consuming RAM pretty quickly. This holds for writing and reading.

Memory consumption is almost linear, and a 15MB workbook results in 450MB in RAM.

There is also a new mailing list for the project: http://groups.google.com/group/openpyxl-users. It’s pretty empty for now, but feel free to ask questions there, I’ll be reading it regularly.

Bug reports will be better handled if they are filed on the project bug tracker: http://bitbucket.org/ericgazoni/openpyxl/issues/new.

Happy coding !

Flexibility

IT projects, like tattoos, are commitments. You wouldn’t accept that kind of answer from a tattoo artist, it’s your body, you have the right to change your mind as long as the ink is not under your skin. Why would that be different for software development ? Why would requirements be written into stone once they were signed ?

One could explain the too common attitude towards change by two main factors:

  • process momentum
  • stability issues

Process momentum is the consequence of everyone trying to protect their butt from backfires in case of project failure. As long as you can blame someone else for failure, you think you are safe, but in companies, the way to design the scapegoat is by signing contracts, SLAs, and other forms of paperwork. Every time you make a change in the requirement, someone can feel the contract terms have changed, and therefore, his paper walls are not protecting him anymore. Therefore, either you don’t make changes, either you spend a lot of valuable time to sign agreements.

Stability issues are the quicksand in which developers who don’t practice testing at a sufficient level are thrown when the requirements drift too much from the initial requests. That’s the typical “We will soon release a patch to fix the bugs introduced by previous patch. Sorry for the inconvenience.”. When you designed things like this and they end up looking like this.

The Agile manifesto states “Customer collaboration over contract negotiation”. Customer don’t change the requirements because they are evil, or helpless, but because they found a new way to improve their work. That’s what we do, helping them get their work done, and if possible, done better than their competitors. Don’t think of change as a mutation, but as an evolution.

If our quadruped, monkey-smelling ancestors decided that “walking on our rear limbs was not part of the original design”, just imagine where we would be now. Evolution is the way every live being manages to keep up with changes in its environment. Not changing (or changing two years too late), means putting your own kind in danger. If you eat beef and the new breed of beefs grows two more legs, you’d better find a way to continue chasing them, either by becoming smarter, either increasing your muscular mass (or number of legs, but that’s just gross).

If you eat money, and the competitor grows a new technology to eat more money than you (and possibly start eating your money), you’d better evolve your own tech right now !

Continue reading