Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Shane Hathaway]

zopyxfil...@gmail.com wrote:
> On 27.04.2009 22:56 Uhr, Shane Hathaway wrote:
>> Lennart Regebro wrote:
>>   
>>> Or, we could release 2.12 soon, and then start working on 2.13, a
>>> 
>> +1.  We need an eggified, Buildout-friendly Zope 2 that's fully 
>> compatible with Zope 2.11.  
> 
> Zope 2.11???

In other words, let's not discuss any more sweeping changes for Zope 
2.12.  I want an eggified Zope 2 release soon so that RelStorage is 
easier to support. :-)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Shane Hathaway]

Lennart Regebro wrote:
> Or, we could release 2.12 soon, and then start working on 2.13, a

+1.  We need an eggified, Buildout-friendly Zope 2 that's fully 
compatible with Zope 2.11.  Development after that should be smoother, 
since then we'll all be working with eggs.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Wichert Akkerman]

Hi Gary,

Previously Gary Poster wrote:
> Thanks Uli, Wichert, and Hanno for working out the legal bits!  And  
> thanks to Martijn and Martin for the other replies.
> 
> On Friday I had moved to z3c.recipe.filetemplate, for the reasons I  
> had described then.  Philipp said I could run with that package.   
> However, I'd prefer to work with a more active project.  If there's  
> quick agreement on my additions to the collective recipe, and I'm  
> given commit access, I'll switch.  I don't have time for a bikeshed  
> discussion though, so if it descends much into that I'll stick with  
> extending Philipp's recipe for now, and maybe switch over later when  
> things settle down.

Commit access to the collective is very liberal and generally arranged
within 24 hours. Uli has both commit and pypi access for the package and
has already done a lot of work on it. Your contributions are very
welcome as well!

> If I built on collective.recipe.template, I'd make the following  
> changes.
> 
> REQUIRED
> 
> - verify that the BSD licensing rules are followed (headers, license  
> inclusion, copyright statement, etc.), and fix if not.  I'd prefer if  
> a foundation (e.g., the Plone Foundation) had the copyright.  (TBH,  
> I'm more comfortable with the Zope Foundation repository because the  
> rules for copyright assignment are clearer AIUI, even if they are  
> breached sometimes, as was this case here.  But this isn't critical  
> for my usage or contribution.)

The BSD license has very little restrictions. It certainly does not
require licens statementsin every source file or so. Personally I find
those to be clutter. If there is a missing license file that should be
fixed.

> - Add the ability to specify "eggs" and "extra-paths" the way you can  
> for scripts.  These supply the values for three predefined options  
> (available to the template).  If "paths" are the non-zip paths, and  
> "all_paths" are all paths, then the options woud be defined roughly as  
> given here:
> 
>  os-paths: (os.pathsep).join(paths)
>  string-paths: ', '.join(repr(p) for p in all_paths)
>  space-paths: ' '.join(paths)

I can see that being useful.

> - I have a directory of *.in files that will need to be processed,  
> with shared options, and put in another directory.  Therefore, I'd  
> like to be able to just specify the input directory and optionally the  
> output directory. globs, for filters, might be a nice-to-have.  I came  
> up with a spelling for all this that appealed to me for Philipp's  
> package (which has a constraint of "I only use *.in inputs, and always  
> strip ".in" for the output).  WIth my variant of his spelling, I could  
> do everything I wanted with a line like
> 
>  files = *
>  source-directory = templates
> 
> Then in ``templates`` you would arrange the directory structure you  
> wanted, and make sure that your template files end with ".in".
> 
> I don't have a spelling I like as much for the "input" "output"  
> pattern of the collective recipe.  I'd be OK with "input" and "output"  
> being able to take multiple files:
> 
>  input = templates/etc/foo.in
>   templates/etc/bar.in
>  output = etc/foo
>  etc/bar
> 
> That seems like it rocks the boat least for collective.recipe.template

+1

> 
> NICE-TO-HAVE
> 
> Unless I discover I need this, these are just ideas that I might do on  
> hobby time.
> 
> - Extend/override other buildout sections.  Here's an example, with  
> Philipp's package.  Consider the following buildout::
> 
>  >>> write(sample_buildout, 'buildout.cfg',
>  ... """
>  ... [buildout]
>  ... parts = message
>  ...
>  ... [template_defaults]
>  ... mygreeting = Hi
>  ... myaudience = World
>  ...
>  ... [message]
>  ... recipe = z3c.recipe.filetemplate
>  ... files = helloworld.txt
>  ... extends = template_defaults
>  ...
>  ... myaudience = everybody
>  ... """)
> 
> The "message" section now has values extended from the  
> "template_defaults"
> section, and overwritten locally.  A template of
> ``${mygreeting}, ${myaudience}!`` would thus result in ``Hi, everybody! 
> ``.

This feels more like a feature for buildout: I can see this being useful
for other recipes as well.

> - Define option values in Python.  This would have the os and sys  
> modules in the namespace, and would also have the buildout variables,  
> and would have the paths and all_paths from the ``eggs`` section above  
> so you could manipulate them as desired.
> 
> interpreted-options = path-separator=os.pathsep
>example-paths=' '.join('-t%s' %  
> p for p in paths)
> 
> That would put ``path-separator`` and ``example-paths`` in the  
> recipe's options.

Again, this sounds more like a buildout extension. I've missed the
option to do shell escapes in buildout as well.

Wichert.

-- 
Wichert Akkerman It is simple to make things.
htt

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Lennart Regebro]

Now when we have eggs, can we fork the relevant modules (Publisher +
OFS?) into two versions. Zope 2 backwards compatible versions, and
versions that rely on that __parent__ is sane? Plone, and any others
that want to gradually migrate to the toolkit, could then use that
version. People who require backwards compatibility but need to more
to Python 2.5/2.6 could use the old?

Or, we could release 2.12 soon, and then start working on 2.13, a
version that explicitly is for people who want to move towards the
Zope Toolkit, and may not be completely backward compatible.

(Let the flaming begin.)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Chris McDonough]

On 4/27/09 3:27 PM, Laurence Rowe wrote:
> Martin Aspeli wrote:
>> Laurence Rowe wrote:
>>> Martin Aspeli wrote:
 Hi,

 First - a quick question: can we treat __name__ and id/getId()/_setId()
 as the same, always? OFS.SimpleItem has some support for letting id and
 name be the same, but the link is lost once both __name__ and id are
 set. Why isn't __name__ just a property that reflects self.id ?
>>> I would prefer this to be the other way around -- getId() /  _setId()
>>> should operate on __name__. It will be easier to drop OFS support in the
>>> future if pickles store the real __name__ and __parent__ attributes. We
>>> will presumably require a migration now anyway to add __parent__ pointers.
>> It kind of already does that if 'id' isn't set. But when 'id' is set,
>> they diverge.
>>
>> Also note that according to ILocation, __name__ is a TextLine, which
>> implies unicode. unicode ids are a no-no in Zope 2.
>
> I doubt it would be all that difficult to change the publisher to handle
> unicode path segments.

This would be the only sane thing to do if Zope was being created today.

It's a lot saner to store Unicode object identifiers than string ones, and if 
you've got that it's a no-brainer to use Unicode path segments too.  But if you 
did one and not the other, it would be a worthless change.

>> The current solution I've put into dexterity is to let __name__ be a
>> property that gets and sets id, but assumes its value is unicode. It'll
>> fail if the unicode string can't be encoded to ASCII, though.

