Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-02 Thread Lennart Regebro
On Wed, Apr 1, 2009 at 12: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.

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
___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-02 Thread Lennart Regebro
2009/4/1 Marius Gedminas :
> 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
___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Dieter Maurer
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
___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Matthew Wilkes

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

___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Chris Rossi
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  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-...@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 )
>
___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Martin Aspeli
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Marius Gedminas
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


signature.asc
Description: Digital signature
___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Martin Aspeli
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

___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Tres Seaver
-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  tsea...@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-

___
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 )


Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component

2009-04-01 Thread Jim Fulton

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


___
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 )