Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tres Seaver wrote: I'm OK with having in-tree code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that janitorial deprecation is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the better name. The ongoing cost of that deprecation is then borne by everyone else. +10 Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Christian Theune wrote:
Why? Because we keep changing stuff and don't tell people in VERY LARGE
LETTERS about it.
Actually, you highlighted the wrong bit, the important bit is:
BECAUSE WE KEEP CHANGING STUFF
Using Zope 3, and Zope 2 since the Zope 3 stuff started getting merged
in is like trying to see the bottom of a lake when boats are
continuously churning up the silt as they go past.
It's the churn that's the killer...
Please note, I'm not saying this change is bad or that people should
stop introducing new features, I'm just pointing out that change means
that anyone exposed to change has to re-learn stuff.
Now, my judgement call on all this is that not enough attention is being
given to this re-learning overhead. Tres highlighted the extreme end
of this where spellings and names are changed almost for the sake of it.
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
Sure, having to do:
to_change = {}
if obj.hasProperty(x):
to_change[x]=x_value
else:
obj.manage_addProperty(x,x_value,x_type)
obj.manage_changeProperties(**to_change)
...and remembering that manage_editProperties is BAD isn't that pretty,
but it's been stable for so long that I can write it from memory now,
and that's a big win.
So, for me, it would be great if developers would take more time to
weigh up the what does this new feature or refactoring bring against
the how much of a PITA is it going to be for everyone else to relearn
this...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Christian Theune wrote: this is a rant. I don't want to be destructive or disruptive, but I feel like I need to turn this up right now. Let's start with something positive: I love Zope 3. I do. I know it almost since the beginning and I see how it works out. But to be honest, I too often get the feeling that something in the process is wrong and we are failing to acknowledge it or work on it. I think we make it way to hard for people who want to use Zope 3 as developers making applications with Zope 3. Why? Because we keep changing stuff and don't tell people in VERY LARGE LETTERS about it. I've been arguing for release notes in an earlier discussion. People generally were of the opinion that the proposals are enough. This makes clear that they're not. :) I'd still advocate a document or set of documents per release that details what changes have been made and how your code should change, and not to rely on the proposals on the web in our release documentation. If the proposal makes for perfect release documentation already, then it should also be easy for you to include it in the Zope source tree. So, my proposal for Zope 3.4: * have a developer_notes file or directory somewhere. * let this contain the developer-visible changes. * it should be focused on how to change your code. That's the important bit. Motivations and such might also be useful to have there, but the main thing should be: this change from so and so to so and so, so to make this work, do the following. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Martijn Faassen wrote: So, my proposal for Zope 3.4: * have a developer_notes file or directory somewhere. * let this contain the developer-visible changes. * it should be focused on how to change your code. That's the important bit. Motivations and such might also be useful to have there, but the main thing should be: this change from so and so to so and so, so to make this work, do the following. +10 - this is becoming really important to us Plone people, since we have some code that needs 2.8 compatability, and some that will probably be 2.10 or 2.11 going forward. People see examples in the 2.8-compatible code and try to follow them, and then end up doing silly things. Even those of us who are pretty close to the core get confused sometimes. Here's the kind of thing I'd love to see, in a clear, well-structured document: subscriber ZCML directive -- The 'factory' attribute has been renamed 'handlers' because (whatever good reason??). Instead, you should now do subscriber handler=.module.method for=.interfaces.ISomeEvent / The important things are (a) it's easy to find this by skimming through a document (oh, I'm pretty sure I'm using a subscriber somewhere); (b) there is some rationale. This makes the change easier to remember than just having a blind rule to follow, and allows us to scrutinise changes more; (c) there is a clear example of how it should be done - examples may not speak more than 1,000 words but they're good for 500 at least. This type of document would need to be written by someone who understands the changes, and probably by one or two people not a dozen. A CHANGELOG is mostly useless because it contains too much detail and not enough context. It's fine as an audit trail, but it's very hard to put changes in the context of your own code if they're structured cronoligically and limited to a few key words on a line or two. If anything, this may make me bug philiKON a bit less on IRC ... :-) Martin -- View this message in context: http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.html#a6133275 Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Dieter Maurer wrote: Tres Seaver wrote at 2006-9-2 13:03 -0400: ... I'm OK with having in-tree code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that janitorial deprecation is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the better name. The ongoing cost of that deprecation is then borne by everyone else. I have the feeling that almost the complete Python community is abusing deprecations. I was hit by deprecations in the email package: The deprecation told me to use a different method, but this method was not a full replacement for the old one and failed in my use case. In the next release, my old method was removed -- but fortunately, I know how to recreate methods and silence stupid deprecations. That is unfortunate example of obviously bad deprecation. Deprecation is hard and it requires a great deal of thought. But it can be manageable in many cases. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
It is my impression that it was Zope 2's obscenity towards API stability
which provoked the Zope 3 rewrite. We are only doing now what could have
been done (over the course of 4 to 5 years) much earlier. After all, the
new religion idea (Component Architecture) dates as far back as 2001.
Sure, having to do:
to_change = {}
if obj.hasProperty(x):
to_change[x]=x_value
else:
obj.manage_addProperty(x,x_value,x_type)
obj.manage_changeProperties(**to_change)
...and remembering that manage_editProperties is BAD isn't that pretty,
but it's been stable for so long that I can write it from memory now,
and that's a big win.
Well, prettiness (or rather ugliness) aside, I'm having a problem
letting that argument count. C programmers could easily use the same
line of argumentation to say that manual error handling via return codes
may be more complicated than dealing with exceptions, but they've been
doing it for so many years that they can write it from memory now.
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
So, for me, it would be great if developers would take more time to
weigh up the what does this new feature or refactoring bring against
the how much of a PITA is it going to be for everyone else to relearn
this...
Agreed.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Martijn Faassen wrote: So, my proposal for Zope 3.4: * have a developer_notes file or directory somewhere. * let this contain the developer-visible changes. * it should be focused on how to change your code. That's the important bit. Motivations and such might also be useful to have there, but the main thing should be: this change from so and so to so and so, so to make this work, do the following. Sounds great! I've put it on my personal 'follow up list', hopefully so we don't forget about it. Christian - -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/D+ZdUt9X/gknwIRAsvhAJ45OMOEEX89c5TAzxKda/zPwgcyXACeL7MJ KdsjLbVW9Nl7mhcMn3BMaD8= =W+8A -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] URLGetter security declaration: changing from zope.View to zope.Public
In zope/app/publisher/http.zcml we have class class=zope.publisher.http.URLGetter require permission=zope.View attributes=get __getitem__ __str__ / /class I think this should be zope.Public. Otherwise unauthorized users viewing an untrusted page template will get errors from a template that tries to do things like tal:attributes=action request/URL. A non-public permission is particularly problematic because URLGetter doesn't have an __parent__ attribute; therefore, there's no context for someone to *get* zope.View in the current public zope 3 security policies (and even then, the context would be request, and where should *it* get a security context?) Objections? I probably won't port this back to 3.3 unless folks request it, since I'm not sure if it is a bugfix (port) or a policy change (don't port). I'm going to change this in the trunk now. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
baiju m-2 wrote: This document is maintained as a wiki page, so anyone can edit it. http://kpug.zwiki.org/WhatIsNewInZope33 This is great! It's probably exactly what we need. Martin -- View this message in context: http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.html#a6137481 Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. So, for me, it would be great if developers would take more time to weigh up the what does this new feature or refactoring bring against the how much of a PITA is it going to be for everyone else to relearn this... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. So, for me, it would be great if developers would take more time to weigh up the what does this new feature or refactoring bring against the how much of a PITA is it going to be for everyone else to relearn this... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I might be the perpetrator, but surely such a change has no impact on code which imports the module. Does this affect you because it breaks patches you maintain? I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. As I said earlier, I actually *like* the insulation provided by a façade package: it leaves the internal location free to change wildly, without propagating the churn from that change out to those who are clients of the code. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/HSr+gerLs4ltQ4RAiLGAJ490R2aiQAAeuVELa90QzjLNYszxwCfa4Bq ccve4CXAHlKBRgoTl+FVYuY= =BPQx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. Backwards incompatible changes are bad, I absolutely agree. I don't think we've done many BBB incompatible changes in the past, though, thanks to the checkin police who's watching over checkins and the tests. We *did* have changes that generated deprecation warnings. But that's something else. I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. This is how we did it. The packages remain in zope.app for the time being, just pointing to the zope packages via deferred imports. Of course, the deferred imports generate deprecation warnings when executed. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
