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@...
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 )

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@...
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 )

-----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          tseaver@...
Palladion Software   "Excellence by Design"    http://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@...
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 )

On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver <tseaver@...> 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@...
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 )

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@...
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 )

Marius Gedminas <marius@...> 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:/sr\
c/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@...
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 )

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@...
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 )

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@...
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 )

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@...
> 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@...
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 )

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@...
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 )

* 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 <faassen@...> [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 <tseaver@...> [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 <kobold@...> [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@...
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 )

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=detail&aid=2793544&group_id=66150&atid=5135\
03

It's fixed since yesterday.

Yours sincerely,
--
Michael Howitz · mh@... · 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@...
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 )

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=detail&aid=2793544&group_id=66150&atid=5135\
03
>
> 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@...
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 )

Hey,

Jan-Wijbrand Kolman wrote:
> 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?

I'm still not sure there'd be a real benefit. It depends on how much
code would end up being shared. If a lot of code is shared it might make
sense to merge them (or factor the code out into a general schema-based
serialization and deserialization framework). If it turns out your
improvements to z3c.schema2json also make sense in z3c.schema2xml then
that's an argument in favor of sharing code between them.

Regards,

Martijn




_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Thomas Lotze wrote:
> 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?

True. It's indeed a goal, as I'd like to be able to use this sooner
rather than later. If we break backwards compatibility then we'd have to
go through all the IFoo() calls everywhere in all our code to see
whether a default argument is in use.

> 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.

Sure. But if we want to retain backwards compatibility we'll have to go
another way.

Regards,

Martijn