That's certainly keeping with the spirit of the default "bad identifier" regex 
in OFS, but it does feel a little weird to need to never use high-order 
characters in ids (even if you did need to make them utf-8 encoded).  I had to 
work around this for one very large application that wanted to use Zope as a 
filesystem storage and it was no fun at all (in fact, it would have been sanest 
to not use Zope for that).

> This is what I'm worried about. If new code uses __name__ instead, then
> it opens up the possibility to share ZODB content between Plone and
> lightweight systems like repoze.bfg, as well as making it easier for
> Plone to migrate to a cleaner content model. Plone has been around for
> eight years now, I sincerely hope we are not still stuck on
> OFS.SimpleItem for another eight years!

I wouldn't worry much about trying to preserve compatibility between Zope 2 and 
Zope 3/bfg at this level; it's highly unlikely that *any* Plone content object 
will work out of the box on any system other than Zope2 (or at least without a 
large chunk of Zope2 sitting around) due to abuses of things like 
"self.REQUEST" 
in Archetypes.  But I could be wrong.

- C
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Laurence Rowe]

Martin Aspeli wrote:
> Laurence Rowe wrote:
>> Martin Aspeli wrote:
>>> Hi,
>>>
>>> First - a quick question: can we treat __name__ and id/getId()/_setId() 
>>> as the same, always? OFS.SimpleItem has some support for letting id and 
>>> name be the same, but the link is lost once both __name__ and id are 
>>> set. Why isn't __name__ just a property that reflects self.id ?
>> I would prefer this to be the other way around -- getId() /  _setId() 
>> should operate on __name__. It will be easier to drop OFS support in the 
>> future if pickles store the real __name__ and __parent__ attributes. We 
>> will presumably require a migration now anyway to add __parent__ pointers.
> 
> It kind of already does that if 'id' isn't set. But when 'id' is set, 
> they diverge.
> 
> Also note that according to ILocation, __name__ is a TextLine, which 
> implies unicode. unicode ids are a no-no in Zope 2.

I doubt it would be all that difficult to change the publisher to handle 
unicode path segments.

> The current solution I've put into dexterity is to let __name__ be a 
> property that gets and sets id, but assumes its value is unicode. It'll 
> fail if the unicode string can't be encoded to ASCII, though.

This is what I'm worried about. If new code uses __name__ instead, then 
it opens up the possibility to share ZODB content between Plone and 
lightweight systems like repoze.bfg, as well as making it easier for 
Plone to migrate to a cleaner content model. Plone has been around for 
eight years now, I sincerely hope we are not still stuck on 
OFS.SimpleItem for another eight years!

Laurence

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin

[Roger Ineichen]

Hi Hanno

> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ 
> Added some BBB code to setDefaultSkin
> 
> Hi.
> 
> Roger Ineichen wrote:
> >> Roger Ineichen wrote:
> >> Then there's some tests and description missing proving 
> that intent. 
> >> All I could read in the changelog and the skinnable tests was 
> >> pointing in the other direction: Making it possible to use the 
> >> Skinnable concept without relying on IBrowserRequest. The whole 
> >> JSONRequest (which is not a
> >> BrowserRequest) tests inside skinnable.txt continue to work.
> > 
> > Yes, I think everything was tested, but probably future 
> ideas are not 
> > documented. There where some discussion about to split each request 
> > into it's own packages.
> 
> Where did that discussion happen? All I have heard of was 
> discussions at PyCon, where nobody quite seemed to see any 
> point in the whole different request types story at all anymore.
> 
> I don't mind if the skinnable story gets less intermingled 
> with the request story in a new zope.skinnable package and 
> breaks some backwards compatibility at that point. Right now 
> that mix of the two concepts is so prevalent in all kinds of 
> places, that I'd rather stay on the backwards compatible side.

Can you tell me what was not backward compatible?

> All ZCML browser directives by default register everything 
> for IDefaultBrowserLayer and expect those resources to be 
> available on "normal" browser requests. The test helpers in 
> zope.app.testing to get browser resources set up rely on the 
> same mix of concerns. This stuff is used all over the place 
> without caring about loading zope.publisher's ZCML right now.

Did my refactoring break anything? If so what?

> >> All I did here was to move two constructs from ZCML into 
> direct code.
> >> The lines I added do exactly the same as the default adapter 
> >> registered as:
> > 
> > Uhh, this is call hard coded and makes it impossible to exclude the 
> > adapter with the  directive.
> 
> I call that retaining sensible defaults. You can opt-out of 
> the IDefaultBrowserLayer for browser requests by providing 
> your own specialized adapter. I prefer no configuration for 
> the most common case with an opt-out scenario instead of the 
> everything is opt-in behavior.

Do you understand the impact of your changes? I see what you
are trying to do but I don't know which package or application
you are trying to fix with your changes. Can you give me some
hints about what you are trying to fix with your changes?

> > I see two things which are bad. Skinnable depends now on 
> > IBrowserRequest. I moved the skinnable concept out of the browser 
> > request part. This allows us to separate the skinnable and all 
> > different request types into own packages if we do future 
> refactoring.
> 
> zope.publisher is the package that defines the 
> IBrowserRequest interface. It might make sense to split those 
> concerns off into different packages and then straighten out 
> the dependencies. At that point I can see having a 
> setDefaultSkin method inside zope.skinnable with a different 
> behavior. But the one inside zope.publisher ought to play 
> nicely with IBrowserRequest.

Any improvements are very welcome. Do you think we should move
the skinnable concept into zope.skinnable?

Sorry if I'm bother you about this details but I spent
a full day with this refactoring and one of my apps depends
on this deault browser layer less concept. You just reverted
the hole refactoring with 3 lines of code.

Regards
Roger Ineichen

> Hanno
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  ** (Related lists -  
> http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
> 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martijn Faassen]

Hey,

On Mon, Apr 27, 2009 at 6:39 PM, Hermann Himmelbauer  wrote:
> It may well be that people (even I myself) use e.g. zope.interfaces or some
> other package in some Zope related or unrelated product where it is necessary
> due to some other dependencies to maintain Python 2.4 compatibility.
>
> Therefore I would rather not suggest to drop support for Python 2.4, however,
> if this is a major blocker, it's acceptable (for me).

That's a good point; zope.interface and zope.component probably should
remain 2.4 compatible as they are so low in the stack and have the
most "outside" use.

Regards,

Martijn
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Martin Aspeli]

Laurence Rowe wrote:
> Martin Aspeli wrote:
>> Hi,
>>
>> First - a quick question: can we treat __name__ and id/getId()/_setId() 
>> as the same, always? OFS.SimpleItem has some support for letting id and 
>> name be the same, but the link is lost once both __name__ and id are 
>> set. Why isn't __name__ just a property that reflects self.id ?
> 
> I would prefer this to be the other way around -- getId() /  _setId() 
> should operate on __name__. It will be easier to drop OFS support in the 
> future if pickles store the real __name__ and __parent__ attributes. We 
> will presumably require a migration now anyway to add __parent__ pointers.

It kind of already does that if 'id' isn't set. But when 'id' is set, 
they diverge.

Also note that according to ILocation, __name__ is a TextLine, which 
implies unicode. unicode ids are a no-no in Zope 2.

The current solution I've put into dexterity is to let __name__ be a 
property that gets and sets id, but assumes its value is unicode. It'll 
fail if the unicode string can't be encoded to ASCII, though.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Laurence Rowe]

