Zope

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note: First of all, apologies for the cross-posting. I wanted to reach as many people as possible. On Monday, May 10 (tomorrow) one of the Zope Foundation-maintained servers will be physically ... [More] moved to a different data center by our hosting provider. The server will be shut down at around 20:00 UTC and, according to the hosting provider, become available again no later than 05:30 UTC the next day (May 11). As you can see from the list of services affected below the impact will be minimal. Services affected ================= - - the zope2.zope.org website - - backup mail services Server shutdown =============== Monday, May 10 20:00 UTC - 22:00 CEST/Berlin - 16:00 EDT/New York - May 11 06:00 EST/Sydney Server start ============ On or before Tuesday, May 11 05:30 UTC - 07:30 CEST/Berlin - 01:30 EDT/New York - 15:30 EST/Sydney I will send a reminder a few hours before the move. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin [Less]

Your chance to shape an update to Professional Plone Development As rumoured, there will be an update to Professional Plone Development that covers Plone 4. A lot has happened in the two-and-a-half years since the first edition was published. Plone ... [More] has evolved. Important third party tools such as Buildout and Paster have become mainstream. New tools, such as mr.developer and XDV are rapidly going the same way. There are lots of things I'd like to update, some things I want to remove, and much new content I want to add. However, I need your help. I want to make sure that this new edition is at least as successful as the first edition, which helped define "best practice" for a lot of new and maturing Plone developers. If you are (or would like to be) a Plone developer and you are interested in Plone 4, I'd love to know: What topics you're most interested in learning aboutIf you have read the first edition of Professional Plone Development: Which chapters you didn't like or found confusingWhat content you feel is out of date or obsoleteWhat, if anything, might entice you to purchase a second edition :-) Please email me ([email protected]) your comments, or - if you prefer - leave a comment below with your thoughts and (hopefully constructive) criticism. P.S. I will be starting work on the new edition in the coming weeks. I won't make any promises about a publication date, except perhaps to say that I'd be very disappointed if it didn't hit the shelves this year, and hopeful that it'll be available not too long after the final Plone 4 release date. Read into that what you wish. :-) [Less]

A little demo (and the idea behind) for collective.portlettabber product

Agendaless will be doing a WSGI training at Penn State's Business College on the third tutorial day of the PSE conference Moonshining: Making WSGI for Fun and Profit Abstract The Python web development world has adopted on WSGI as an ... [More] interoperability standard for Python web servers, applications, and middleware components. This tutorial examines that specification in detail, and shows practical examples of using WSGI to improve development productivity, integrate applications, and solve various deployment problems. Topics PEP 333: the WSGI spec Using "stock" WSGI tools paster mod_wsgi Extending the WSGI application middleware paste templates paster configuration Practical applications Debugging errors with WSGI Profiling / instrumenting a WSGI application Unified authentication via repoze.who Unified skinning via Deliverance Duration One day. Cost $150 per student. Includes a copy of the 'repoze.bfg' book. Register Via PayPal You can pay online with a credit card using PayPal: Student name    Register Using Alternate Payment If paying via PayPal is not an option for you, please send us an email to make other arrangements. [Less]

Plone give us the right way to hide elements from the HTML page! Just use it... but what about jQuery?

As the clock counts down to the release of a brand new Plone 4, events take center stage for the Plone community. World Plone Day just finished demoing Plone to the planet, Plone is represented at next week’s CMS Expo in Chicago, and regional Plone ... [More] conferences are taking place on both sides of the Atlantic at the end of May — at Penn State University in the U.S, and Sorrento, Italy. [Less]

---