_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Wolfgang Schnerring 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 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 <faassen@...> [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 <tseaver@...> [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 <kobold@...> [2009-11-25 20:51]:
>>     IFoo(x, y, default=None, name='something')
>
> or am I missing something here?

I think the problem would exist if we did something like this:

def IFoo(default, name, *args):
     pass

but if we did something like this we should be okay, I think:

def IFoo(*args, **kw):
     name = kw.get('name', missing)
     default = kw.get('default', missing)
     adapted = args

> 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?

I'm not very fond of the second argument interpreted as default. If it
weren't there I'd be quite interested in the API you're proposing.

But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan code.

We could perhaps release a special version of
zope.interface/zope.component that *forbids* the second argument to see
what bugs pop up, but that'd still not guarantuee we catch all cases.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On 2009-11-26 08:43, 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=detail&aid=2793544&group_id=66150&atid=5135\
03
>
> It's fixed since yesterday.

That's not a fix, it just replaced one problem with another one: it is
now impossible to get your full list of packages.

Wichert.

--
Wichert Akkerman <wichert@...>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Martijn Faassen wrote:

> Thomas Lotze wrote:
>> 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?
>
> True. It's indeed a goal, as I'd like to be able to use this sooner
> rather than later. If we break backwards compatibility then we'd have to
> go through all the IFoo() calls everywhere in all our code to see
> whether a default argument is in use.

Understood.

>> 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.
>
> Sure. But if we want to retain backwards compatibility we'll have to go
> another way.

Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it allows
us to implement a simple and consistent API anyway.

My favourite option under these circumstances would be something like

IFoo.query(*args, default=None, ...)

though possibly with a method name in a different color of bike shed,
where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may
be written as IFoo.query(x, y).

--
Thomas



_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Martijn Faassen wrote:
> But someone needs to think of a feasible upgrade scenario. We could
> instrument all calls to IFoo and see whether a default argument is in
> use, but what then? I'd be hard to distinguish a default argument from
> one we're meant to adapt. I'd also be non-trivial to scan code.

Here is an interface decorator I intend to try out soon.  It adds
convenient component lookup methods to a particular interface without
requiring any changes to zope.interface.

--- (snip) ---

from zope.interface.interfaces import IInterface
from zope.component import getAdapter
from zope.component import getMultiAdapter
from zope.component import getUtility
from zope.component import queryAdapter
from zope.component import queryMultiAdapter
from zope.component import queryUtility

def componentlookup(iface):
      """Decorator: adds zope.component lookup methods to an interface.

      Adds utility([default], [name]) and adapt(*args, [default], [name]).
      """
      assert IInterface.providedBy(iface)

      def utility(**kw):
          if 'default' in kw:
              return queryUtility(iface, **kw)
          else:
              return getUtility(iface, **kw)
      iface.utility = utility

      def adapt(*args, **kw):
          if len(args) == 1:
              # simple adapter lookup
              arg = args[0]
              if not 'name' in kw and iface.providedBy(arg):
                  # The object passed in already provides this interface,
                  # and no adapter name was provided, so return the object
                  # unchanged.
                  return arg
              if 'default' in kw:
                  return queryAdapter(arg, iface, **kw)
              else:
                  return getAdapter(arg, iface, **kw)

          # multi-adapter lookup
          if 'default' in kw:
              return queryMultiAdapter(args, iface, **kw)
          else:
              return getMultiAdapter(args, iface, **kw)
      iface.adapt = adapt

      return iface


--- (snip) ---

Example usage:

      @componentlookup
      class IFoo(Interface):
          pass

      class Foo(object):
          implements(IFoo)

      IFoo.adapt(Foo())
      IFoo.adapt(Foo(), HTTPRequest(), name='edit')
      IFoo.adapt(Foo(), name='x')
      IFoo.adapt(Foo(), default=None)
      IFoo.utility(default=None)

I think class decorators were added in Python 2.6, but in earlier
Pythons you can do this instead:

      class IFoo(Interface):
          pass
      componentlookup(IFoo)

Shane
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Am Mittwoch 25 November 2009 13:07:58 schrieb Benji York:
> On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer <dusty@...> 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.

Thanks a lot for help, that would really great. The question is, how do I find
out (with my limited knowledge of zope.security) if the bug exists in 3.4.1?

I saw in your link you sent me that a core-dump can be made somehow, how can
this be done? Because via that core-dump I expect we can pinpoint the reason
and confirm the bug for zope.security-3.4.1?

Best Regards,
Hermann

--
hermann@...
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Summary of messages to the zope-tests list.
Period Wed Nov 25 12:00:00 2009 UTC to Thu Nov 26 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: Wed Nov 25 20:38:30 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013083.html

Subject: OK : Zope-2.11 Python-2.4.6 : Linux
From: Zope Tests
Date: Wed Nov 25 20:40:31 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013084.html

Subject: OK : Zope-2.12 Python-2.6.4 : Linux
From: Zope Tests
Date: Wed Nov 25 20:42:31 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013085.html

Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux
From: Zope Tests
Date: Wed Nov 25 20:44:31 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013086.html

Subject: OK : Zope-trunk Python-2.6.4 : Linux
From: Zope Tests
Date: Wed Nov 25 20:46:31 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013087.html

Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux
From: Zope Tests
Date: Wed Nov 25 20:48:31 EST 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013088.html

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
<matthew@...> 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?

There could be an optional keyword argument to be explicit.

This would be a single-adapter lookup:

IFoo(from=my_tuple)

While this would be a multi-adapter lookup:

IFoo(my_tuple)
--
Benji York
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman <wichert@...> wrote:
> That's not a fix, it just replaced one problem with another one: it is
> now impossible to get your full list of packages.

Indeed.

Once SourceForge is allowing logins again I suggest we discuss this
there.

I'll be suggesting that the recent "fix" be reverted and they instead
use the CSS I posted earlier.
--
Benji York
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On Thu, Nov 26, 2009 at 14:34, Benji York <benji@...> wrote:
> On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
> <matthew@...> 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?
>
> There could be an optional keyword argument to be explicit.
>
> This would be a single-adapter lookup:
>
> IFoo(from=my_tuple)

You probably already realized it by now, but this is a syntax error
(remember: "from module import name").

>
> While this would be a multi-adapter lookup:
>
> IFoo(my_tuple)

To take my stab at this bikeshed painting, and since it doesn't seem
likely we'd want to break backward compatibility, I think I'd prefer
the other way around:

IFoo(multi=my_tuple)

and leave the first parameter for single adaptation, although what I'd
really prefer is multi-adaptation on multiple positional parameter.

Cheers, Leo
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On Thu, Nov 26, 2009 at 6:52 AM, Hermann Himmelbauer <dusty@...> wrote:
>> If this bug did indeed exist in 3.4.1, we can backport the fix and do a
>> 3.4.x bug-fix release.
>
> Thanks a lot for help, that would really great. The question is, how do I find
> out (with my limited knowledge of zope.security) if the bug exists in 3.4.1?

>From looking at the code, it seems the bug does exist in 3.4.1 (and
3.4.2).  I merged the fix to the 3.4 branch and released 3.4.3.

> I saw in your link you sent me that a core-dump can be made somehow, how can
> this be done? Because via that core-dump I expect we can pinpoint the reason
> and confirm the bug for zope.security-3.4.1?

As a first step, I suggest putting 3.4.3 in production and seeing if the
segfaults stop.
--
Benji York
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

2009/11/26 Martijn Faassen <faassen@...>:
> Hey,
>
> Jan-Wijbrand Kolman wrote:
>> 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?
>
> I'm still not sure there'd be a real benefit. It depends on how much
> code would end up being shared. If a lot of code is shared it might make
> sense to merge them (or factor the code out into a general schema-based
> serialization and deserialization framework). If it turns out your
> improvements to z3c.schema2json also make sense in z3c.schema2xml then
> that's an argument in favor of sharing code between them.

I can't see much core code being shared to be honest. However, the
benefits of merging would be more apparent to clients of these modules
who want to be able to use z3c.schema2json and z3c.schema2xml together
to support both serialization formats.

I can see two use cases from the perspective of client code:

  * I want to have my objects serialized and deserialized but don't
want to know what format is used, just use an agnostic interface
(z3c.autoinclude wires the correct implementation from the list of
dependencies).
  * I want to present a list of possible serialization formats and have
the user select the appropriate one.

Thanks,
Paul
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida
<leorochael@...> wrote:
> On Thu, Nov 26, 2009 at 14:34, Benji York <benji@...> wrote:
>> On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
>>> I know it's probably a spurious use case, but what if I want to adapt a
>>> tuple?
>>
>> There could be an optional keyword argument to be explicit.
>>
>> This would be a single-adapter lookup:
>>
>> IFoo(from=my_tuple)
>
> You probably already realized it by now, but this is a syntax error
> (remember: "from module import name").

Nope, it hadn't occurred to me.  Some other argument name could be used
instead.

>> While this would be a multi-adapter lookup:
>>
>> IFoo(my_tuple)
>
> To take my stab at this bikeshed painting, and since it doesn't seem
> likely we'd want to break backward compatibility, I think I'd prefer
> the other way around:
>
> IFoo(multi=my_tuple)
>
> and leave the first parameter for single adaptation, although what I'd
> really prefer is multi-adaptation on multiple positional parameter.

I'd rather have the common case (of adapting a non-tuple) be the simpler
form and the exception (adapting a tuple) require more verbiage.
--
Benji York
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Shane Hathaway wrote:
[I talk about backwards compatibility issues with some proposed API changes,
but this modification doesn't have this issue]

> Here is an interface decorator I intend to try out soon.  It adds
> convenient component lookup methods to a particular interface without
> requiring any changes to zope.interface.

Cool!

It'd be cool if this could be released as a package. I would still
propose folding this into zope.component (somehow) and making interfaces
do this by default. This is because the decorator as far as I understand
requires one to be in control of the interface.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Thomas Lotze wrote:
[snip]
> Then let me suggest not changing the call signature of an interface at all
> but only add one or a few new methods. Firstly, this will keep backwards
> compatibility even with code that adapts a tuple, and secondly, it allows
> us to implement a simple and consistent API anyway.

That was my original proposal, right? (I only propose adding a 'name'
argument to the IFoo() lookup if it isn't there already, otherwise it's
all new methods).

> My favourite option under these circumstances would be something like
>
> IFoo.query(*args, default=None, ...)
>
> though possibly with a method name in a different color of bike shed,
> where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may
> be written as IFoo.query(x, y).

It could indeed be done as a single method. See Shane's post for a
possible implementation.

Regards,

Martijn



_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )

Martijn Faassen wrote:

> Thomas Lotze wrote:
> [snip]
>> Then let me suggest not changing the call signature of an interface at all
>> but only add one or a few new methods. Firstly, this will keep backwards
>> compatibility even with code that adapts a tuple, and secondly, it
>> allows us to implement a simple and consistent API anyway.
>
> That was my original proposal, right? (I only propose adding a 'name'
> argument to the IFoo() lookup if it isn't there already, otherwise it's
> all new methods).

I specifically wanted to suggest not adding that name argument but leaving
the existing call untouched. I think once we add a new method, we
shouldn't at the same time improve the existing one as that would IMO
suggest rather forcefully that there's more than one way to do the same
thing; just leaving it in there for compatibility is bad enough from the
point of view of a clean API.

--
Thomas



_______________________________________________
Zope-Dev maillist  -  Zope-Dev@...
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 )