November 2016 - Zope-Dev

Port a bunch packages to github
by Michael Howitz 11 Nov '16

11 Nov '16

Hi! I use the following packages in a project. I realized that they are not yet moved to github. zope.broken z3c.preference z3c.authviewlet z3c.i18n z3c.locales z3c.wizard zodbupdate Is there anybody so kind to do the migration for me or give me the knowledge and power to do it myself? (Maybe I even find the time to port them to Python 3.) Thanks in advance, Michael Howitz

2 4

zope-tests -
by Zope tests summarizer 11 Nov '16

11 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-09 00:00:00 UTC and 2016-11-10 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0

Zope 2/4/5 Roadmap
by Hanno Schlichting 10 Nov '16

10 Nov '16

Hi. We've had some roadmap discussions at the recent Zope Resurrection Sprint and at the current PyCon Germany conference. I'll try to summarize the consensus we've reached among those in attendance at the events, trying to see what others think of the plan. The current main motivation for any new Zope release seems to be Python 3 compatibility. There's little interest in any new features in the Zope Toolkit or other dependencies outside of Python 3 support. Based on this and given the progress already made, it seems that the main feature of the next Zope 4 release should be Python 3 compatibility. Releasing a major new Zope version before this goal is reached seems to make no sense, as there are few if any consumers of the framework who would use it. I think it is achievable to release a final Zope 4 version with Python 3 support in mid to late 2017, but as with any volunteer based project it will take as long as it needs to. In order to speed up the process, there are various sprints being planned. Looking at the work that happened on Zope master thus far (https://zope.readthedocs.io/en/latest/WHATSNEW.html) there also seems to be support for the changes made, with the exception of the "ZMI simplification" part. I'll work on reverting the changes I did to reduce the ZMI functionality over the next weeks, to get parity again with Zope 2.13. In order to keep the scope of the next release manageable, I'd also like to avoid adding any other major breaking changes to it. For example there's long been talk about replacing DateTime with Python's built-in datetime, adding parent pointers to avoid implicit Acquisition or others. All of those are on the table for a Zope 5 release in the future, but I don't think they should go into Zope 4. At this point Zope 5 has no clearly defined feature set or a target release date. This is an overview of the general plan, if there's interest I can provide more details about the features already implemented and the current status of the porting effort, if you haven't followed the changes on Github. Acting as interim Zope-release-manager, Hanno

2 1

zope-tests -
by Zope tests summarizer 10 Nov '16

10 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-08 00:00:00 UTC and 2016-11-09 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0

zope-tests -
by Zope tests summarizer 09 Nov '16

09 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-07 00:00:00 UTC and 2016-11-08 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0

zope-tests -
by Zope tests summarizer 08 Nov '16

08 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-06 00:00:00 UTC and 2016-11-07 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0

Re: [Zope-dev] Intercepting __getattr__ in a Python 2.3 old-style mixin class?
by Andreas Jung 07 Nov '16

07 Nov '16

Python 2.7 is different because all classes are automatically new-style classes. In Python 2.7 you would have to overwrite __getattribute__() but I am on Python 2.3 here. And I have to stay on Python 2.3 for now…welcome to hell :-) Andreas On 7 Nov 2016, at 13:23, Michael Howitz wrote: > Am 07.11.2016 um 13:01 schrieb Andreas Jung <lists(a)zopyx.com>: >> I have a large Python 2.3 based installation with 200k LOC. As part of a migration project I need to intercept all attribute lookups of all old-style class. >> >> Old legacy code: >> >> class Foo(Bar): >> ... >> >> >> My idea is to inject a common mixin class like >> >> class Foo(Bar, Mixin): >> ... >> >> class Mixin: >> >> def __getattr__(self, k) >> print repr(self), k >> return Foo.__getattr__(self, k) > > Hi Andreas, > > I doubt that your approach works. Attributes defined on `Foo` are _not_ resolved using __getattr__. > See the following example using Python 2.7: > > In [1]: 1 class A: > 2 x = 'foo' > 3 def __getattr__(self, key): > 4 return 'bar' > > In [2]: a = A() > > In [3]: a.x > Out[3]: 'foo' > > In [4]: a.b = 'b' > > In [5]: a.b > Out[5]: 'b' > > Maybe I am missing something here. > > -- > Mit freundlichen Grüßen > Michael Howitz >

3 2

Intercepting __getattr__ in a Python 2.3 old-style mixin class?
by Andreas Jung 07 Nov '16

07 Nov '16

I have a large Python 2.3 based installation with 200k LOC. As part of a migration project I need to intercept all attribute lookups of all old-style class. Old legacy code: class Foo(Bar): ... My idea is to inject a common mixin class like class Foo(Bar, Mixin): ... class Mixin: def __getattr__(self, k) print repr(self), k return Foo.__getattr__(self, k) However I am running always into a recursion because Foo.__getattr__ resolves to Mixin.__getattr__. (The migrated code has to run under Python 2.3 as the first step of the migration where will be moving forward to Python 2.7 later on). Is there any way to fix the code for Python 2.3 old-style classes? -aj

1 0

zope-tests -
by Zope tests summarizer 07 Nov '16

07 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-05 00:00:00 UTC and 2016-11-06 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0

zope-tests -
by Zope tests summarizer 06 Nov '16

06 Nov '16

This is the summary for test reports received on the zope-tests list between 2016-11-04 00:00:00 UTC and 2016-11-05 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Non-OK results --------------

1 0