Two small convenience suggestions for zope.interface and zope.component
Hi, I'd like to add support for the following: 1) Provider decorator: @provider(IFoo) def some_function(context) pass This is an alternative to doing a separate alsoProvides() on the function. 2) An interfaceProvides directive: class IFoo(Interface): interfaceProvides(ISomeMarker) This is alternative to doing alsoProvides() on the interface. The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the "what is this" information at the top of the entity. I can probably help implement this. Any thoughts? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Apr 1, 2009, at 10:02 AM, Martin Aspeli wrote:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo) def some_function(context) pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface): interfaceProvides(ISomeMarker)
This is alternative to doing alsoProvides() on the interface.
The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the "what is this" information at the top of the entity.
I can probably help implement this. Any thoughts?
+1 -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo) def some_function(context) pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface): interfaceProvides(ISomeMarker)
This is alternative to doing alsoProvides() on the interface.
The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the "what is this" information at the top of the entity.
I can probably help implement this. Any thoughts?
You should probably add a "class decorator" 'interfaceProvider', as well, because the "in-suite" versions are problematic for 2to3 conversion (IIRC what Lennart said yesterday). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ03rd+gerLs4ltQ4RAhmLAJ94wuHpAwJjNu8rylhKZeYn1yV11QCeLh36 zMqCZerP8HNUyFJH4IvNkaY= =pD4Z -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo) def some_function(context) pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface): interfaceProvides(ISomeMarker)
This is alternative to doing alsoProvides() on the interface.
The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the "what is this" information at the top of the entity.
I can probably help implement this. Any thoughts?
You should probably add a "class decorator" 'interfaceProvider', as well, because the "in-suite" versions are problematic for 2to3 conversion (IIRC what Lennart said yesterday).
I'm not sure I understand what you mean by that. Can you show an example? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Wed, Apr 01, 2009 at 10:56:30PM +0800, Martin Aspeli wrote:
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo) def some_function(context) pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface): interfaceProvides(ISomeMarker)
This is alternative to doing alsoProvides() on the interface.
The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the "what is this" information at the top of the entity.
I can probably help implement this. Any thoughts?
You should probably add a "class decorator" 'interfaceProvider', as well, because the "in-suite" versions are problematic for 2to3 conversion (IIRC what Lennart said yesterday).
I'm not sure I understand what you mean by that. Can you show an example?
It's a Python 2.6/3.0 feature: from zope.component import adapter from zope.interface import implementer @adapter(IFoo) @implementer(IBar) class MyClass(object): def __init__(self, context): self.context = context ... which translates to the obvious class MyClass(object): def __init__(self, context): self.context = context ... MyClass = implementer(IBar)(MyClass) MyClass = adapter(IFoo)(MyClass) assuming I got the application order right. I now also wonder if adapter()/implementer() would work when called with classes rather than functions...? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Hi Marius,
It's a Python 2.6/3.0 feature:
Oh... sniff... I so want that. ;)
from zope.component import adapter from zope.interface import implementer
@adapter(IFoo) @implementer(IBar) class MyClass(object):
def __init__(self, context): self.context = context ...
which translates to the obvious
class MyClass(object):
def __init__(self, context): self.context = context ...
MyClass = implementer(IBar)(MyClass) MyClass = adapter(IFoo)(MyClass)
assuming I got the application order right.
Great.
I now also wonder if adapter()/implementer() would work when called with classes rather than functions...?
I would hope so, or it'd be really confusing. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Additionally, if I was grokking Lennart correctly yesterday, __metaclass__ is going away, so the current metaclass implementation is going to need some rejiggering. What was unclear was whether a single implementation could support both <=2.5 and >=2.6. Chris On Wed, Apr 1, 2009 at 1:09 PM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Hi Marius,
It's a Python 2.6/3.0 feature:
Oh... sniff... I so want that. ;)
from zope.component import adapter from zope.interface import implementer
@adapter(IFoo) @implementer(IBar) class MyClass(object):
def __init__(self, context): self.context = context ...
which translates to the obvious
class MyClass(object):
def __init__(self, context): self.context = context ...
MyClass = implementer(IBar)(MyClass) MyClass = adapter(IFoo)(MyClass)
assuming I got the application order right.
Great.
I now also wonder if adapter()/implementer() would work when called with classes rather than functions...?
I would hope so, or it'd be really confusing. :)
Martin
-- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On 1 Apr 2009, at 18:25, Chris Rossi wrote:
Additionally, if I was grokking Lennart correctly yesterday, __metaclass__ is going away, so the current metaclass implementation is going to need some rejiggering. What was unclear was whether a single implementation could support both <=2.5 and >=2.6.
__metaclass__ is being replaced by a metaclass kwarg to class definition in 3.0, I believe. Matt
On Wed, Apr 1, 2009 at 12:25, Chris Rossi <chris@archimedeanco.com> wrote:
Additionally, if I was grokking Lennart correctly yesterday, __metaclass__ is going away, so the current metaclass implementation is going to need some rejiggering. What was unclear was whether a single implementation could support both <=2.5 and >=2.6.
2.5 doesn't support class decorators, so no. But the plan is that both implements(IFoo) and @implementor(IFoo) will be available under 2.6. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
2009/4/1 Marius Gedminas <marius@gedmin.as>:
I now also wonder if adapter()/implementer() would work when called with classes rather than functions...?
Yes, in 2.6 and 3.0. Not with the current trunk of zope.interfaces, though, but in the future, sure. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Martin Aspeli wrote at 2009-4-1 22:02 +0800:
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo) def some_function(context) pass
I have already searched for this several times -- and was disappointed about my failure :-) -- Dieter
participants (8)
-
Chris Rossi -
Dieter Maurer -
Jim Fulton -
Lennart Regebro -
Marius Gedminas -
Martin Aspeli -
Matthew Wilkes -
Tres Seaver