Martin Aspeli wrote:
> Hi,
> 
> First - a quick question: can we treat __name__ and id/getId()/_setId() 
> as the same, always? OFS.SimpleItem has some support for letting id and 
> name be the same, but the link is lost once both __name__ and id are 
> set. Why isn't __name__ just a property that reflects self.id ?

I would prefer this to be the other way around -- getId() /  _setId() 
should operate on __name__. It will be easier to drop OFS support in the 
future if pickles store the real __name__ and __parent__ attributes. We 
will presumably require a migration now anyway to add __parent__ pointers.

> In Zope 2.12, acquisition wrappers are optional. Instead of using a 
> wrapper, acquisition can work by following __parent__ pointers. That 
> work well for views, where these are now set properly, but no content 
> currently maintains __parent__ pointers.
> 
> We can fix this by introducing some code in OFS (and BTreeFolder2) that 
> mimics what zope.container does. We can't use the setitem() and 
> uncontained() helpers directly, since these deal with containment 
> proxies and have slightly different semantics, but I think we can do this:
> 
>   1) Add the following to _setOb:
> 
>  def _setOb(self, id, object):
>  if ILocation.providedBy(object):
>  if not IContained.providedBy(object):
>  alsoProvides(object, IContained)
> 
>  oldname = getattr(object, '__name__', None)
>  oldparent = getattr(object, '__parent__', None)
> 
>  if id is not oldname:
>  object.__name__ = id
>  if self is not oldparent:
>  object.__parent__ = self
> 
>  setattr(self, id, object)
> 
> 
>   2) Add the following to _delOb:
> 
>  def _delOb(self, id):
>  """ Remove the named object from the folder. """
>  try:
>  obj = self._getOb(id, _marker)
>  if obj is not _marker:
>  if IContained.providedBy(obj):
>  obj.__parent__ = None
>  obj.__name__ = None
>  except AttributeError:
>  # No need to fail if we can't set these
>  pass
> 
>  delattr(self, id)
> 
> Note that there's a slight discrepancy here with the way zope.container 
> works. In Zope 3, the __parent__ pointer is not unset until after the 
> ObjectRemovedEvent is fired. In Zope 2, we only fire that event after 
> the object has been fully removed (in _delObject()), but we have the 
> ObjectWillBeRemovedEvent that is fired before. I don't think this really 
> matters, though.
> 
>   3) It'd be nice to also make ObjectManager and BTreeFolder2Base 
> support the IContainer interface, so that OFS containers can be used 
> with the more natural dict-like API of Zope 3 rather than the somewhat 
> obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we 
> have now.
> 
> To add this, we'd just need to add a few methods to ObjectManager that 
> calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and 
> so on.
> 
> We have code for all three of these in plone.folder which could be 
> pushed down to OFS an BTreeFolder2 quite easily.

+1

Laurence

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Martin Aspeli wrote:
>> Tres Seaver wrote:
>>> Thinking further on this:  there is actually not much "shiny" about the
>>> ZTK:  it is going to be equivalent to a cut-down, dependency-stripped,
>>> bbb-cruft-sanded version of the packages already shipping with Zope
>>> 2.10.x / 2.11.x.  Until Plone quits using Zope2 altogether (likely
>>> never, AFAIK) Plone has no direct interest in the ZTK, which is just a
>>> layer of the Zope2 stack from Plone's perspective.
>> In practice, though, people are using packages from newer Zope releases 
>> in third party products, and, possibly, in Plone core.
>>
>> One example is z3c.form, which requires you to upgrade zope.i18n and 
>> zope.component That works fine, FWIW. :)
> 
> But it won't be "supported".  Mix-and-match is not what the toolkit (or
> the related KGS / index stuff) is designed for.

Sure. Which is why I said it would be disappointing (as opposed to 
negligent) if Python 2.4 support were dropped. ;)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Hermann Himmelbauer]

Am Montag 27 April 2009 16:44:17 schrieb Martijn Faassen:
> Hi there,
>
> What do people feel about dropping Python 2.4 support in the Zope
> Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave
> vaguely as we *still* don't have a canonical list) only have to work in
> Python 2.5 (and preferably 2.6), not Python 2.4 anymore.

It may well be that people (even I myself) use e.g. zope.interfaces or some 
other package in some Zope related or unrelated product where it is necessary 
due to some other dependencies to maintain Python 2.4 compatibility.

Therefore I would rather not suggest to drop support for Python 2.4, however, 
if this is a major blocker, it's acceptable (for me).

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:
> Tres Seaver wrote:
>> Thinking further on this:  there is actually not much "shiny" about the
>> ZTK:  it is going to be equivalent to a cut-down, dependency-stripped,
>> bbb-cruft-sanded version of the packages already shipping with Zope
>> 2.10.x / 2.11.x.  Until Plone quits using Zope2 altogether (likely
>> never, AFAIK) Plone has no direct interest in the ZTK, which is just a
>> layer of the Zope2 stack from Plone's perspective.
> 
> In practice, though, people are using packages from newer Zope releases 
> in third party products, and, possibly, in Plone core.
> 
> One example is z3c.form, which requires you to upgrade zope.i18n and 
> zope.component That works fine, FWIW. :)

But it won't be "supported".  Mix-and-match is not what the toolkit (or
the related KGS / index stuff) is designed for.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9d6++gerLs4ltQ4RAiYnAKDJFrQ2Bp4Bd6mwJjXoZqVJuSMzigCglARB
VrBWI/9TEvGrDuS8YV+/86o=
=Z+vD
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tres Seaver wrote:
>> Martin Aspeli wrote:
>>
>>> The Plone 3.x series will stay on Python 2.4 for a long time yet, so
>>> this would be very disappointing. I can understand it if the maintenance
>>> burden becomes large, or if there are compelling features of 2.5/2.6
>>> that we really want to make use of. The tgz issue seems like a pretty
>>> weak reason, though, especially since there are workarounds.
>> "Stability or goodies, pick one".  If you can't upgrade to a newer
>> Python / Zope, you can't use the ZTK, which *cannot* be constrained by
>> backwared compatiblity with pre-2.12 Zope versions:  those versions are
>> stuck with using the Zope 3.3 / 3.4 trees on which they were originally
>> based, just as they are stuck with Python 2.4.
> 
> Thinking further on this:  there is actually not much "shiny" about the
> ZTK:  it is going to be equivalent to a cut-down, dependency-stripped,
> bbb-cruft-sanded version of the packages already shipping with Zope
> 2.10.x / 2.11.x.  Until Plone quits using Zope2 altogether (likely
> never, AFAIK) Plone has no direct interest in the ZTK, which is just a
> layer of the Zope2 stack from Plone's perspective.

In practice, though, people are using packages from newer Zope releases 
in third party products, and, possibly, in Plone core.

One example is z3c.form, which requires you to upgrade zope.i18n and 
zope.component That works fine, FWIW. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Andreas Jung wrote:
> On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
>> Andreas Jung wrote:
>>
>>   
>>> What would be disappointing?
>>> 
>> To be unable to use new packages from an updated Zope Toolkit.
>>
>> It may be that some (many?) packages won't work with Zope 2.10, but if 
>> we get the kind of dependency isolation we're talking about, I'd wager 
>> that quite a few packages would work if pulled in independently.
>>   
> Would it be much work bringing Plone 3.X to Zope 2.12?

