Re: [Zope3-dev] Re: What does python 3000 mean for zope?
On 8/31/07, Stephan Richter <[EMAIL PROTECTED]> wrote: > That's is what I am most worried about. I really need to look into this to see > how much things changed. Maybe not as much as we tend to think. I think the changes will be substantial, both for Python code and for C extensions. A biggie is going to be the replacement of immutable str for binary data; that gets replaced with a mutable bytes object. It'll be good to have, but the loss of an immutable sequence-of-bytes type seems like a problem to me. On the other hand, we gain ordinary string literals being Unicode. I'm not sure what will happen with the standard library; it's just too early to say. I don't actually expect huge changes there, aside from changes required by the str->bytes replacement. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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: What does python 3000 mean for zope?
On Friday 31 August 2007 20:16, Philipp von Weitershausen wrote: > C extensions, anyone? That's is what I am most worried about. I really need to look into this to see how much things changed. Maybe not as much as we tend to think. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
David Pratt wrote: Hi. I am concerned about the announcement of python 3000 today that will break backwards compatibility. Zope and twisted are my favorite frameworks. The code base for both frameworks are not small. I haven't evaluated the changes but I can say this is a not great day for the python community either. I can see this dividing folks between present and future. Particularly, I'm thinking about incompatibilities developing around packages and dependencies through some sort of drawn out transition by the python community that may take years. Has anyone thoughts or comments about python 3000 implications for zope? Unfortunately, my first thoughts are that Python 3000 feels like Y2K for python :-(. Many thanks. We're currently struggling to get to Python 2.5 (which isn't exactly fresh out of the oven) mostly due to incompatibilities that it introduced compared to Python 2.4. So when Guido says Py3k will allow incompatible changes for the "first time", it'll be hard to imagine how big the implications really are. It's especially hard to imagine because Py3k isn't done yet. Will the stdlib be reorganized? Who knows. I sure would like to see this '2to3' tool tackle the Zope codebase. C extensions, anyone? Zope is depending on a lot of third party code. This is a good thing, it helps us focusing on what do best: write web apps. But before those dependencies aren't ported yet, we might just as well sit back and enjoy Python 2.x. The flip side of the coin is, however, that with our many individual libraries, it could be easier to tackle (provided we manage to down on those interdependencies). I'm not saying Zope never will or should or can run on Py3k, but I trust it'll be on Python 2.x for a long time still. And that can't be too bad, it has been for many years now after all. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] What does python 3000 mean for zope?
Hi. I am concerned about the announcement of python 3000 today that will break backwards compatibility. Zope and twisted are my favorite frameworks. The code base for both frameworks are not small. I haven't evaluated the changes but I can say this is a not great day for the python community either. I can see this dividing folks between present and future. Particularly, I'm thinking about incompatibilities developing around packages and dependencies through some sort of drawn out transition by the python community that may take years. Has anyone thoughts or comments about python 3000 implications for zope? Unfortunately, my first thoughts are that Python 3000 feels like Y2K for python :-(. Many thanks. Regards, David ___ 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.sendmail having dependency on zope.app.comonent
Am Freitag, den 31.08.2007, 14:04 +0200 schrieb Christophe Combelles: > I was still using vocabularies, but it seems interesting, thanks for the > explanation! > So it basically looks like a vocabulary, with the token and title parts being > seperated and optional. Right, and with defaults (I tried to find good defaults) for generating titles and tokens for almost any objects. ___ 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.sendmail having dependency on zope.app.comonent
On Fri, Aug 31, 2007 at 01:21:08PM +0200, Christian Theune wrote: > Am Freitag, den 31.08.2007, 13:06 +0200 schrieb Wichert Akkerman: > > Is there documentation on sources anywhere? The last time I checked > > there was nothing that I could understand either in zope.* or > > on the wiki. > > It took me a while to understand them myself. Especially as there is > some code in there that is basically not useful. > > I'll try to give a very short overview: How do you feel about adding it to the top of zope/schema/sources.txt? Marius Gedminas -- We don't care. We don't have to. We're the Phone Company. 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.sendmail having dependency on zope.app.comonent
Christian Theune a écrit : Hi, Am Freitag, den 31.08.2007, 13:06 +0200 schrieb Wichert Akkerman: Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. It took me a while to understand them myself. Especially as there is some code in there that is basically not useful. I'll try to give a very short overview: Sources are designed with three concepts: - The source itself - an iterable This can return any kind of object it wants. It doesn't have to care for browser representation, encoding, ... - A way to map a value from the iterable to something that can be used for form *values* - this is called a token - A way to map a value to something that can be displayed to the user - this is called a title The last two elements are dispatched using a so called `term`. The ITitleTokenizedTerm interface contains a triple of (value, token, term). Additionally there are some lookup functions to perform the mapping between values and terms and tokens and terms. Sources that require context use a special factory: a context source binder that is called with the context and instanciates the source when it is actually used. The general design is very nice as it seperates the concerns correctly, for simple use cases it requires you to write quite a few components (3 classes most times) which is why I came up with zc.sourcefactory which basically provides a cleaner easy-to-use API for (as the name says) application developers while having the backend APIs be logically sound. Hope this helped, Christian I was still using vocabularies, but it seems interesting, thanks for the explanation! So it basically looks like a vocabulary, with the token and title parts being seperated and optional. Christophe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/ccomb%40free.fr ___ 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.sendmail having dependency on zope.app.comonent
Hi, Am Freitag, den 31.08.2007, 13:06 +0200 schrieb Wichert Akkerman: > Is there documentation on sources anywhere? The last time I checked > there was nothing that I could understand either in zope.* or > on the wiki. It took me a while to understand them myself. Especially as there is some code in there that is basically not useful. I'll try to give a very short overview: Sources are designed with three concepts: - The source itself - an iterable This can return any kind of object it wants. It doesn't have to care for browser representation, encoding, ... - A way to map a value from the iterable to something that can be used for form *values* - this is called a token - A way to map a value to something that can be displayed to the user - this is called a title The last two elements are dispatched using a so called `term`. The ITitleTokenizedTerm interface contains a triple of (value, token, term). Additionally there are some lookup functions to perform the mapping between values and terms and tokens and terms. Sources that require context use a special factory: a context source binder that is called with the context and instanciates the source when it is actually used. The general design is very nice as it seperates the concerns correctly, for simple use cases it requires you to write quite a few components (3 classes most times) which is why I came up with zc.sourcefactory which basically provides a cleaner easy-to-use API for (as the name says) application developers while having the backend APIs be logically sound. Hope this helped, Christian ___ 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.sendmail having dependency on zope.app.comonent
Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: On 30 Aug 2007, at 14:19 , Michael Howitz wrote: Am 22.08.2007 um 15:53 schrieb Philipp von Weitershausen: Michael Howitz wrote: while looking at the dependencies of packages in the zope.* namespace at gocept we found out that zope.sendmail depends on zope.app.component. Just to make sure: If we ever had a formal distinction of the zope.* and zope.app.* namespaces, I think we've abandoned it a while ago already. So, it doesn't matter whether a package is in zope.* or zope.app.*, we need to take all interdependencies (also the ones in zope.app.*) into account. So all in all I don't think it's a big problem in zope.sendmail depended on zope.app.component, as long as zope.app.component wouldn't depend on a gazillion other things... So, you suggest to leave this dependency as it is as long no-one complains? In general, yes. That said, zope.app.component isn't the lightest dependency. It draws in almost all of zope.app.* zope.sendmail needs zope.app.component.vocabulary.UtilityVocabulary to define a vocabulary for the utilities implementing zope.sendmail.interfaces.IMailDelivery. So we'd suggest to move zope.app.component.vocabulary.UtilityVocabulary out of the zope.app.* namespace because it is a generic vocabulary. Possible places for UtilityVocabulary could be zope.component (because the concept of utilities is defined there) or zope.schema (because the concept of vocabularies is defined there). zope.schema seems to be the better place because zope.component does not depend on zope.schema yet. But zope.schema does in no way depend on zope.component. Yes, you are right. So we would introduce a dependency from zope.schema to zope.comonent. The only way to get lost of the zope.app dependency seems to be a new package "zope.app.sendmail" (including deprecation!). But there is already a zope.app.mail which is deprecated and will be removed in 3.5. I don't understand why that is "the only way" and why we have to create more packages in that dreadful zope.app.* namespace. One way to break this dependency is to move the UtilityVocabulary out to a separate package, e.g. zope.utilityvocabulary. Another way is to simply stop using UtilityVocabulary; this would also be an opportunity to replace it with a source. zc.sourcefactory is supposed to make this quite easy (and from what I've seen, it does), but unfortunately its dependencies aren't exactly light-weight either. Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. There are some docs here: http://pypi.python.org/pypi/zc.sourcefactory 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] Re: zope.sendmail having dependency on zope.app.comonent
Previously Philipp von Weitershausen wrote: > On 30 Aug 2007, at 14:19 , Michael Howitz wrote: > > >Am 22.08.2007 um 15:53 schrieb Philipp von Weitershausen: > > > >>Michael Howitz wrote: > >>>while looking at the dependencies of packages in the zope.* > >>>namespace at gocept we found out that zope.sendmail depends on > >>>zope.app.component. > >> > >>Just to make sure: If we ever had a formal distinction of the > >>zope.* and zope.app.* namespaces, I think we've abandoned it a > >>while ago already. So, it doesn't matter whether a package is in > >>zope.* or zope.app.*, we need to take all interdependencies (also > >>the ones in zope.app.*) into account. So all in all I don't think > >>it's a big problem in zope.sendmail depended on > >>zope.app.component, as long as zope.app.component wouldn't depend > >>on a gazillion other things... > > > >So, you suggest to leave this dependency as it is as long no-one > >complains? > > In general, yes. That said, zope.app.component isn't the lightest > dependency. It draws in almost all of zope.app.* > > >>>zope.sendmail needs > >>>zope.app.component.vocabulary.UtilityVocabulary to define a > >>>vocabulary for the utilities implementing > >>>zope.sendmail.interfaces.IMailDelivery. > >>>So we'd suggest to move > >>>zope.app.component.vocabulary.UtilityVocabulary out of the > >>>zope.app.* namespace because it is a generic vocabulary. > >>>Possible places for UtilityVocabulary could be zope.component > >>>(because the concept of utilities is defined there) or > >>>zope.schema (because the concept of vocabularies is defined there). > >>>zope.schema seems to be the better place because zope.component > >>>does not depend on zope.schema yet. > >> > >>But zope.schema does in no way depend on zope.component. > > > >Yes, you are right. So we would introduce a dependency from > >zope.schema to zope.comonent. > >The only way to get lost of the zope.app dependency seems to be a > >new package "zope.app.sendmail" (including deprecation!). But there > >is already a zope.app.mail which is deprecated and will be removed > >in 3.5. > > I don't understand why that is "the only way" and why we have to > create more packages in that dreadful zope.app.* namespace. > > One way to break this dependency is to move the UtilityVocabulary out > to a separate package, e.g. zope.utilityvocabulary. > > Another way is to simply stop using UtilityVocabulary; this would > also be an opportunity to replace it with a source. zc.sourcefactory > is supposed to make this quite easy (and from what I've seen, it > does), but unfortunately its dependencies aren't exactly light-weight > either. Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.sendmail having dependency on zope.app.comonent
On 30 Aug 2007, at 14:19 , Michael Howitz wrote: Am 22.08.2007 um 15:53 schrieb Philipp von Weitershausen: Michael Howitz wrote: while looking at the dependencies of packages in the zope.* namespace at gocept we found out that zope.sendmail depends on zope.app.component. Just to make sure: If we ever had a formal distinction of the zope.* and zope.app.* namespaces, I think we've abandoned it a while ago already. So, it doesn't matter whether a package is in zope.* or zope.app.*, we need to take all interdependencies (also the ones in zope.app.*) into account. So all in all I don't think it's a big problem in zope.sendmail depended on zope.app.component, as long as zope.app.component wouldn't depend on a gazillion other things... So, you suggest to leave this dependency as it is as long no-one complains? In general, yes. That said, zope.app.component isn't the lightest dependency. It draws in almost all of zope.app.* zope.sendmail needs zope.app.component.vocabulary.UtilityVocabulary to define a vocabulary for the utilities implementing zope.sendmail.interfaces.IMailDelivery. So we'd suggest to move zope.app.component.vocabulary.UtilityVocabulary out of the zope.app.* namespace because it is a generic vocabulary. Possible places for UtilityVocabulary could be zope.component (because the concept of utilities is defined there) or zope.schema (because the concept of vocabularies is defined there). zope.schema seems to be the better place because zope.component does not depend on zope.schema yet. But zope.schema does in no way depend on zope.component. Yes, you are right. So we would introduce a dependency from zope.schema to zope.comonent. The only way to get lost of the zope.app dependency seems to be a new package "zope.app.sendmail" (including deprecation!). But there is already a zope.app.mail which is deprecated and will be removed in 3.5. I don't understand why that is "the only way" and why we have to create more packages in that dreadful zope.app.* namespace. One way to break this dependency is to move the UtilityVocabulary out to a separate package, e.g. zope.utilityvocabulary. Another way is to simply stop using UtilityVocabulary; this would also be an opportunity to replace it with a source. zc.sourcefactory is supposed to make this quite easy (and from what I've seen, it does), but unfortunately its dependencies aren't exactly light-weight either. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
