Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 17. Januar 2007 22:49:11 +0100 Dieter Maurer <[EMAIL PROTECTED]> wrote: Andreas Jung wrote at 2007-1-17 17:48 +0100: ... So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). In future times, the preamble might contain information which should not be dropped, e.g. when there is an XML version different from "1.0". We're faster with new Zope versions than the W3C with any standard. For PageTemplates, we know that the encoding information is probably not relevant after the parsing -- unless we want to use it as a default for the "Content-Type" charset but I doubt that this is a good thing. If the "Content-Type"'s charset is given explicitely, then the "encoding" of the XML declaration needs to be adapted to this value during the serialization anyway -- thus overriding any "encoding" present there. ? -aj pgpGl17OH27Hh.pgp Description: PGP signature ___ 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: SVN: zope.app.annotation/ Add zope.app.annotation as a top-level package.
Philipp von Weitershausen wrote: I suggest we come up with a prioritized list instead of alphabetical. +1 > Baiju M wrote: We can eggify all packages except those in Spring cleanup proposal [1] Sure, we *can*, but I think it's a lot of work and we don't necessarily have to do all of them. That isn't to say I don't appreciate your work going into this effort, I just think it could be used more effectively ;) This /is/ to say that I appreciate your work on this, Baiju. :) -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Idea: Failure to lookup adapters
Stephan Richter wrote: On Monday 15 January 2007 14:25, Sidnei da Silva wrote: 'We've tried to look up an adapter for (ISomething, ITheOther) but none was found' 'Found an adapter for IFoo, which is a base class for the IBar interface requested. No adapter has been found for the most-specific interface IBar' Comments? My major concern is speed here. It's a bit early to have that concern, we haven't even come up with a strategy yet ;). "Premature optimization is the root of all evil" -- Donald E. Knuth Any debug handling will make the registry slower; I am using adapters very heavily in my code and any slow-down of one lookup would be multiplied many times. There are certainly ways in Python to have debug code in an application that won't be run in production mode, e.g.: if __debug__: # do expensive logging call here, or whatever Code like this won't be run with python -O (which is what you'd obviously use in production). I wonder whether a different approach could be taken. The APIDOC code does already a registration analysis. Maybe we can use the registrations in a away that they simulate the adapter registry. Thus you could provide APIDOC (via the Web UI or Python) with a component or instance and it tells you how it tries to look up the adapter. Clearly that would be much slower, but okay for inspection. Sounds good. I like the explainAdapter() suggestion. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wildcard adapter
Martin Aspeli wrote: Chris Withers wrote: Hi All, I was wondering if someone could give me a definitive explanation of what the following means: No, but this is: provideAdapter(...,adapts=(Interface, ISomething, Interface),...) Actually, ZCML translates a "*" to None. And as of Zope 3.3, adapting None or Interface is equivalent. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wildcard adapter
Chris Withers wrote: Hi All, I was wondering if someone could give me a definitive explanation of what the following means: Yes. If it is, then which of the following should I use to register a generic adapter for any single object to an interface: provideAdapter(...,adapts=(None,),...) This one. provideAdapter(...,adapts=None,...) This will give you most likely an error. I'm not having a lot of joy registering generic adapters so I thought I'd come and check my understanding here ;-) I have no idea what a "generic" adapter is, but the zope.component API docs (== interfaces) are certainly complete in this sense. There are also doctests. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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.tal.xmlparser.XMLParser() dislikes unicode
Andreas Jung wrote at 2007-1-17 17:48 +0100: > ... >So Martijn's and my proposal remain. They are not very different. In the >end the behavior is almost identical. But I will adopt your suggestion to >remove >the preamble when storing the data internally (basically to avoid a >possible encoding ambiguity). In future times, the preamble might contain information which should not be dropped, e.g. when there is an XML version different from "1.0". For PageTemplates, we know that the encoding information is probably not relevant after the parsing -- unless we want to use it as a default for the "Content-Type" charset but I doubt that this is a good thing. If the "Content-Type"'s charset is given explicitely, then the "encoding" of the XML declaration needs to be adapted to this value during the serialization anyway -- thus overriding any "encoding" present there. -- Dieter ___ 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.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote at 2007-1-16 23:19 +0100: >Dieter Maurer wrote: >> Martijn Faassen wrote at 2007-1-15 15:44 +0100: >>> >>> I would say refusing to guess and bailing out with an error message is >>> better in this case. >> >> I disagree with you. >> >> Logically, parsing an encoded XML document consists of two >> passes: decode the encoded string into unicode and reconstruct >> the XML info elements from the serialization. >> >> Traditionally, these two passes are not performed one after >> the other but folded together in a single pass. >> >> But that tradition should not prevent to separate out the >> (Unicode) decoding phase. And after this phase is done, >> there is not ambiguity left with the "XML declaration". >> Its encoding attribute is simply irrelevant for the second phase >> (apart from generating the PI info element). > >That's nice as far as it goes. What if after the second phase you need >to parse the XML again? >What do you do with your encoding header then? After the second phase, I now longer have an XML string but instead either a sequence of events (SAX style) or a tree of XML info elements (syntax tree style). But, whatever I have, the second stage does not magically change my unicode string. It could be parsed over and over again. >If it's irrelevant, you better strip it out before you put it into the >parser. I loose information then. The event stream or info element tree lacks the XML declaration PI then, or at least its "encoding" attribute. The parsing process is allowed to loose some information. For example it can loose whitespace details or the order of attributes. I don't know whether the loss or modification of "PI"s is considered acceptable. In general, this would definitely be wrong. I have read some article in "comp.text.xml" that complained about the loss of the encoding information -- at it may be a good hint about the default encoding to be used on encoding/serialization. This menas that some XML processing systems loose the information and not everyone is happy. -- 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: SVN: zope.app.annotation/ Add zope.app.annotation as a top-level package.
Baiju M wrote: Philipp von Weitershausen wrote: Baiju M wrote: > Log message for revision 72044: Add zope.app.annotation as a > top-level package. > > Changed: A zope.app.annotation/ A zope.app.annotation/branches/ > A zope.app.annotation/tags/ A zope.app.annotation/trunk/ > > -=- Is it really necessary to create the BBB packages in zope.app (annotation, traversing, etc.) as separate eggs? They're gonna go away in Zope 3.5 anyway. I think they could be part of the zope.app egg in Zope 3.4. I thought we can create individual eggs instead of a big zope.app egg for Zope 3.4. Well, I don't think we have to make every single subpackage its own egg. We should pick our battles and start with those individual eggs that can actually be used w/o Zope 3, e.g. zope.app.container, zope.app.form, etc. I don't think we need to create individual eggs for each package, especially those that will disappear soon anyway because of BBB. So I started working on eggification of zope.app.* packages in alphabetical order :) (zope.app.annotation was the first package) I suggest we come up with a prioritized list instead of alphabetical. We can eggify all packages except those in Spring cleanup proposal [1] Sure, we *can*, but I think it's a lot of work and we don't necessarily have to do all of them. That isn't to say I don't appreciate your work going into this effort, I just think it could be used more effectively ;) -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Idea: Failure to lookup adapters
Stephan Richter wrote: My major concern is speed here. Any debug handling will make the registry slower; I am using adapters very heavily in my code and any slow-down of one lookup would be multiplied many times. + sys.maxint. 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] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote: That's what I do too... See my post elsewhere in the thread for an example of why this is Not Good. Luckily Twiddler is still less than version 1.0 ;-) When someone reports it as a bug, I'll fix it. 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] wildcard adapter
On Wed, Jan 17, 2007 at 06:37:52AM -0800, Martin Aspeli wrote: > Chris Withers wrote: > > I was wondering if someone could give me a definitive explanation of > > what the following means: > > > > > for="* ISomething *" > > ... > > > > ...means? > > > > Is the following equivalent: > > > > provideAdapter(...,adapts=(None,ISomething,None),...) > > No, but this is: > > provideAdapter(...,adapts=(Interface, ISomething, Interface),...) As far as I know provideAdapter treats None the same way as Interface. I've used this pattern a few times: from zope.adapter import adapts, provideAdapter from zope.interface import implements ... class SomeAdapter(object): adapts(None) implements(IFoo) ... provideAdapter(SomeAdapter) BTW passing interfaces to provideAdapter/ is out of fashion. I prefer using zope.component.adapts and zope.interface.implements (or zope.component.adapter and zope.interface.implementer, when my adapter is a function rather than a class). Marius Gedminas -- America and England are two countries separated by a common language. signature.asc Description: Digital signature ___ 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.tal.xmlparser.XMLParser() dislikes unicode
--On 16. Januar 2007 14:12:46 +0100 Martijn Faassen <[EMAIL PROTECTED]> wrote: I am replying to the three proposals. First I have to kick the proposal of Tres (UTF-8 storage). We want unicode as internal representation for any kind of ZPT (both text/html and text/xml). Supporting unicode for text/html and utf-8 for text/xml would make code more complicated and lead to further unicode encoding conflicts. We're trying to solve this issue right now and I don't want to introduce a new construction site. So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). Andreas pgpxXQNoRi2gs.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
Chris Withers wrote: > > Hi All, > > I was wondering if someone could give me a definitive explanation of > what the following means: > > for="* ISomething *" > ... > > ...means? > > Is the following equivalent: > > provideAdapter(...,adapts=(None,ISomething,None),...) > No, but this is: provideAdapter(...,adapts=(Interface, ISomething, Interface),...) > If it is, then which of the following should I use to register a generic > adapter for any single object to an interface: > > provideAdapter(...,adapts=(None,),...) > provideAdapter(...,adapts=None,...) > > I'm not having a lot of joy registering generic adapters so I thought > I'd come and check my understanding here ;-) > provideAdapter(adapts=(Interface,), ...) Martin -- View this message in context: http://www.nabble.com/wildcard-adapter-tf3027563.html#a8411297 Sent from the Zope3 - dev mailing list archive 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] wildcard adapter
Hi All, I was wondering if someone could give me a definitive explanation of what the following means: If it is, then which of the following should I use to register a generic adapter for any single object to an interface: provideAdapter(...,adapts=(None,),...) provideAdapter(...,adapts=None,...) I'm not having a lot of joy registering generic adapters so I thought I'd come and check my understanding here ;-) 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
[Zope3-dev] Re: SVN: zope.app.annotation/ Add zope.app.annotation as a top-level package.
Philipp von Weitershausen wrote: Baiju M wrote: > Log message for revision 72044: Add zope.app.annotation as a > top-level package. > > Changed: A zope.app.annotation/ A zope.app.annotation/branches/ > A zope.app.annotation/tags/ A zope.app.annotation/trunk/ > > -=- Is it really necessary to create the BBB packages in zope.app (annotation, traversing, etc.) as separate eggs? They're gonna go away in Zope 3.5 anyway. I think they could be part of the zope.app egg in Zope 3.4. I thought we can create individual eggs instead of a big zope.app egg for Zope 3.4. So I started working on eggification of zope.app.* packages in alphabetical order :) (zope.app.annotation was the first package) We can eggify all packages except those in Spring cleanup proposal [1] BTW, There will be a "Zope 3 Egg Day !" [2] on next Saturday (20-Jan-2007) and it will continue on Sunday [3] if there is interest. [1] http://wiki.zope.org/zope3/SpringCleaning07 [2] http://mail.zope.org/pipermail/zope3-dev/2007-January/021491.html [3] http://mail.zope.org/pipermail/zope3-dev/2007-January/021492.html Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attribute index indexing None if returned from callable
Hello Jürgen, Yep, +1. Did some changes around the subject but seems like it was not enough. The outcome of the story was the same: None should not get indexed. Wednesday, January 17, 2007, 1:35:04 PM, you wrote: > If a callable is used to provide the value for an attribute index in > zope.app.catalog value None is indexed. If the value is directly > provided by an attribute None is never indexed. > I would like to see the same behavior for both cases, that means None is > not indexed in either ways. > If no one complains I will check in the necessary changes. > Jürgen > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/adamg%40fw.hu -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: Epochs of faith are epochs of fruitfulness; but epochs of unbelief, however glittering, are barren of all permanent good. - Johann Wolfgang von Goethe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] attribute index indexing None if returned from callable
If a callable is used to provide the value for an attribute index in zope.app.catalog value None is indexed. If the value is directly provided by an attribute None is never indexed. I would like to see the same behavior for both cases, that means None is not indexed in either ways. If no one complains I will check in the necessary changes. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] server error in apidoc (encoding pb)
Dmitry Vasiliev a écrit : Christophe Combelles wrote: Did someone have a look on this error ? Is it a trivial thing, or a local configuration problem, or is it reproduceable? (I write in utf-8, and I put # -*- coding: utf-8 -*- in my interfaces.py) You must use unicode docstrings. The encoding declaration at the top of the module doesn't do any magic by itself but just tells Python from which encoding unicode strings can be decoded. So your module should looks like this: # -*- coding: utf-8 -*- u"""Some docstring text in utf-8.""" That's it, that was actually trivial, I forgot the 'u' :) thanks ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