Yesterday I hinted on a post on zope.testing and Python 3, and here it is. Almost all zope.something modules uses zope.testing for it’s tests. It does this in two ways, the testrunner and zope.testing.doctest. This means that to port zope.something ... [More] to Python 3, you first need to port zope.testing to Python 3. Except of course, it uses zope.interface, and zope.interface uses zope.testing and you get a Catch 22. I solved this for zope.testing’s dependencies by making it possible for their tests to be run also with Distributes test runner. It’s not as advanced as the Zope test runner, most annoyingly there is no easy way to run just a subset of the tests, but it did the job. This also avoid the use of zc.buildout, which also hasn’t been ported to Python 3, and also depends on zope.testing, so in this way I could start bootstrapping the Python 3 port of the Zope Toolkit. Extracting the test runner But zope.testing also depends on zope.testing. Most specifically, it depends on Zopes test runner to run the tests, so much so that running them with Distributes test runner will fail. I did succeed in porting it to Python 3, but it was a pain, and I didn’t feel good about it. When looking at it again in December, I decided the port was such a hacky mess that I started over. One of the things I did that time was to build a custom test command for setup.py, so that I could use Zope’s test runner to run the tests. This was an improvement, but still messy. The final outcome of this was the idea to extract the test runner into it’s own module. I did this, and zope.testrunner was released in a beta yesterday. As you see I messed up the formatting of the documentation, and I also forgot to move zope.testing.exceptions to zope.testrunner, I’ll do that in a beta 2 soon. This means zope.testrunner will not depend on zope.testing at all. Also, this extraction means zope.testing will not depend on zope.testrunner. The tests that are left in zope.testing can be run with Distributes test runner. Removing doctest The Zope community has been on the forefront of doctests. In fact, The Zope community has tended to overuse doctests, and used them instead of unittests, which is wrong and evil. Doctests should be for testing documentation, not documenting tests. The doctest module wasn’t included in the stdlib until Python 2.4, but Zope 3 was running on earlier versions. To solve this in the days before buildouts, zope.testing simply included it’s own copy of doctest.py. However, it has not been kept in sync with the stdlibs since 2004, and stdlibs doctest has many, many bugfixes that zope.tetsing.doctest doesn’t have. And, funnily, it’s also the other way around, zope.testing.doctest has both fixed some bugs, and even introduced some features that the standard doctest doesn’t have. However, porting zope.testing.doctest, with it’s bugs, to Python 3 would be ridiculous, not to mention difficult, but the two doctests has diverged enough to not be fully compatible. After some discussion about this, we decided to simply drop zope.testing.doctest. It has been deprecated since Christmas. Since this will be a backwards incompatible version of zope.testing, we decided to also not have any BBB imports of zope.testing.testrunner or zope.testing.exceptions. We’ll release a version with these deprecated as well in the near future. After that I’ll merge the changes to trunk, and sometimes reasonably soon, hopefully in May, a zope.testing 4.0.0 will be released with Python 3 support. We’ll continue to maintain and release zope.testing 3.9 to the end of the year. Migrating to zope.testing 4.0 and zope.testrunner 4.0 If you use the zope.testrunner, you most likely use it via zc.buildout and the zc.receipe.testrunner module. It will be updated to use zope.testrunner instead, and most likely you’ll not even notice that you are using zope.testrunner instead of zope.testing.testrunner, as initial tests indicate that they are fully compatible. However, dropping zope.testing.doctest is a different matter, as there are some substantial differences. Footnotes First of all zope.testing.doctest has support for using code in footnotes as setup code. Stdlibs doctest doesn’t. If you need this feature you should migrate your doctests to use Manuel. Globals The doctests using zope.testing.doctest will inherit the TestCases globals. Stdlib doctest doesn’t do this. You’ll have to pass in these variables explicitly instead. Returning unicode There is a bug in Stdlibs doctest. If one doctest returns a unicode object, all subsequent testresults will be converted to unicode as well. This is not a problem unless you then return a non-ascii string, when you’ll get a unicode decode error. To fix this, don’t return unicode, rather test for equality with the expected unicode string. DOS linefeeds in Unix If you have a doctest with DOS/Windows linefeeds in Unix, it will fail, complaining on inconsistent whitespace. To solve this, don’t have DOS linefeeds on Unix. Your version control system will handle this if you don’t mess it up. REPORT_ONLY_FIRST_FAILURE and REPORT_xDIFF Stdlibs doctest will not allow you to override reportflags in your test. So if you explicitly in the test set that the test should have a REPORT_NDIFF flag, for example, even if you tell the testrunner to use UDIFF, this will be ignored. That kinda makes sense, I suppose. However, REPORT_ONLY_FIRST_FAILURE is also a report flag and will also be ignored, so if you have a test where you set a diff flag, passing -1 to the test runner will be ignored, which is highly annoying. zope.monkeypatches.doctest These last three bugs have been reported with patches to Pythons bugtracker, but they are likely to be ignored. Only the last one is a problem in Python 3, btw. As a part of the Python 3 port of zope.testing I also converted zope.testing.doctest to a set of monkey patches of stdlibs doctest. Although it was decided to not keep these patches and just drop doctest, I created a product called zope.monkeypatches.doctest. It’s not released yet, and won’t be released unless these bugs turn out to be big real life problems. But they are there and will be preserved there until I’m sure these bugs aren’t big problems. That’s it for now! Filed under: plone, python, python 3000, python3, zope, zope3 [Less]

About two years ago, I took my first look at Python 3. I liked what I saw, and as I also adore the Zope Component Architecture, I wanted it on Python 3. so I started porting it. But to develop Zope packages you typically need zc.buildout. So I needed ... [More] to port it. But it in turned required Setuptools. So I started porting that, and realized that Setuptools was a complex piece of software, and stopped. But in August 2008 I tried again, and got further. That effort finally came to fruition as Martin von Löwis reviewed my port and merged it with various improvements into Distribute, released in September 2009. I have from time to time returned to my quest to get zope.component ported to Python 3, and after about two years, a second milestone has finally happened: I released zope.interface 3.6.0, the first version that supports Python 3. Hopefully we’ll see zope.event and zope.exceptions in Python 3 versions too. I’ve merged Python 3 support into trunk for these already, but I want to let zope.interface simmer for a while, to make sure I didn’t make any mistakes in the release. Next is zope.testing. And that requires a post of it’s own. Edit: I should mention that I wasn’t the only one involved in this port. In particular Martin v Löwis (again) supplied that port of the C-code. Thank him too. Filed under: plone, python, python 3000, python3, zope, zope3 [Less]