It would be interesting to make it optional. I don't think we can make 
it required - too big a change for people using Plone 3.x and expecting 
forwards compatibility with new versions.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tres Seaver wrote:
> Martin Aspeli wrote:
> 
>> The Plone 3.x series will stay on Python 2.4 for a long time yet, so
>> this would be very disappointing. I can understand it if the maintenance
>> burden becomes large, or if there are compelling features of 2.5/2.6
>> that we really want to make use of. The tgz issue seems like a pretty
>> weak reason, though, especially since there are workarounds.
> 
> "Stability or goodies, pick one".  If you can't upgrade to a newer
> Python / Zope, you can't use the ZTK, which *cannot* be constrained by
> backwared compatiblity with pre-2.12 Zope versions:  those versions are
> stuck with using the Zope 3.3 / 3.4 trees on which they were originally
> based, just as they are stuck with Python 2.4.

Thinking further on this:  there is actually not much "shiny" about the
ZTK:  it is going to be equivalent to a cut-down, dependency-stripped,
bbb-cruft-sanded version of the packages already shipping with Zope
2.10.x / 2.11.x.  Until Plone quits using Zope2 altogether (likely
never, AFAIK) Plone has no direct interest in the ZTK, which is just a
layer of the Zope2 stack from Plone's perspective.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9daE+gerLs4ltQ4RAtmvAJsGD68zXZUod1LIyD1/B1oYfSlZOwCgiR+e
eNQ2a+aI8VtZMxgQe+M+p60=
=7jUW
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Gary Poster]

Thanks Uli, Wichert, and Hanno for working out the legal bits!  And  
thanks to Martijn and Martin for the other replies.

On Friday I had moved to z3c.recipe.filetemplate, for the reasons I  
had described then.  Philipp said I could run with that package.   
However, I'd prefer to work with a more active project.  If there's  
quick agreement on my additions to the collective recipe, and I'm  
given commit access, I'll switch.  I don't have time for a bikeshed  
discussion though, so if it descends much into that I'll stick with  
extending Philipp's recipe for now, and maybe switch over later when  
things settle down.

If I built on collective.recipe.template, I'd make the following  
changes.

REQUIRED

- verify that the BSD licensing rules are followed (headers, license  
inclusion, copyright statement, etc.), and fix if not.  I'd prefer if  
a foundation (e.g., the Plone Foundation) had the copyright.  (TBH,  
I'm more comfortable with the Zope Foundation repository because the  
rules for copyright assignment are clearer AIUI, even if they are  
breached sometimes, as was this case here.  But this isn't critical  
for my usage or contribution.)

- Add the ability to specify "eggs" and "extra-paths" the way you can  
for scripts.  These supply the values for three predefined options  
(available to the template).  If "paths" are the non-zip paths, and  
"all_paths" are all paths, then the options woud be defined roughly as  
given here:

 os-paths: (os.pathsep).join(paths)
 string-paths: ', '.join(repr(p) for p in all_paths)
 space-paths: ' '.join(paths)

- I have a directory of *.in files that will need to be processed,  
with shared options, and put in another directory.  Therefore, I'd  
like to be able to just specify the input directory and optionally the  
output directory. globs, for filters, might be a nice-to-have.  I came  
up with a spelling for all this that appealed to me for Philipp's  
package (which has a constraint of "I only use *.in inputs, and always  
strip ".in" for the output).  WIth my variant of his spelling, I could  
do everything I wanted with a line like

 files = *
 source-directory = templates

Then in ``templates`` you would arrange the directory structure you  
wanted, and make sure that your template files end with ".in".

I don't have a spelling I like as much for the "input" "output"  
pattern of the collective recipe.  I'd be OK with "input" and "output"  
being able to take multiple files:

 input = templates/etc/foo.in
  templates/etc/bar.in
 output = etc/foo
 etc/bar

That seems like it rocks the boat least for collective.recipe.template

NICE-TO-HAVE

Unless I discover I need this, these are just ideas that I might do on  
hobby time.

- Extend/override other buildout sections.  Here's an example, with  
Philipp's package.  Consider the following buildout::

 >>> write(sample_buildout, 'buildout.cfg',
 ... """
 ... [buildout]
 ... parts = message
 ...
 ... [template_defaults]
 ... mygreeting = Hi
 ... myaudience = World
 ...
 ... [message]
 ... recipe = z3c.recipe.filetemplate
 ... files = helloworld.txt
 ... extends = template_defaults
 ...
 ... myaudience = everybody
 ... """)

The "message" section now has values extended from the  
"template_defaults"
section, and overwritten locally.  A template of
``${mygreeting}, ${myaudience}!`` would thus result in ``Hi, everybody! 
``.

- Define option values in Python.  This would have the os and sys  
modules in the namespace, and would also have the buildout variables,  
and would have the paths and all_paths from the ``eggs`` section above  
so you could manipulate them as desired.

interpreted-options = path-separator=os.pathsep
   example-paths=' '.join('-t%s' %  
p for p in paths)

That would put ``path-separator`` and ``example-paths`` in the  
recipe's options.

- Make a script recipe that allows you to specify an  
``initialization_template``, as I described in my first email.

I'm pretty busy all around right now, and there's always the YAGNI  
concern, so I probably won't do those, but they seem like potentially  
good ideas.

Gary
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:

> The Plone 3.x series will stay on Python 2.4 for a long time yet, so 
> this would be very disappointing. I can understand it if the maintenance 
> burden becomes large, or if there are compelling features of 2.5/2.6 
> that we really want to make use of. The tgz issue seems like a pretty 
> weak reason, though, especially since there are workarounds.

"Stability or goodies, pick one".  If you can't upgrade to a newer
Python / Zope, you can't use the ZTK, which *cannot* be constrained by
backwared compatiblity with pre-2.12 Zope versions:  those versions are
stuck with using the Zope 3.3 / 3.4 trees on which they were originally
based, just as they are stuck with Python 2.4.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9c/5+gerLs4ltQ4RAn3OAJ44lr3NpqK4zsqJB4tqxq0Df9yyIACgzeEV
gxn1gqQeduZaFKqE2GERbSg=
=ippb
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martijn Faassen]

Martin Aspeli wrote:
> Andreas Jung wrote:
> 
>> What would be disappointing?
> 
> To be unable to use new packages from an updated Zope Toolkit.
> 
> It may be that some (many?) packages won't work with Zope 2.10, but if 
> we get the kind of dependency isolation we're talking about, I'd wager 
> that quite a few packages would work if pulled in independently.

Probably less than you think, unless you pulled in *all* of the new 
packages. If not, you tend to get loops where package A depends on B 
which depends on A.app (which got moved to A, but B doesn't know that 
are you only use the new A, not the new B). And then you'll pull in 
other versions of the same code that now lives in A, and tests will break.

> It's also generally silly to break compatibility with a platform if 
> there's not a compelling reason to do so. I suspect there may be 
> compelling reasons, but the TAR file issue isn't one of them.

The reasons would be the familiar ones of "we have limited resources" 
combined with "we got to get a move on to Python 2.6, and then possibly 
on to Python 3, probably through 2.7", with a dash of "it'd be cool to 
be able to use the 'with' statement" and "some packages might only work 
in Python 2.5".

Compelling? That depends on whether any of the objections to such a move 
are compelling enough. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Hanno Schlichting]

Chris Withers wrote:
> I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to 
> see 2.12 out the door as soon as possible.

Then we have a conflict of interest. My main goal for Zope 2.12 is to be
based on the Zope Toolkit 1.0 release and loose quite some more stuff.

That in itself is going to take quite some more months to get to I'd
assume. In the current situation Zope2 is based on some undefined mix of
packages which none of the others projects share. To share actual
maintenance cost between the different communities we need to get some
stable basis with a somewhat defined scope back.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Andreas Jung]

