[Zope] Get raw data (byte array) from flash in Zope
Hello everyone, I have a question about how to get raw data sent by a flash application in Zope (a zope method/function). The flash application uses the method in the link below to send to the server an image (jpg): http://www.zedia.net/2008/sending-bytearray-and-variables-to-server-side-script-at-the-same-time/ Searching through the internet I have found a PHP example that gets this byte array sent from flash: http://blog.joa-ebert.com/2006/05/01/save-bytearray-to-file-with-php/ They are getting the date form a header called HTTP_RAW_POST_DATA. The question is: how can I get this data on the server side in Zope? Becasue: - REQUEST.form is empty - HTTP_RAW_POST_DATA is missing - there is no other key or value in the REQUEST to indicate the value I am looking for On my local devel machine I managed to find a solution: - using Zope 2.10.3 I have enabled use-wsgi (on) (without apache) - in zope, the method called from flash is something like this: ... v = REQUEST.environ['wsgi.input'] v.seek(0) f = open(join(SOME_PATH, 'image.jpg'), 'wb') f.write(v.read()) f.close() return '1' This solution doesn't work on the production environment - Zope 2.11.4 with ZEO (pound and apache in the front of zope as load balancer and web server). Is there a way to solve this problem? Any idea is highly appreciated. Thank you very much, Dragos -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Get raw data (byte array) from flash in Zope
Try REQUEST.BODYFILE On 25.11.2009, at 12:30, Dragos Chirila wrote: The question is: how can I get this data on the server side in Zope? Becasue: - REQUEST.form is empty - HTTP_RAW_POST_DATA is missing - there is no other key or value in the REQUEST to indicate the value I am looking for -- Stefan H. Holek ste...@epy.co.at ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Get raw data (byte array) from flash in Zope
Doesn't work: AttributeError: BODYFILE On Wed, Nov 25, 2009 at 1:59 PM, Stefan H. Holek ste...@epy.co.at wrote: Try REQUEST.BODYFILE On 25.11.2009, at 12:30, Dragos Chirila wrote: The question is: how can I get this data on the server side in Zope? Becasue: - REQUEST.form is empty - HTTP_RAW_POST_DATA is missing - there is no other key or value in the REQUEST to indicate the value I am looking for -- Stefan H. Holek ste...@epy.co.at -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Frequent ZOPE crashes
Hello Mailinglist, we've been using ZOPE in combination with the Silva CMS for around four years now to serve our University's homepage. And everything worked fine so far. A week ago we switched to a new layout (for corporate reasons) and now we're experiencing frequent crashes of the Zope servers. Fortunately enough the reconnect themselves to the ZODB but since this is now happening around every five minutes, I'm rather worried that this might permanently damage the ZODB. I have absolutely no idea how this can happen, as we're using the same python, libxml2, libxslt and other module versions as with the old homepage - in fact the new site even runs on the same hardware. We never experienced any problems like these up until now. As far as I understood so far, it requires some C modules to successfully cause ZOPE to segfault? Versions we're using: Python 2.4.6 Zope 2.11.2 LibXML2 2.7.3 LibXSLT 1.1.24 Python-LDAP 2.3.6 Setuptools 0.6c9 and a Kerberos Module plus the Silva CMS (2.1) on top. We have four ZOPE servers, each running two ZEO processes and a separate ZODB. The machines all run RedHat Enterprise Linux 5.4. In front of that Apache, Squid and Pound take care of the caching. What we did was to examine the coredump-files with gdb but unfortunately this didn't prove to be very helpful because either things go wrong during garbage collection or some ceval stuff. So basically something trashes certain python-objects at time before. Do you have *any* hinst in how to track down this problem? Or are there any known problems with the versions above? The changelogs didn't reveal any plausible cause for me... Kind regards, Andreas Krasa ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Frequent ZOPE crashes
At first, try to eliminate error outside of the Zope itself. Try to install it all into plain whole new (and reliable!) machine. Do not use restore of any backups! - Original Message - From: Andreas Krasa andreas.kr...@wu-wien.ac.at A week ago we switched to a new layout (for corporate reasons) and now we're experiencing frequent crashes of the Zope servers. Fortunately ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Get raw data (byte array) from flash in Zope
The data is actually received by Zope, but its broken into pieces. Please find a sample of the REQUEST.form here http://media.fourhooks.ro/request_form.jpg Any hints on how to put the image back together? On Wed, Nov 25, 2009 at 4:58 PM, Dragos Chirila objectval...@gmail.com wrote: Doesn't work: AttributeError: BODYFILE On Wed, Nov 25, 2009 at 1:59 PM, Stefan H. Holek ste...@epy.co.at wrote: Try REQUEST.BODYFILE On 25.11.2009, at 12:30, Dragos Chirila wrote: The question is: how can I get this data on the server side in Zope? Becasue: - REQUEST.form is empty - HTTP_RAW_POST_DATA is missing - there is no other key or value in the REQUEST to indicate the value I am looking for -- Stefan H. Holek ste...@epy.co.at -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] dynamically call zsqlmethod
I am passing a variable named 'column' to the following script and trying to fill a select box with the result of a zsqlmethod chosen dynamically using this variable. print select name=nonboolean method=post command=context.column() for row in command: code=row.code meaning=row.meaning print option value=%s%s/option (code,meaning) print /select return printed I can not work out how to substitiute the command with the variable, any help much appreciated. Regards Garry ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] dynamically call zsqlmethod
getattr(context, column)()? -aj On Wed, Nov 25, 2009 at 19:53, Garry Saddington ga...@schoolteachers.co.ukwrote: I am passing a variable named 'column' to the following script and trying to fill a select box with the result of a zsqlmethod chosen dynamically using this variable. print select name=nonboolean method=post command=context.column() for row in command: code=row.code meaning=row.meaning print option value=%s%s/option (code,meaning) print /select return printed I can not work out how to substitiute the command with the variable, any help much appreciated. Regards Garry ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] dynamically call zsqlmethod
IF it's a variable passed to the script wouldn't you simply access it as 'column'? Also, is it a variable or a function? Or is the variable the name of a function somewhere? If it's the former just call it: column(). If it's the latter, Andreas should be correct, getattr(context, column)() or possible context[column] if you like that better. -- Jeffrey D Peterson Webmaster Crary Industries, Inc. -Original Message- From: zope-boun...@zope.org [mailto:zope-boun...@zope.org] On Behalf Of Garry Saddington Sent: Wednesday, November 25, 2009 12:53 PM To: zope@zope.org Subject: [Zope] dynamically call zsqlmethod I am passing a variable named 'column' to the following script and trying to fill a select box with the result of a zsqlmethod chosen dynamically using this variable. print select name=nonboolean method=post command=context.column() for row in command: code=row.code meaning=row.meaning print option value=%s%s/option (code,meaning) print /select return printed I can not work out how to substitiute the command with the variable, any help much appreciated. Regards Garry ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] dynamically call zsqlmethod
Jeff Peterson wrote: IF it's a variable passed to the script wouldn't you simply access it as 'column'? Also, is it a variable or a function? Or is the variable the name of a function somewhere? If it's the former just call it: column(). If it's the latter, Andreas should be correct, getattr(context, column)() or possible context[column] if you like that better. Thanks, Andreas' solution works for me. Regards Garry ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Nov 24 12:00:00 2009 UTC to Wed Nov 25 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Nov 24 20:38:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013077.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Nov 24 20:40:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013078.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Nov 24 20:42:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013079.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Nov 24 20:44:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013080.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Nov 24 20:46:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013081.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Nov 24 20:48:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013082.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope3 server with SIGSEGV - what to do?
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer du...@qwer.tk wrote: Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0). The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?). Yep. The introduction of so many non-backward-compatible changes in the last few years has also caused me great pain. Any ideas how to solve this? If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.schema2xml and z3c.schema2json
Hi, I'm about to work a bit on z3c.schema2json [1]. As has been briefly discussed before (a while ago [2]), z3c. schema2json is so similar to z3c.schema2xml [3] in what it does and how it does it, that I wonder about merging the two packages somehow. One way to do this - maybe - is to use named registrations for the (de)serialization adapters. The name could reflect the serialization mode - for example xml or json. But maybe there're other ideas to achieve this? Or, could it be that merging has no real benefit? regards, jw [1] http://svn.zope.org/Sandbox/paulwilson/z3c.schema2json/ [2] https://mail.zope.org/pipermail/zope-dev/2009-June/037091.html [3] http://svn.zope.org/z3c.schema2xml/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
Thomas Lotze wrote: Stephan Richter wrote: On Tuesday 24 November 2009, Thomas Lotze wrote: Could somebody please give me PyPI rights for zope.browserresource? I'd like to release a new version of it which includes the recent fixes to its dependencies. Thank you very much. I am in the process of making you all powerful. :-) Argh, now the PyPI UI is really broken for me... No, seriously - thank you very much. Yes, PyPI is broken if you're an admin of many packages, feel free to me too on this issue: http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503 Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document-navigation {overflow: scroll; max-height:
15em; width: 15em; overflow-x: hidden}');
--
Benji York
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
Benji York wrote:
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document-navigation {overflow: scroll; max-height:
15em; width: 15em; overflow-x: hidden}');
I'm not yet, but this may well be a reason to change that. Thank you very
much for the pointer.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] improving the utility and adapter lookup APIs
Hi there, Reading the thread Chris McDonough started (and ended) about modifying the way utility registration works reminded me of the following thinking. It's quite independent and probably even antithetical to Chris's approach as it uses interfaces, but that's fine. The goal is to make it easier to look up certain componenty things. The goal is to have to import from zope.component as little as possible for lookups. Just import interfaces and you'll be done. I think it makes sense to make the lookup operation disappear into the language as much as we can make them. I know we've had this kind of discussion before, but let's get something working this time around. So I'm also looking for volunteers to help out with the implementation. I'm going to ignore registration APIs for now in this discussion. While they can be improved too, we have ZCML and martian-style registration systems that can handle that ok. Let's focus on lookup APIs first. We have a nice way to look up a single adapter: from foo import IFoo IFoo(object) Unfortunately, this breaks down when you want to look up a multiadapter: from foo import IFoo from zope import component component.getMultiAdapter((x, y), IFoo) That's an extra import and a lot more typing. We also have it break down when you want to look up a utility: from zope import component component.getUtility(IFoo) So let's look at ways to hook this up to interfaces. Adapter: IFoo(x) Adapter with default: IFoo(x, default=default) So far it's all supported. (I think. It's hard to find the code that supports this.. hints?) Named adapter: IFoo(x, name='something') Multiadapter: IFoo.multi(x, y) Multiadapter with default: IFoo.multi(x, y, default=default) Named multiadapter: IFoo.multi(x, y, name='something') Utility: IFoo.utility() [or possibly IFoo() instead?] Utility with default: IFoo.utility(default=default) [or IFoo(default=default)?] Named utility: IFoo.utility(name='something') [or IFoo(name='something')?] As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass I know Jim had some objections towards implementation of this in an earlier discussion, but later changed his mind. So I'm going to look at Jim for hints about implementing this. :) If we do well we might all have this for Christmas. :) Thoughts? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: [snip good stuff] Multiadapter: IFoo.multi(x, y) I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) Multiadapter with default: IFoo.multi(x, y, default=default) Expanding the above: IFoo((x,y), default=default) Utility: IFoo.utility() [or possibly IFoo() instead?] I like IFoo(). As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass We already have the function decorator zope.interface.implementer, I'd extend that notion: @IFoo.implementer class Foo(object): pass If we do well we might all have this for Christmas. :) /me pens a letter to Zanta Claus. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? Matt ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote: ... Thoughts? FWIW, this mirrors some of the thoughts I've had, after a lot of discussions with Launchpad/Canonical engineers about the pros and cons of the Zope interface and component code. My OSCON presentation touched on some of these discussions, observations and ideas. Ideas on addressing the problems in the feedback are the focus of my upcoming PyCon presentation. I'm in the middle of an experiment to modify the code without backwards compatibility concerns, to see where it takes me. Obviously, there's an extremely high hurdle for backwards incompatibility, but it was the experiment I wanted to pursue, and one that (obviously) I felt had merit. My intent is to show these at PyCon and start a discussion about the value of the changes, what could be done without breaking backwards compatibility, what could be done with minimal backwards compatibility breakage, and if anything I discovered merits more significant breakage. I'd prefer to think about these myself for a while, and continue to experiment. I've already digested a lot of feedback, from the interviews at Launchpad and Canonical, from past mailing list discussions, from documents like BFG's design defence (http://docs.repoze.org/bfg/1.1/designdefense.html), and from personal discussions. Most people have heard some variation of the (perceived/real) problems before; I'm not ready to settle on my preferred solutions myself. I'm seeing how everything fits together, and it's a big puzzle to assemble. My experiments don't need to hold anyone else up, of course, but I do have a concrete deadline to deliver something. :-) I'll share once I feel that I am reasonably happy with my choices, which may or may not be significantly before PyCon. If other folks want to run on without me, I can at least point to the slides for the OSCON talk I gave with the Canonical/Launchpad feedback if you are interested. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. I do think, however, that this is more a problem with registration than with look-up. You need to know whether to register a factory or an instance of a component, but whatever you look up will provide the interface you require and doesn't have to be called in either case. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote: Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote: Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). Yeah, this is one of my goals too. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Chris McDonough wrote: There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). I realize this might be too abstract. Let me provide an example. Zope views accept (context, request) in their arglist: class AView(object): def __init__(self, context, request): pass This makes sense for Zope, because in a Zope system, the context is almost always important. It usually represents persistent data, or at least the subject of the view. But in other systems, you might want to adapt on a context but not require people to put it in the argument list of the adapter, e.g. if you want to support a request-only calling convention for the adapter ala: def view(request): pass ... and have the user be able to get at the context via request.context. The only way to do this currently is something like the following: provides = map(providedBy, (context, request)) view_callable = registry.adapters.lookup( provides, IView, name=view_name, default=None) request.context = context response = view_callable(request) This is actually fine by me, it works great, but it's not very obvious what's happening to the casual reader. getMultiAdapter should probably be have been named callMultiAdapter, and getMultiAdapter should have just returned the thing. Too late for that now, but it helps explain my original comment. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
On Wed, Nov 25, 2009 at 04:30:57PM +0100, Thomas Lotze wrote:
Benji York wrote:
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document-navigation {overflow: scroll; max-height:
15em; width: 15em; overflow-x: hidden}');
I'm not yet, but this may well be a reason to change that. Thank you very
much for the pointer.
PyPI made me not only become a greasemonkey user, but write this script:
http://userscripts.org/scripts/show/30836
Benji's solution seems simpler and more elegant.
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: [snip good stuff] Multiadapter: IFoo.multi(x, y) I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) +1 Multiadapter with default: IFoo.multi(x, y, default=default) Expanding the above: IFoo((x,y), default=default) +1 again. Utility: IFoo.utility() [or possibly IFoo() instead?] I like IFoo(). +1 (I argued for this spelling ages ago, like maybe 2002). As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass We already have the function decorator zope.interface.implementer, I'd extend that notion: @IFoo.implementer class Foo(object): pass +0 here: I don't mind the current pattern, but it might be needful to switch to support Lennart's / MvL's work on porting to Python 3. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNdwYACgkQ+gerLs4ltQ5MOQCeNsA1pDP2o9xnJp7w/axU4xaI 2HYAniCBpRY0TxV7BBkN6ad5Dtfg49kl =ySiv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNd4UACgkQ+gerLs4ltQ6+2gCcC1nsuHkvLHimLWvuXutREduQ rSYAnRNRep5iZVbpJqz0W/D3FQKoJwwP =vHqM -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. It doesn't matter *to the caller* how the adapter / utility lookup works, which is why making the spelling regular for the caller is a good idea. The caller doesn't know any different in the zope.component API: getUtility(IFoo) getAdapter(context, IFoo) They are both lookups, from the caller's perspective. Why should the caller care that the adapter lookup finds a factory and calls it, while the utility lookup (typically) finds a global singleton? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNeLcACgkQ+gerLs4ltQ6F9gCfXooovAG8fAKZtxL06++hPP/9 8H4AoITGogG8Mv4rg2M/FR1cyyOUZwFk =b2h1 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
* 2009-11-25 19:35, Tres Seaver wrote: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I'm probably saying something very stupid... What's wrong with the it? Can't we define something like: def __call__(self, *args, **kw): to get a multi adapter in this way? IFoo(x, y, default=None, name='something') Best regards, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote: Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. I am, in fact, adapting tuples for what I consider to be a good reason (pretty-printing arbitrary objects) in zodbbrowser. http://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/annotate/head:/src/zodbbrowser/value.py Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) This also doesn't allow you to use this (anti?)pattern: class Foo: implements(IFoo) def do_something(self): # custom behaviour here default_foo_adapter = getAdapter(self, IFoo) return default_foo_adapter.do_something() # fallback to default behaviour It may not be very theoretically correct, but it's something I find very useful when writing IPublishTraverse implementing classes for zope.publisher to traverse over. It saves me from having to inherit from the default traverser. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Sutherland wrote: On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) This also doesn't allow you to use this (anti?)pattern: class Foo: implements(IFoo) def do_something(self): # custom behaviour here default_foo_adapter = getAdapter(self, IFoo) return default_foo_adapter.do_something() # fallback to default behaviour It may not be very theoretically correct, but it's something I find very useful when writing IPublishTraverse implementing classes for zope.publisher to traverse over. It saves me from having to inherit from the default traverser. Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't:: $ bin/virtualenv-2.6 --no-site-packages /tmp/brian ... $ cd /tmp/brian $ bin/easy_install zope.component ... $ bin/python from zope.interface import Interface from zope.interface import implements class IFoo(Interface): ... pass ... from zope.component import getAdapter class Foo: ... implements(IFoo) ... foo = Foo() IFoo(foo) is foo True getAdapter(foo, IFoo) is foo Traceback (most recent call last): File stdin, line 1, in module ... zope.component.interfaces.ComponentLookupError: (__main__.Foo instance at 0xb7d0690c, InterfaceClass __main__.IFoo, u'') which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNmQIACgkQ+gerLs4ltQ7vgQCgyJqce5aMgNksSziaz8oBis1x ZpUAoKcVmJxbIY0gHw4L39wxaV1jbW9T =E7Cn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Marius Gedminas mar...@gedmin.as writes: On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote: Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. I am, in fact, adapting tuples for what I consider to be a good reason (pretty-printing arbitrary objects) in zodbbrowser. http://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/annotate/head:/src/zodbbrowser/value.py Similarly, I've often sub-classed built-in types when using the ZCA such that isinstance(obj, tuple) is True. Ross ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] split out zope.component mechanics into a separate package (was Re: improving the utility and adapter lookup APIs)
Chris McDonough wrote: If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module. It would be useful to split these core mechanics into a separate package. Here's why: - The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery. - The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security. - The registry itself is useful outside the context of the zope.component API package; the API is essentially just candy on top of the registry itself. I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency). After that's done, I'd suggest we make zope.component depend on zope.registry. At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app. Thoughts? - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] split out zope.component mechanics into a separate package (was Re: improving the utility and adapter lookup APIs)
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote: Chris McDonough wrote: If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module. It would be useful to split these core mechanics into a separate package. Here's why: - The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery. - The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security. - The registry itself is useful outside the context of the zope.component API package; the API is essentially just candy on top of the registry itself. I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency). After that's done, I'd suggest we make zope.component depend on zope.registry. At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app. Thoughts? FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Hi all Betreff: Re: [Zope-dev] improving the utility and adapter lookup APIs On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. Of corse do adapter adapt something. But why do we excpect that we will get an adapter if we enhance the interface implementation and do some dance with e.g. IFoo(???). Form the interface point of view there should only be a contract that the returned object provides that interface. Adapters and utilities are different, that's no question. But if an interfaces get called without an argument, it could return an object providing this interface. Based on the missing value (not None, just missing) the object doesn't get adapted/called and could return an utility. If we skip this option, then IFoo() will raise a ComponentLookupError or tell us that the signature at least needs one or more argument. The following makes sense to me: getUtility(IFoo) - IFoo() getUtility(IFoo, name='foo') - IFoo(name='foo') getAdapter(obj, IFoo) - IFoo(obj) getMultiAdapter((foo, bar), IFoo) - IFoo(foo, bar) Regards Roger Ineichen Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I quite like the simplicity of this spelling, so I want to be sure *why* it must be ruled out. (...or does it, really?) I'm thinking that this... * Martijn Faassen faas...@startifact.com [2009-11-25 22:21]: The last one won't work if we want to maintain backwards compatibility. The second argument is the default. is a valid argument, while this... * Tres Seaver tsea...@palladion.com [2009-11-25 13:34]: You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. is not, as evidenced by... * Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]: IFoo(x, y, default=None, name='something') or am I missing something here? So I'm thinking, there is no technical reason that prevents Thomas' spelling, and I'm wondering, do we really have to preserve backwards compatibility for this case? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
Am 25.11.2009 um 15:49 schrieb Chris Withers: [...] Yes, PyPI is broken if you're an admin of many packages, feel free to me too on this issue: http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503 It's fixed since yesterday. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
Michael Howitz wrote: Am 25.11.2009 um 15:49 schrieb Chris Withers: [...] Yes, PyPI is broken if you're an admin of many packages, feel free to me too on this issue: http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503 It's fixed since yesterday. Well, by some definition of fixed. That list should just have been moved to its own page, rather than just truncated... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
