Re: [Zope-dev] component registry navelgazing

2011-06-13 Thread Fabio Tranchitella
* 2011-06-12 22:49, Chris McDonough wrote:
 This seems slightly inconsistent with the adaptation worldview imposed by
 getAdapter/queryAdapter.  I think it would be more consistent if
 c.queryAdapter(IFoo, foo) returned foo if foo already implemented IFoo
 and there was no other more specific adapter registered for the IFoo/foo
 pair in the registry, no?

+1, way more consistent than returning None.

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] component registry navelgazing

2011-06-13 Thread Chris Withers
On 12/06/2011 21:48, Chris McDonough wrote:
 Currently if you ask a registry to singly-adapt an object to an
 interface, and the object you're trying to adapt implements that
 interface, here's what happens:

 from zope.component.registry import Components
 c = Components()
 from zope.interface import Interface, implements
 class IFoo(Interface): pass
 ...
 class Foo(object):
 ... implements(IFoo)
 ...
 foo = Foo()
 c.queryAdapter(IFoo, foo)
 None

Looking back in history:

https://mail.zope.org/pipermail/zope-dev/2008-August/032902.html

I guess one or other of us has the parameter order wrong, probably me.

Much thread ensued:
https://mail.zope.org/pipermail/zope-dev/2008-August/thread.html#32902
https://mail.zope.org/pipermail/zope-dev/2008-September/thread.html#33174

Some justification for keeping the status quo from Fred:

https://mail.zope.org/pipermail/zope-dev/2008-September/033172.html

I stand by my resultant request here:

https://mail.zope.org/pipermail/zope-dev/2008-September/033170.html

Maybe less people care about ZCA now and so we might actually get 
sensible changes made.

Maybe forking would be easier...

cheers,

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] component registry navelgazing

2011-06-13 Thread Chris McDonough
On Mon, 2011-06-13 at 10:08 +0100, Chris Withers wrote:
 On 12/06/2011 21:48, Chris McDonough wrote:
  Currently if you ask a registry to singly-adapt an object to an
  interface, and the object you're trying to adapt implements that
  interface, here's what happens:
 
  from zope.component.registry import Components
  c = Components()
  from zope.interface import Interface, implements
  class IFoo(Interface): pass
  ...
  class Foo(object):
  ... implements(IFoo)
  ...
  foo = Foo()
  c.queryAdapter(IFoo, foo)
  None
 
 Looking back in history:
 
 https://mail.zope.org/pipermail/zope-dev/2008-August/032902.html
 
 I guess one or other of us has the parameter order wrong, probably me.
 
 Much thread ensued:
 https://mail.zope.org/pipermail/zope-dev/2008-August/thread.html#32902
 https://mail.zope.org/pipermail/zope-dev/2008-September/thread.html#33174
 
 Some justification for keeping the status quo from Fred:
 
 https://mail.zope.org/pipermail/zope-dev/2008-September/033172.html
 
 I stand by my resultant request here:
 
 https://mail.zope.org/pipermail/zope-dev/2008-September/033170.html
 
 Maybe less people care about ZCA now and so we might actually get 
 sensible changes made.

This argument against makes sense to me:

https://mail.zope.org/pipermail/zope-dev/2008-August/032908.html

So I've added a method to a subclass of
zope.component.registry.Components for my own purposes:

def queryAdapterOrSelf(self, object, interface, default=None):
provides = providedBy(object)
if not interface in provides:
return self.queryAdapter(object, interface, default=default)
return object


- 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] zope-tests - FAILED: 12, OK: 53

2011-06-13 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/13/2011 01:00 AM, Zope tests summarizer wrote:

 [5]FAILED  Zope 3.4 Known Good Set / py2.4-32bit-linux
https://mail.zope.org/pipermail/zope-tests/2011-June/043168.html

This fails (wihtout much other information) trying to download
'ClientForm==0.2.10':

-  % --
Getting distribution for 'ClientForm==0.2.10'.
While:
  Installing test.
  Getting distribution for 'ClientForm==0.2.10'.
Error: Couldn't find a distribution for 'ClientForm==0.2.10'.
-  % --

Which looks like a bogus error to me, given that the egg has been
released to PyPI since 2008-12-03:

  http://pypi.python.org/pypi/ClientForm


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

iEYEARECAAYFAk319xQACgkQ+gerLs4ltQ7gFQCgv3nfxqP0ryEqBCcBoVBEg1iY
yRQAni+MMJX4mmPGGzEOWcCp1fEXktam
=Tmh2
-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] component registry navelgazing

2011-06-13 Thread Charlie Clark
Hiya,

Am 12.06.2011, 22:48 Uhr, schrieb Chris McDonough chr...@plope.com:

 from zope.component.registry import Components
 c = Components()
 from zope.interface import Interface, implements
 class IFoo(Interface): pass
 ...
 class Foo(object):
 ... implements(IFoo)
 ...
 foo = Foo()
 c.queryAdapter(IFoo, foo)
 None

 In order to get the object itself back from such an adaptation, you need
 to use the default= argument.