On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
> Andreas Jung wrote:
>
>   
>> What would be disappointing?
>> 
>
> To be unable to use new packages from an updated Zope Toolkit.
>
> It may be that some (many?) packages won't work with Zope 2.10, but if 
> we get the kind of dependency isolation we're talking about, I'd wager 
> that quite a few packages would work if pulled in independently.
>   
Would it be much work bringing Plone 3.X to Zope 2.12?

Andreas


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Hanno Schlichting]

Martijn Faassen wrote:
> What do people feel about dropping Python 2.4 support in the Zope 
> Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave 
> vaguely as we *still* don't have a canonical list) only have to work in 
> Python 2.5 (and preferably 2.6), not Python 2.4 anymore.

Btw. I just updated the Zope2 KGS over the weekend again at
http://svn.zope.org/*checkout*/Zope/trunk/versions.cfg

It contains the latest released version of everything Zope2 depends on
at least. So it should be a good base for deciding what exactly the Zope
Toolkit is.

> What do Zope 2 and Plone people in general think about moving to Python 
> 2.5 for the newer releases? I'll note we're shuffling around the 
> dependency structure so much in the Zope Toolkit it's unlikely 
> everything will remain compatible for that reason as well.

As others mentioned as long as there's no good compelling reason to drop
support for a Python version I'd rather not do it.

Andreas mentioned the policy for Zope 2.12: It ain't officially
supported, but we won't break it without a good reason.

The Plone policy is:

For 3.x is: stuck with Python 2.4
For 4.0: We require Python 2.6 and won't even support 2.5. But Plone 4.0
is future-ware that will be released sometime next year.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Andreas Jung wrote:

> What would be disappointing?

To be unable to use new packages from an updated Zope Toolkit.

It may be that some (many?) packages won't work with Zope 2.10, but if 
we get the kind of dependency isolation we're talking about, I'd wager 
that quite a few packages would work if pulled in independently.

It's also generally silly to break compatibility with a platform if 
there's not a compelling reason to do so. I suspect there may be 
compelling reasons, but the TAR file issue isn't one of them.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Chris Withers]

Hanno Schlichting wrote:
> Since these pointers will take precedence over any even manually crafted
> Acquisition chains, certain operations might no longer be possible. An
> object with parent pointers will have its real physical path as its
> context. In the way Acquisition used to be used, it was quite possible
> to change the context of things by crafting different AQ chains.

Indeed, and as someone who has real live production code that does 
exactly this kind of thing, I'm a big -1 for these changes.

I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to 
see 2.12 out the door as soon as possible.

For me, a true buildout-compatible release wins over all else. I really 
think we should aim for nothing more in terms of features before 2.12 is 
out...

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Martin Aspeli]

Uli Fouquet wrote:

> In the beginning my code should go into collective.recipe.template
> itself (Wichert agreed), but I wasn't granted committer access to the
> collective repository yet. Of course I requested to be approval and
> waited for weeks, but nothing happened.

I'm sorry to hear that! In general, access to the Collective is very 
unproblematic. Find an op in #plone on irc.freenode.net and they should 
be able to help you.

How did you request the access? Clearly, something's broken down.

Martin


-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Martin Aspeli]

Gary Poster wrote:
> I'm concerned about the state of the zc.buildout template recipes.  I  
> want one.  I want some one-off files, specific to a certain project,  
> for which writing a standalone recipe feels very heavy.
> 
> Here are the template recipes I found:
> 
> collective.recipe.template (Wichert Akkerman)

FTR, this seems to be the de-facto choice in the Plone world, and it's 
quite well production-tested.

I didn't even know about the others. :)

> z3c.recipe.template (Uli Fouquet)

It's a bit disappointing that Uli created a new package rather than add 
the relatively minor feature missing from collective.recipe.template 
according to the PyPI page, although I agree the lack of tests is 
off-putting and should be fixed.

Still, since the package was based on the other one, I don't see why we 
couldn't have added tests to collective.recipe.template rather than fork 
it. :-/

> Since I don't find the prospect of creating yet another template  
> recipe attractive, and Philipp's z3c.recipe.filetemplate looks like it  
> can take my new features while maintaining backwards compatibility,  
> I'll try that next, I suppose.

What features do you want to add?

Why can't they (plus the tests) go into the original 
collective.recipe.template?

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Upcoming Zope 2.9-2.11 releases

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christophe Tronche wrote:
> Does it work with python2.5 / 2.6 ? If not are there plans to do that ?

- - Zope 2.12 prefers python 2.5 / 2.6, and should still run on 2.4.

- - Older versions will continue to be supported only on 2.4 (we can't
  make the kind of invasive changes needed for full compatibility in
  bugfix releases of stable software).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9cad+gerLs4ltQ4RAtEmAJ97LdGzOky4HQD975nFu0z1Zppr1ACfVWBD
E6i9aZbFsLT8YbPeKrtM/Ds=
=86FU
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Andreas Jung]

On 27.04.2009 16:48 Uhr, Martin Aspeli wrote:
> Martijn Faassen wrote:
>   
>> Hi there,
>>
>> What do people feel about dropping Python 2.4 support in the Zope 
>> Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave 
>> vaguely as we *still* don't have a canonical list) only have to work in 
>> Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
>>
>> (this won't affect Zope 3.4 or below)
>>
>> One issue that came up recently was that .tgz releases to PyPI sometimes 
>> break with Python 2.4 due to a bug in Python 2.4. Using --zip is a 
>> workaround. And Plone currently depends on Python 2.4. Is it possible to 
>> work around this by *also* uploading a zip if we discover there's a 
>> problem with a package and it's pointed out there? If not, are there 
>> other workarounds?
>>
>> What do Zope 2 and Plone people in general think about moving to Python 
>> 2.5 for the newer releases? I'll note we're shuffling around the 
>> dependency structure so much in the Zope Toolkit it's unlikely 
>> everything will remain compatible for that reason as well.
>> 
> The Plone 3.x series will stay on Python 2.4 for a long time yet, so 
> this would be very disappointing. 
>   


What would be disappointing?

Andreas
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Andreas Jung]

On 27.04.2009 16:44 Uhr, Martijn Faassen wrote:
> Hi there,
>
> What do people feel about dropping Python 2.4 support in the Zope 
> Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave 
> vaguely as we *still* don't have a canonical list) only have to work in 
> Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
>   

New releases should mean new major releases e.g. 3.X -> 3.X+1
> (this won't affect Zope 3.4 or below)
>
> One issue that came up recently was that .tgz releases to PyPI sometimes 
> break with Python 2.4 due to a bug in Python 2.4. Using --zip is a 
> workaround. And Plone currently depends on Python 2.4. Is it possible to 
> work around this by *also* uploading a zip if we discover there's a 
> problem with a package and it's pointed out there? If not, are there 
> other workarounds?
>
> What do Zope 2 and Plone people in general think about moving to Python 
> 2.5 for the newer releases? 
>   

Zope 2.12 already *requires* Python 2.5 or 2.6. Python 2.4 support in
Zope 2.12
is inofficial. Zope 2.12 will ship with those Z3 modules there are
compatible and stable.

Andreas
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Upcoming Zope 2.9-2.11 releases

[Andreas Jung]

On 27.04.2009 16:38 Uhr, Christophe Tronche wrote:
> Does it work with python2.5 / 2.6 ? If not are there plans to do that ?
>
> Best regards,
> Ch. Tronche
>
> On Sat, Apr 25, 2009 at 1:23 PM, Andreas Jung mailto:li...@zopyx.com>> wrote:
>
> I plan to release new releases for Zope 2.9-2.11 over the next weekend.
Huh? We never changed requirements for the Python version during the
maintenance phase of a release. Zope 2.12 will require Zope 2.5 or 2.6.

-aj

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martin Aspeli]