I know that the question has been answered but your question makes me ask  
another: why would you want to adapt an object with itself?

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] component registry navelgazing

2011-06-13 Thread Georges Racinet
Stepping in… and +1 for the original question

On 06/13/2011 04:26 PM, Charlie Clark wrote:
 I know that the question has been answered but your question makes me ask  
 another: why would you want to adapt an object with itself?

The sake of logical consistency should be enough. If you think of it,
it's very similar to addition of zero : why would you want to add
nothing ?

Not having to predict where/if/when such special cases may blow in your
face is very useful, and has indeed been very productive in the past.

-- 
Georges Racinet, http://www.racinet.fr, http://anybox.fr
Zope/CPS  OpenERP expertise, assistance  development
GPG: 0x4862FFF7 identi.ca  twitter: gracinet



signature.asc
Description: OpenPGP 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] component registry navelgazing

2011-06-13 Thread Chris Withers
On 13/06/2011 15:26, Charlie Clark wrote:
 In order to get the object itself back from such an adaptation, you need
 to use the default= argument.

 I know that the question has been answered but your question makes me ask
 another: why would you want to adapt an object with itself?

I have something, I want something that implements IWhatever.

Now, it may well be that something implements IWhatever, but it may also 
not. As the author of the code in question, I don't want to have to care.

Other authors can plug in adapters for the cases where something doesn't 
implement IWhatever ;-)

cheers,

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] component registry navelgazing

2011-06-13 Thread Charlie Clark
Am 13.06.2011, 17:01 Uhr, schrieb Chris Withers ch...@simplistix.co.uk:

 I have something, I want something that implements IWhatever.
  Now, it may well be that something implements IWhatever, but it may  
 also not. As the author of the code in question, I don't want to have to  
 care.
  Other authors can plug in adapters for the cases where something  
 doesn't implement IWhatever

I can appreciate the use case but not the semantics - you are not looking  
for an adapter but an implementation. I guess this is related to the  
IWhatever(object) approach which does the magic for you. I guess  
queryProvider(object, interface) would be a better spelling for that use  
case, which may be more general than I'm suggesting.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] component registry navelgazing

2011-06-13 Thread Jim Fulton
On Sun, Jun 12, 2011 at 4:48 PM, Chris McDonough chr...@plope.com wrote:
 Currently if you ask a registry to singly-adapt an object to an
 interface, and the object you're trying to adapt implements that
 interface, here's what happens:

 from zope.component.registry import Components
 c = Components()
 from zope.interface import Interface, implements
 class IFoo(Interface): pass
 ...
 class Foo(object):
 ...     implements(IFoo)
 ...
 foo = Foo()
 c.queryAdapter(IFoo, foo)
 None

 In order to get the object itself back from such an adaptation, you need
 to use the default= argument.

 c.queryAdapter(IFoo, foo, default=foo)
 __main__.Foo object at 0x24a3910

 This seems slightly inconsistent with the adaptation worldview imposed
 by getAdapter/queryAdapter.  I think it would be more consistent if
 c.queryAdapter(IFoo, foo) returned foo if foo already implemented IFoo
 and there was no other more specific adapter registered for the IFoo/foo
 pair in the registry, no?

I don't know what getAdapter/queryAdapter you're referring to in
This seems slightly inconsistent with the adaptation worldview imposed
by getAdapter/queryAdapter.

Do you mean  This seems slightly inconsistent with the adaptation
worldview imposed
by interface __call__. ?

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
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] component registry navelgazing

2011-06-13 Thread Jim Fulton
On Mon, Jun 13, 2011 at 12:38 PM, Jim Fulton j...@zope.com wrote:
 On Sun, Jun 12, 2011 at 4:48 PM, Chris McDonough chr...@plope.com wrote:
 Currently if you ask a registry to singly-adapt an object to an
 interface, and the object you're trying to adapt implements that
 interface, here's what happens:

 from zope.component.registry import Components
 c = Components()
 from zope.interface import Interface, implements
 class IFoo(Interface): pass
 ...
 class Foo(object):
 ...     implements(IFoo)
 ...
 foo = Foo()
 c.queryAdapter(IFoo, foo)
 None

 In order to get the object itself back from such an adaptation, you need
 to use the default= argument.

 c.queryAdapter(IFoo, foo, default=foo)
 __main__.Foo object at 0x24a3910

 This seems slightly inconsistent with the adaptation worldview imposed
 by getAdapter/queryAdapter.  I think it would be more consistent if
 c.queryAdapter(IFoo, foo) returned foo if foo already implemented IFoo
 and there was no other more specific adapter registered for the IFoo/foo
 pair in the registry, no?

 I don't know what getAdapter/queryAdapter you're referring to in
 This seems slightly inconsistent with the adaptation worldview imposed
 by getAdapter/queryAdapter.

 Do you mean  This seems slightly inconsistent with the adaptation
 worldview imposed
 by interface __call__. ?