Martijn Faassen wrote:
> Hi there,
> 
> What do people feel about dropping Python 2.4 support in the Zope 
> Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave 
> vaguely as we *still* don't have a canonical list) only have to work in 
> Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
> 
> (this won't affect Zope 3.4 or below)
> 
> One issue that came up recently was that .tgz releases to PyPI sometimes 
> break with Python 2.4 due to a bug in Python 2.4. Using --zip is a 
> workaround. And Plone currently depends on Python 2.4. Is it possible to 
> work around this by *also* uploading a zip if we discover there's a 
> problem with a package and it's pointed out there? If not, are there 
> other workarounds?
> 
> What do Zope 2 and Plone people in general think about moving to Python 
> 2.5 for the newer releases? I'll note we're shuffling around the 
> dependency structure so much in the Zope Toolkit it's unlikely 
> everything will remain compatible for that reason as well.

The Plone 3.x series will stay on Python 2.4 for a long time yet, so 
this would be very disappointing. I can understand it if the maintenance 
burden becomes large, or if there are compelling features of 2.5/2.6 
that we really want to make use of. The tgz issue seems like a pretty 
weak reason, though, especially since there are workarounds.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Martijn Faassen]

Hi there,

What do people feel about dropping Python 2.4 support in the Zope 
Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave 
vaguely as we *still* don't have a canonical list) only have to work in 
Python 2.5 (and preferably 2.6), not Python 2.4 anymore.

(this won't affect Zope 3.4 or below)

One issue that came up recently was that .tgz releases to PyPI sometimes 
break with Python 2.4 due to a bug in Python 2.4. Using --zip is a 
workaround. And Plone currently depends on Python 2.4. Is it possible to 
work around this by *also* uploading a zip if we discover there's a 
problem with a package and it's pointed out there? If not, are there 
other workarounds?

What do Zope 2 and Plone people in general think about moving to Python 
2.5 for the newer releases? I'll note we're shuffling around the 
dependency structure so much in the Zope Toolkit it's unlikely 
everything will remain compatible for that reason as well.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Release management proposal

[Martijn Faassen]

Hey Jim, others,

Jim Fulton wrote:

[__file__ in setup.py]

> Stop talking about this. :)
> 
> This is almost certainly a buildout bug that I'll fix.

Just making sure we have some clear conclusions in this thread...

Do we have a buildout bug id we can track so we make sure we don't 
forget about it? (if it wasn't already fixed?)

The other issue involved using --zip to retain compatibility with Python 
2.4. There was some back and forth about this. I will bring up the whole 
issue of Python 2.4 support in Zope Toolkit packages in a new thread.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Upcoming Zope 2.9-2.11 releases

[Christophe Tronche]

Does it work with python2.5 / 2.6 ? If not are there plans to do that ?

Best regards,
Ch. Tronche

On Sat, Apr 25, 2009 at 1:23 PM, Andreas Jung  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I plan to release new releases for Zope 2.9-2.11 over the next weekend.
> So if you any pending fixes, please commit them.
>
> Mit freundlichen Grüßen/Kind regards,
> Andreas Jung
>
> - ---
> ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
> Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376
> Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
> Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
> - 
> E-Publishing, Python, Zope & Plone development, Consulting
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (Darwin)
>
> iEYEARECAAYFAkny8p8ACgkQCJIWIbr9KYx1EgCaA3UQgSobJ14lRBf/zwcMxn+A
> zi4AoNwNo22SYn9TNJoEg/n2BPlb8mvL
> =ZIZ0
> -END PGP SIGNATURE-
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Adding docs.zope.org/zodb

[Martijn Faassen]

Hey,

Laurence Rowe wrote:
> I've added the ZODB developers guide to the zope2docs buildout 
> (converting it to rst) and added another article and some more links to 
> the zodb articles section, but ideally these should live in their own 
> directory. What do I need to do to make this happen?

Yay! Awesome! Thanks Jens also!

Regards,

Martijn



___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Martijn Faassen]

Hey,

Uli Fouquet wrote:
[snip]
> Beside this it would really be nice, if one could share code at least in
> the Zope-, Plone and collective repositories with less legal hassle. But
> I guess this was already discussed extensively here, so I'd better shut
> up ;)

Normally the way code is shared is not by copying it but simply 
importing it. :)

If you import, there's no problem building on BSD-licensed code from 
ZPL-ed code. Or LGPL-ed code either. Or vice-versa If you use code in 
any of those licenses relying on any other of those licenses, you'll 
just be able to use without concern. Only if you want to modify an 
underlying library do you need to think about the implications of the 
license.

Only building on GPL-ed code has some issues, but from what I understand 
the Plone developers have done quite a lot of work on making sure stuff 
is BSD-ed or LGPL-ed now. I'd recommend against building libraries in 
svn.zope.org that rely on a GPL-ed library for their operation (though I 
do not think it's formally disallowed).

Only if you copy code into our repository do you need to worry about 
licenses.

For small snippets of about 10 lines or so I think a combination of fair 
use and surface-rewrites which typically are useful anyway will take the 
license worries away (but I'm not a lawyher).

Larger pieces of code than that, i.e. you're forking, you need to worry 
about the license when submitting it to svn.zope.org. But that's one of 
the reasons we *have* our copyright policy! But when you fork you need 
to worry about other things anyway.

I'm glad this fork got unforked! Thanks Gary for pointing it out, Uli 
and Wichert for unforking, and others for helping Uli getting access and 
the like.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Uli Fouquet]

Hi there,

Hanno Schlichting wrote:

> Uli Fouquet wrote:

> > I put the sources in a private repository meanwhile. I'd prefer to put
> > the sources into Zope repository again, but if this is legally too
> > difficult, they will stay hosted elsewhere.
> 
> Why not merge it back to the original recipe in the collective now?

That's exactly what's happening right now :)

>  Just
>  tell me your plone.org username and I'll give you collective access in
> a matter of a day.

Looks like I was just to dumb to use my collective access correctly.
Many thanks to all friendly people that offered help! And my apologies
to the collective admins, esp. gotcha!

Beside this it would really be nice, if one could share code at least in
the Zope-, Plone and collective repositories with less legal hassle. But
I guess this was already discussed extensively here, so I'd better shut
up ;)

Best regards,

-- 
Uli



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Hanno Schlichting]

Andreas Jung wrote:
> I have no problem with the changes. You have my blessing if Hanno is ok
> with the changes from the Plone prospective.

I'm OK with the changes from the Plone perspective.

I do however have a concern from the Zope perspective ;)

What I'm worried about is what kind of migration we need for this to
happen and what kind of impact this can have on derived types which
might override the methods in question.

If someone overwrites _setOb and _delOb in custom classes without
calling the methods on the base classes or hasn't fully bought into the
events story, I'm a bit worried we get hard to track down
inconsistencies in the parent pointers.

Since these pointers will take precedence over any even manually crafted
Acquisition chains, certain operations might no longer be possible. An
object with parent pointers will have its real physical path as its
context. In the way Acquisition used to be used, it was quite possible
to change the context of things by crafting different AQ chains.