By the later messages, I can see that that is what you meant to say.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
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] zope-tests - FAILED: 8, OK: 52

2011-06-13 Thread Zope tests summarizer
This is the summary for test reports received on the 
zope-tests list between 2011-06-12 00:00:00 UTC and 2011-06-13 00:00:00 UTC:

See the footnotes for test reports of unsuccessful builds.

An up-to date view of the builders is also available in our 
buildbot documentation: 
http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds

Reports received


   Bluebream / Python2.4.6 64bit linux
   Bluebream / Python2.5.5 64bit linux
   Bluebream / Python2.6.5 64bit linux
   ZTK 1.0 / Python2.4.6 Linux 64bit
   ZTK 1.0 / Python2.5.5 Linux 64bit
   ZTK 1.0 / Python2.6.5 Linux 64bit
   ZTK 1.0dev / Python2.4.6 Linux 64bit
   ZTK 1.0dev / Python2.5.5 Linux 64bit
   ZTK 1.0dev / Python2.6.5 Linux 64bit
   Zope 3.4 KGS / Python2.4.6 64bit linux
   Zope 3.4 KGS / Python2.5.5 64bit linux
   Zope 3.4 Known Good Set / py2.4-32bit-linux
   Zope 3.4 Known Good Set / py2.4-64bit-linux
   Zope 3.4 Known Good Set / py2.5-32bit-linux
   Zope 3.4 Known Good Set / py2.5-64bit-linux
   Zope Buildbot / zope2.12-py2.6 slave-osx
   Zope Buildbot / zope2.13-py2.6 slave-osx
   Zope Buildbot / zope2.13-py2.7 slave-osx
   Zope Buildbot / zope2.14-py2.6 slave-osx
   Zope Buildbot / zope2.14-py2.7 slave-osx
   Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx
   Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx
   Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx
   Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx
   Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx
   Zope Buildbot / zopetoolkit-py2.5 slave-osx
   Zope Buildbot / zopetoolkit-py2.6 slave-osx
   Zope-2.10 Python-2.4.6 : Linux
   Zope-2.11 Python-2.4.6 : Linux
   Zope-2.12 Python-2.6.6 : Linux
   Zope-2.12-alltests Python-2.6.6 : Linux
   Zope-2.13 Python-2.6.6 : Linux
   Zope-2.13-alltests Python-2.6.6 : Linux
   Zope-trunk Python-2.6.6 : Linux
   Zope-trunk-alltests Python-2.6.6 : Linux
   winbot / ZODB_dev py_254_win32
   winbot / ZODB_dev py_265_win32
   winbot / ZODB_dev py_265_win64
   winbot / ZODB_dev py_270_win32
   winbot / ZODB_dev py_270_win64
[1]winbot / z3c.coverage_py_265_32
[2]winbot / z3c.rml_py_265_32
[3]winbot / zc_buildout_dev py_254_win32
[4]winbot / zc_buildout_dev py_265_win32
[5]winbot / zc_buildout_dev py_265_win64
[6]winbot / zc_buildout_dev py_270_win32
[7]winbot / zc_buildout_dev py_270_win64
   winbot / ztk_10 py_254_win32
   winbot / ztk_10 py_265_win32
[8]winbot / ztk_10 py_265_win64
   winbot / ztk_11 py_254_win32
   winbot / ztk_11 py_265_win32
   winbot / ztk_11 py_265_win64
   winbot / ztk_11 py_270_win32
   winbot / ztk_11 py_270_win64
   winbot / ztk_dev py_254_win32
   winbot / ztk_dev py_265_win32
   winbot / ztk_dev py_265_win64
   winbot / ztk_dev py_270_win32
   winbot / ztk_dev py_270_win64

Non-OK results
--

[1]FAILED  winbot / z3c.coverage_py_265_32
   https://mail.zope.org/pipermail/zope-tests/2011-June/043240.html


[2]FAILED  winbot / z3c.rml_py_265_32
   https://mail.zope.org/pipermail/zope-tests/2011-June/043239.html


[3]FAILED  winbot / zc_buildout_dev py_254_win32
   https://mail.zope.org/pipermail/zope-tests/2011-June/043276.html


[4]FAILED  winbot / zc_buildout_dev py_265_win32
   https://mail.zope.org/pipermail/zope-tests/2011-June/043277.html


[5]FAILED  winbot / zc_buildout_dev py_265_win64
   https://mail.zope.org/pipermail/zope-tests/2011-June/043278.html


[6]FAILED  winbot / zc_buildout_dev py_270_win32
   https://mail.zope.org/pipermail/zope-tests/2011-June/043279.html


[7]FAILED  winbot / zc_buildout_dev py_270_win64
   https://mail.zope.org/pipermail/zope-tests/2011-June/043280.html


[8]FAILED  winbot / ztk_10 py_265_win64
   https://mail.zope.org/pipermail/zope-tests/2011-June/043270.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 )