I'm quite certain that none of the code in Plone or on the CMF level has
such problems. But I have no idea what kind of code is out there in the
wild based on Zope2.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin

[Hanno Schlichting]

Hi.

Roger Ineichen wrote:
>> Roger Ineichen wrote:
>> Then there's some tests and description missing proving that 
>> intent. All I could read in the changelog and the skinnable 
>> tests was pointing in the other direction: Making it possible 
>> to use the Skinnable concept without relying on 
>> IBrowserRequest. The whole JSONRequest (which is not a 
>> BrowserRequest) tests inside skinnable.txt continue to work.
> 
> Yes, I think everything was tested, but probably future
> ideas are not documented. There where some discussion about
> to split each request into it's own packages.

Where did that discussion happen? All I have heard of was discussions at
PyCon, where nobody quite seemed to see any point in the whole different
request types story at all anymore.

I don't mind if the skinnable story gets less intermingled with the
request story in a new zope.skinnable package and breaks some backwards
compatibility at that point. Right now that mix of the two concepts is
so prevalent in all kinds of places, that I'd rather stay on the
backwards compatible side.

All ZCML browser directives by default register everything for
IDefaultBrowserLayer and expect those resources to be available on
"normal" browser requests. The test helpers in zope.app.testing to get
browser resources set up rely on the same mix of concerns. This stuff is
used all over the place without caring about loading zope.publisher's
ZCML right now.

>> All I did here was to move two constructs from ZCML into direct code.
>> The lines I added do exactly the same as the default adapter 
>> registered as:
> 
> Uhh, this is call hard coded and makes it impossible to
> exclude the adapter with the  directive.

I call that retaining sensible defaults. You can opt-out of the
IDefaultBrowserLayer for browser requests by providing your own
specialized adapter. I prefer no configuration for the most common case
with an opt-out scenario instead of the everything is opt-in behavior.

> I see two things which are bad. Skinnable depends now on
> IBrowserRequest. I moved the skinnable concept out of the
> browser request part. This allows us to separate the skinnable
> and all different request types into own packages if we do future 
> refactoring.

zope.publisher is the package that defines the IBrowserRequest
interface. It might make sense to split those concerns off into
different packages and then straighten out the dependencies. At that
point I can see having a setDefaultSkin method inside zope.skinnable
with a different behavior. But the one inside zope.publisher ought to
play nicely with IBrowserRequest.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Tests: 8 OK

[Zope Tests Summarizer]

Summary of messages to the zope-tests list.
Period Sun Apr 26 12:00:00 2009 UTC to Mon Apr 27 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope Tests.


Tests passed OK
---

Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Apr 26 20:42:32 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011563.html

Subject: OK : Zope-2.11 Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Apr 26 20:44:33 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011564.html

Subject: OK : Zope-trunk Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Apr 26 20:46:34 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011565.html

Subject: OK : Zope-trunk Python-2.5.4 : Linux
From: Zope Tests
Date: Sun Apr 26 20:48:37 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011566.html

Subject: OK : Zope-trunk Python-2.6.1 : Linux
From: Zope Tests
Date: Sun Apr 26 20:50:37 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011567.html

Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Apr 26 20:52:38 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011568.html

Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux
From: Zope Tests
Date: Sun Apr 26 20:54:38 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011569.html

Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux
From: Zope Tests
Date: Sun Apr 26 20:56:39 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011570.html

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Hanno Schlichting]

Uli Fouquet wrote:
> I put the sources in a private repository meanwhile. I'd prefer to put
> the sources into Zope repository again, but if this is legally too
> difficult, they will stay hosted elsewhere.

Why not merge it back to the original recipe in the collective now? Just
 tell me your plone.org username and I'll give you collective access in
a matter of a day.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ComputedAttribute Object

[Hermann Himmelbauer]

Am Montag 27 April 2009 10:59:21 schrieb Sandrine Meyantchop:
> sorry but self.title() don't work also

I personally get along in such situations by displaying something 
like "self.__dict__" or "dir(self)" in a log file and handling from object to 
object if necessary.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Uli Fouquet]

Hi there,

Uli Fouquet wrote: 

> Gary Poster wrote:
> > I'm concerned about the state of the zc.buildout template recipes.  I  
> > want one.  I want some one-off files, specific to a certain project,  
> > for which writing a standalone recipe feels very heavy.
> > 
> > Here are the template recipes I found:
> > 
> > collective.recipe.template (Wichert Akkerman)
> > iw.recipe.template (Ingeniweb)
> > inquant.recipe.textfile (Stefan Eletzhofer)
> > z3c.recipe.template (Uli Fouquet)
> > buildout_script (Nathan Yergler)
> > z3c.recipe.filetemplate (Philipp von Weitershausen)

[snip]

> > However, on starting to hack on its documentation to sketch the 
> > changes I wanted, I gradually realized that this was a fork of 
> > collective.recipe.template. Since collective.recipe.template is 
> > listed as BSD in setup.py (though I saw no explicit licensing 
> > otherwise), placing z3c.recipe.template in the zope.org ZPL-only 
> > repository is problematic.
> 
> > But meanwhile, I'm concerned about the state of
> z3c.recipe.template. 
> > IMO, Uli and Wichert should try to reconcile the licensing and
> forking 
> > issues (with Uli taking the lead in those discussions, ideally,
> since 
> > he is the one who forked). z3c.recipe.template should be removed
> from 
> > the zope.org repository, unless/until the licensing story is cleaned
> up.
> 
> I removed the source from the repository and asked Wichert for how to
> proceed. If there's a lawyer in the house: how can one switch from BSD
> to ZPL for derivative works if both parties agree?

I negotiated with Wichert and we will focus on
collective.recipe.template from now on. I'll apply all changes,
extensions, docs and tests that went into z3c.recipe.template (in fact
only a few lines were copied from c.r.template) now to
collective.recipe.template (one template generator less).

Wichert does not want to switch the license to avoid license
proliferation. I can understand that.

So, if you want to contribute (I'd be happy to see this), you can use
c.r.template from now on. Having template generating support in stock
buildout, however, would also be nice.

Best regards,

-- 
Uli



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ComputedAttribute Object

[robert rottermann]

I do not know
try
Title
Title()
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ComputedAttribute Object

[Sandrine Meyantchop]

sorry but self.title() don't work also
--- En date de : Lun 27.4.09, robert rottermann  a écrit :
De: robert rottermann 
Objet: Re: [Zope-dev] ComputedAttribute Object
À: elsand...@yahoo.fr
Cc: Zope-Dev@zope.org
Date: Lundi 27 Avril 2009, 9h23

Sandrine Meyantchop schrieb:
> i have only try with str, but the problem is that i want to have for
> example the title but str(self.title) return ComputedAttribute object at
> 0xb7cdb8a0.
self.title() ??

> 
> 
> --- En date de : *Lun 27.4.09, robert rottermann
//* a
> écrit :
> 
> De: robert rottermann 
> Objet: Re: [Zope-dev] ComputedAttribute Object
> À: elsand...@yahoo.fr
> Cc: Zope-Dev@zope.org
> Date: Lundi 27 Avril 2009, 8h40
> 
> Sandrine Meyantchop schrieb:
> > Hello,
> > i want to know how i can convert a ComputedAttribute Object to a
String.
> > I have exactly the problem explain here:
> > http://www.zope.org/Collectors/Ape/19
> > but i want to have a string in state of a ComputedAttribute
Object.
> >
>  Any Ideas??
> > Sandra
> > 
> > 
> > 
> >

> > 
> > ___
> > Zope-Dev maillist  -  Zope-Dev@zope.org
> > http://mail.zope.org/mailman/listinfo/zope-dev
> > **  No cross posts or HTML encoding!  **
> > (Related lists - 
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope )
> str(object) ??
> 
> 
> 
> 
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )




  ___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin

[Roger Ineichen]

Hi Hanno

Regards
Roger Ineichen
_
END OF MESSAGE
  

> -Ursprüngliche Nachricht-
> Von: Hanno Schlichting [mailto:hanno...@hannosch.eu] 
> Gesendet: Montag, 27. April 2009 09:16
> An: d...@projekt01.ch
> Betreff: Re: AW: [Checkins] SVN: zope.publisher/trunk/ Added 
> some BBB code to setDefaultSkin
> 
> Hi.
> 
> Roger Ineichen wrote:
> >> Log message for revision 99518:
> >>   Added some BBB code to setDefaultSkin to allow 
> IBrowserRequest's to 
> >> continue to work without configuring any special adapter for 
> >> IDefaultSkin. Lot's of code inside Zope2 relying on using 
> the request 
> >> object without tons of CA setup
> > 
> > I don't comment this.
> > 
> > but,
> > You broke my hole refactoring. My refactoring was making it 
> possible 
> > to use IDefaultBrowserLayer less IBrowserRequest.
> > 
> > Your changes apply now to every IBrowserRequest an 
> > IDefaultBrowserLayer where explicit was no default layer configured 
> > for. This is bad because and makes the previous refactoring 
> obsolate.
> > 
> > Can you revert this changes?
> 
> Then there's some tests and description missing proving that 
> intent. All I could read in the changelog and the skinnable 
> tests was pointing in the other direction: Making it possible 
> to use the Skinnable concept without relying on 
> IBrowserRequest. The whole JSONRequest (which is not a 
> BrowserRequest) tests inside skinnable.txt continue to work.

Yes, I think everything was tested, but probably future
ideas are not documented. There where some discussion about
to split each request into it's own packages.

> All I did here was to move two constructs from ZCML into direct code.
> The lines I added do exactly the same as the default adapter 
> registered as:

Uhh, this is call hard coded and makes it impossible to
exclude the adapter with the  directive.

>  name="default"
> factory=".skinnable.getDefaultSkin"
> for="zope.publisher.interfaces.browser.IBrowserRequest"
> provides="zope.publisher.interfaces.IDefaultSkin"
> />
> 
> Unless I got something wrong, no behavior was changed if you 
> load zope.publisher's configure.zcml. For Zope2 it is now 
> just possible to continue to ignore that configure.zcml as it 
> had done before.

I see two things which are bad. Skinnable depends now on
IBrowserRequest. I moved the skinnable concept out of the
browser request part. This allows us to separate the skinnable
and all different request types into own packages if we do future 
refactoring.

And each IBrowserRequest will get typed by a IDefaultBrowserLayer
which doesn't allow to have a default skin less browser request.

I still think we should revert this changes. The skinnable concept
is a base pattern which should not know about the different request
types.

Regards
Roger Ineichen

> Hanno
> 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [cmf-tests] UNKNOWN : CMF-trunk Zope-trunk Python-2.6.1 : Linux

[Stefan H. Holek]

What's the reason zope.component.interfaces has no BBB for this  
import? The Zope Toolkit is full of 'deprecated()', so why not in this  
case?

Stefan


On 27.04.2009, at 03:28, CMF Tests wrote:

> CMF Tests : UNKNOWN
> CMF-trunk Zope-trunk Python-2.6.1 : Linux
>
> Running /usr/local/python2.6/bin/python ./bin/test
> Test-module import failures:
>
> Module: Products.CMFCore.tests.test_DynamicType
>
> Traceback (most recent call last):
>  File "/home/stefan/autotest/temp/python26-zope212-cmf22/src/ 
> Products.CMFCore/Products/CMFCore/tests/test_DynamicType.py", line  
> 26, in 
>from zope.component.interfaces import IDefaultViewName
> ImportError: cannot import name IDefaultViewName

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ComputedAttribute Object

[robert rottermann]

Sandrine Meyantchop schrieb:
> i have only try with str, but the problem is that i want to have for
> example the title but str(self.title) return ComputedAttribute object at
> 0xb7cdb8a0.
self.title() ??

> 
> 
> --- En date de : *Lun 27.4.09, robert rottermann //* a
> écrit :
> 
> De: robert rottermann 
> Objet: Re: [Zope-dev] ComputedAttribute Object
> À: elsand...@yahoo.fr
> Cc: Zope-Dev@zope.org
> Date: Lundi 27 Avril 2009, 8h40
> 
> Sandrine Meyantchop schrieb:
> > Hello,
> > i want to know how i can convert a ComputedAttribute Object to a String.
> > I have exactly the problem explain here:
> > http://www.zope.org/Collectors/Ape/19
> > but i want to have a string in state of a ComputedAttribute Object.
> >
>  Any Ideas??
> > Sandra
> > 
> > 
> > 
> > 
> > 
> > ___
> > Zope-Dev maillist  -  Zope-Dev@zope.org
> > http://mail.zope.org/mailman/listinfo/zope-dev
> > **  No cross posts or HTML encoding!  **
> > (Related lists - 
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope )
> str(object) ??
> 
> 
> 
> 
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin

[Hanno Schlichting]

Hi.

Roger Ineichen wrote:
>> Log message for revision 99518:
>>   Added some BBB code to setDefaultSkin to allow 
>> IBrowserRequest's to continue to work without configuring any 
>> special adapter for IDefaultSkin. Lot's of code inside Zope2 
>> relying on using the request object without tons of CA setup
> 
> I don't comment this.
> 
> but,
> You broke my hole refactoring. My refactoring was making it
> possible to use IDefaultBrowserLayer less IBrowserRequest.
> 
> Your changes apply now to every IBrowserRequest an 
> IDefaultBrowserLayer where explicit was no default
> layer configured for. This is bad because and makes
> the previous refactoring obsolate.
> 
> Can you revert this changes?

Then there's some tests and description missing proving that intent. All
I could read in the changelog and the skinnable tests was pointing in
the other direction: Making it possible to use the Skinnable concept
without relying on IBrowserRequest. The whole JSONRequest (which is not
a BrowserRequest) tests inside skinnable.txt continue to work.

All I did here was to move two constructs from ZCML into direct code.
The lines I added do exactly the same as the default adapter registered as:



Unless I got something wrong, no behavior was changed if you load
zope.publisher's configure.zcml. For Zope2 it is now just possible to
continue to ignore that configure.zcml as it had done before.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ComputedAttribute Object

[Sandrine Meyantchop]

i have only try with str, but the problem is that i want to have for example 
the title but str(self.title) return ComputedAttribute object at 0xb7cdb8a0. 


--- En date de : Lun 27.4.09, robert rottermann  a écrit :
De: robert rottermann 
Objet: Re: [Zope-dev] ComputedAttribute Object
À: elsand...@yahoo.fr
Cc: Zope-Dev@zope.org
Date: Lundi 27 Avril 2009, 8h40

Sandrine Meyantchop schrieb:
> Hello,
> i want to know how i can convert a ComputedAttribute Object to a String.
> I have exactly the problem explain here:
> http://www.zope.org/Collectors/Ape/19
> but i want to have a string in state of a ComputedAttribute Object.
> Any Ideas??
> Sandra
> 
> 
> 
> 
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
str(object) ??




  ___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )