On Fri, May 31, 2013 at 3:13 PM, Chris McDonough chr...@plope.com wrote:
On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
On 31 maj 2013, at 01:51, Łukasz Langa luk...@langa.pl wrote:
Back to the point, though. I don't feel we should complicate the
code, tests and documentation by
On 29 maj 2013, at 04:40, Nick Coghlan ncogh...@gmail.com wrote:
I expect we will see improved tools for integrating class based
dispatch and generic function dispatch in the future, but we should
*not* try to engineer a solution up front. Doing so would involve too
much guessing about
On 31 maj 2013, at 01:47, Łukasz Langa luk...@langa.pl wrote:
class State:
def __init__(self):
self.add.register(int, self.add_int)
Ouch, I realized this is wrong just after I hit Send. self.add is a
staticmethod so this registration will overload on every instance. Which is
On 31 maj 2013, at 01:51, Łukasz Langa luk...@langa.pl wrote:
On 31 maj 2013, at 01:47, Łukasz Langa luk...@langa.pl wrote:
class State:
def __init__(self):
self.add.register(int, self.add_int)
Ouch, I realized this is wrong just after I hit Send.
self.add is a staticmethod so
On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
On 31 maj 2013, at 01:51, Łukasz Langa luk...@langa.pl wrote:
Back to the point, though. I don't feel we should complicate the
code, tests and documentation by introducing special handling
for methods. In terms of pure type-driven
On Wed, 29 May 2013 12:40:32 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen ro...@uw.edu wrote:
In article c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl,
Łukasz Langa luk...@langa.pl wrote:
Hello,
Since the initial version, several minor
On Wed, 29 May 2013 08:08:14 +0200
Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 May 2013 12:40:32 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen ro...@uw.edu wrote:
In article c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl,
Łukasz
In article c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl,
Åukasz Langa luk...@langa.pl wrote:
Hello,
Since the initial version, several minor changes have been made to the
PEP. The history is visible on hg.python.org. The most important
change in this version is that I introduced ABC
A question about the example:
how hard would it be to modify the example
@fun.register(list)
...
to work with other collections? If it is easy, I think it would make a
for a much more useful example.
-- Russell
___
Python-Dev mailing list
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen ro...@uw.edu wrote:
Is it true that this cannot be used for instance and class methods? It
dispatches based on the first argument, which is self for instance
methods, whereas the second argument would almost certainly be the
argument one would
On 29/05/13 07:27, PJ Eby wrote:
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen ro...@uw.edu wrote:
Is it true that this cannot be used for instance and class methods? It
dispatches based on the first argument, which is self for instance
methods, whereas the second argument would almost
On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen ro...@uw.edu wrote:
In article c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl,
Łukasz Langa luk...@langa.pl wrote:
Hello,
Since the initial version, several minor changes have been made to the
PEP. The history is visible on hg.python.org. The
On 26 maj 2013, at 01:07, PJ Eby p...@telecommunity.com wrote:
The PEP uses the term implementation, and I think that
actually makes a lot of sense: a generic function is composed of
functions that implement the same operation for different types.
All suggested changes applied. There are
On 26 maj 2013, at 03:37, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, May 26, 2013 at 9:07 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa luk...@langa.pl wrote:
So, the latest document is live:
http://www.python.org/dev/peps/pep-0443/
The code is
On 27 maj 2013, at 15:31, Łukasz Langa luk...@langa.pl wrote:
This is exactly what I did now. I also exposed ._clear_cache() and the
uncached ._find_impl() if somebody finds it necessary to use it. Both
are left undocumented.
For the record, I moved _find_impl out of the closure for easier
Hello,
Since the initial version, several minor changes have been made to the
PEP. The history is visible on hg.python.org. The most important
change in this version is that I introduced ABC support and completed
a reference implementation.
No open issues remain from my point of view.
PEP: 443
On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa luk...@langa.pl wrote:
The most important
change in this version is that I introduced ABC support and completed
a reference implementation.
Excellent! A couple of thoughts on the implementation...
While the dispatch() method allows you to look up
On 25 maj 2013, at 16:08, PJ Eby p...@telecommunity.com wrote:
ISTM there should be some way to get at the raw
registration info, perhaps by exposing a dictproxy for the registry.
Is that really useful? Just today Antoine asked about changing
behaviour of __subclasses__(), suspecting it isn't
On Sun, May 26, 2013 at 12:08 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa luk...@langa.pl wrote:
The most important
change in this version is that I introduced ABC support and completed
a reference implementation.
Excellent! A couple of thoughts on
On 25 maj 2013, at 16:59, Nick Coghlan ncogh...@gmail.com wrote:
I think I added an issue on the tracker for that somewhere... yup:
http://bugs.python.org/issue16832
Given the global nature of the cache invalidation, it may be better as
a module level abc.get_cache_token() function.
I
On Sun, May 26, 2013 at 12:53 AM, Łukasz Langa luk...@langa.pl wrote:
On 25 maj 2013, at 16:08, PJ Eby p...@telecommunity.com wrote:
ISTM there should be some way to get at the raw
registration info, perhaps by exposing a dictproxy for the registry.
Is that really useful? Just today Antoine
On Sun, May 26, 2013 at 1:09 AM, Łukasz Langa luk...@langa.pl wrote:
On 25 maj 2013, at 16:59, Nick Coghlan ncogh...@gmail.com wrote:
I think I added an issue on the tracker for that somewhere... yup:
http://bugs.python.org/issue16832
Given the global nature of the cache invalidation, it may
On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan ncogh...@gmail.com wrote:
Given the global nature of the cache invalidation, it may be better as
a module level abc.get_cache_token() function.
Well, since the only reason to ever use it is to improve performance,
it'd be better to expose it as an
On Sun, May 26, 2013 at 2:48 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan ncogh...@gmail.com wrote:
Given the global nature of the cache invalidation, it may be better as
a module level abc.get_cache_token() function.
Well, since the only reason to
On 25 maj 2013, at 17:13, Nick Coghlan ncogh...@gmail.com wrote:
So I think I'd prefer flipping this around - you can't provide a
custom registry mapping, but you *can* get access to a read only view
of it through a registry attribute on the generic function.
You guys convinced me. Both the
On Sat, 25 May 2013 22:16:04 +0200
Łukasz Langa luk...@langa.pl wrote:
On 25 maj 2013, at 17:13, Nick Coghlan ncogh...@gmail.com wrote:
So I think I'd prefer flipping this around - you can't provide a
custom registry mapping, but you *can* get access to a read only view
of it through a
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa luk...@langa.pl wrote:
So, the latest document is live:
http://www.python.org/dev/peps/pep-0443/
The code is here:
http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
The documentation here:
On Sun, May 26, 2013 at 9:07 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa luk...@langa.pl wrote:
So, the latest document is live:
http://www.python.org/dev/peps/pep-0443/
The code is here:
On 26/05/13 09:07, PJ Eby wrote:
Transforms a function into a single-dispatch generic function. A **generic
function** is composed of multiple functions implementing the same
operation for different types. Which
implementation should be used during a call is determined by the
dispatch
On Thu, May 23, 2013 at 11:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
We should be able to use it to help deal with the every growing
importer API problem, too. I know that's technically what pkgutil
already uses it for, but elevating this from pkgutil implementation
detail to official
On 23 May 2013 22:02, Ronan Lamy ronan.l...@gmail.com wrote:
2013/5/23 Łukasz Langa luk...@langa.pl
Last one wins. Just like with assigning names in a scope, defining methods
in a class or overriding them in a subclass.
This is a serious annoyance, considering that there are several places
On Thu, May 23, 2013 at 6:40 PM, Steven D'Aprano st...@pearwood.info wrote:
I don't think that they will. Being able to register multiple types with a
single call reads very naturally to me, while multiple decorators still
looks weird. Even after many years of seeing them, I still get a
On 24/05/13 15:09, Nick Coghlan wrote:
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano st...@pearwood.info wrote:
I don't think that they will. Being able to register multiple types with a
single call reads very naturally to me, while multiple decorators still
looks weird. Even after many
On Fri, May 24, 2013 at 8:53 PM, Steven D'Aprano st...@pearwood.info wrote:
Python built-ins and the standard library already have a standard idiom for
specifying multiple values at once. A tuple of types is the One Obvious Way
to do this:
@fun.register((float, Decimal))
It's not obvious,
On Fri, May 24, 2013 at 9:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
Furthermore, the proposed registration syntax in the PEP is identical
to the syntax which already exists for ABC registration as a class
decorator (http://docs.python.org/3/library/abc#abc.ABCMeta.register).
Sorry, I
On Fri, May 24, 2013 at 7:54 PM, Sam Partington
sam.parting...@gmail.com wrote:
But isn't it much much worse than names in scope, as with assigning
names in a scope it is only your scope that is affected :
from os.path import join
def join(wibble):
'overloads join in this module only'
2013/5/24 Ethan Furman et...@stoneleaf.us
On 05/23/2013 02:02 PM, Ronan Lamy wrote:
2013/5/23 Łukasz Langa luk...@langa.pl mailto:luk...@langa.pl
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org mailto:
mer...@netwok.org wrote:
Question: what happens if two functions (say
On 24 maj 2013, at 14:22, Ronan Lamy ronan.l...@gmail.com wrote:
2013/5/24 Ethan Furman et...@stoneleaf.us
What would you suggest happen in this case?
Raise a ValueError, maybe? In that case, there needs to be a way to force the
overriding when it is explicitly desired. One way would be to
On Fri, May 24, 2013 at 10:22 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Raise a ValueError, maybe? In that case, there needs to be a way to force
the overriding when it is explicitly desired. One way would be to allow
unregistering implementations: overriding is then done by unregistering the
On 24 maj 2013, at 14:53, Ronan Lamy ronan.l...@gmail.com wrote:
2013/5/24 Łukasz Langa luk...@langa.pl
I recognize the need for such behaviour to be discoverable. This is
important for debugging purposes. This is why I'm going to let users
inspect registered overloads, as well as provide
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman v+pyt...@g.nevcal.com
wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.)
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a complicated
single-dispatch dance rather than supporting native dual-dispatch.
Not
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierre jeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa luk...@langa.pl wrote:
Alternative approaches
==
You could also mention pairtype, used in PyPy:
https://bitbucket.org/pypy/pypy/raw/default/rpython/tool/pairtype.py
(very short code). It's originally about adding
On 23 May 2013 16:37, Devin Jeanpierre jeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a complicated
On 5/23/2013 12:14 AM, Antoine Pitrou wrote:
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierrejeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrousolip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlanncogh...@gmail.com wrote:
The binary
Le Thu, 23 May 2013 00:31:38 -0700,
Glenn Linderman v+pyt...@g.nevcal.com a écrit :
I suspect the point was not that add can be described as doing single
dispatch (it can't), but rather that add could possibly be
implemented in terms of lower-level functions doing single dispatch.
If that
On 23 maj 2013, at 01:16, Terry Jan Reedy tjre...@udel.edu wrote:
I like the general idea. Does you have any specific stdlib use cases in mind?
I thought of pprint, which at some point dispatches on dict versus
set/sequence, but overall it seems more complicated than mere arg type
On 23 maj 2013, at 09:33, Armin Rigo ar...@tunes.org wrote:
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa luk...@langa.pl wrote:
Alternative approaches
==
You could also mention pairtype, used in PyPy:
Thanks for pointing that out. Information on it added
in
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
The dispatch type is currently specified as a decorator argument. The
implementation could allow a form using argument
On 23 May 2013 15:58, Łukasz Langa luk...@langa.pl wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
The dispatch type is currently specified as a decorator
Ok, happy bikeshedding. I'm outta here until that's settled. :-)
On Thu, May 23, 2013 at 7:58 AM, Łukasz Langa luk...@langa.pl wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one.
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
The dispatch type is currently specified as a decorator argument. The
On 23.05.13 00:33, Łukasz Langa wrote:
Hello,
I would like to submit the following PEP for discussion and evaluation.
PEP: 443
Title: Single-dispatch generic functions
[...]
@fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print(Strength in
On 23 May 2013 17:00, Walter Dörwald wal...@livinglogic.de wrote:
Should it be possible to register multiple types for the generic function
with one register() call, i.e. should:
@fun.register(int, float)
def _(arg, verbose=False):
...
be allowed as a synonym for
Hi,
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
@fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print(Strength in numbers, eh?, end= )
...
User API
To define a generic function, decorate it with the ``@singledispatch``
decorator. Note that the dispatch happens on the type of the first
argument, create your function accordingly:
.. code-block:: pycon
from functools import singledispatch
@singledispatch
... def
On Thu, May 23, 2013 at 11:11 AM, Paul Moore p.f.mo...@gmail.com wrote:
Is the debate between 1 and 2, or 1 and 3? Is it even possible to implement
3 without having 2 different names for register?
Yes. You could do it as either:
@func.register
def doit(foo: int):
...
by
On 05/23/2013 11:13 AM, Éric Araujo wrote:
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
@fun.register(int)
... def _(arg, verbose=False):
... if verbose:
...
On Thu, May 23, 2013 at 2:59 PM, PJ Eby p...@telecommunity.com wrote:
I generally lean towards returning the undecorated function, so that if you
say:
@func.register
def do_int(foo: int):
...
Oops, forgot to mention: one other advantage to returning the
undecorated
On 23 maj 2013, at 20:59, PJ Eby p...@telecommunity.com wrote:
As to the ability to do multiple types registration, you could support
it only in type annotations, e.g.:
@func.register
def doit(foo: [int, float]):
...
Initially I thought so, too. But it seems other people
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org wrote:
Does this work if the implementation function is called like the first
decorated function?
No, the ``register()`` attribute returns the undecorated function which
enables decorator stacking, as well as creating unit tests for each
On 05/23/2013 01:10 PM, Łukasz Langa wrote:
On 23 maj 2013, at 20:59, PJ Eby p...@telecommunity.com wrote:
As to the ability to do multiple types registration, you could support
it only in type annotations, e.g.:
@func.register
def doit(foo: [int, float]):
...
Initially I
2013/5/23 Łukasz Langa luk...@langa.pl
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org wrote:
Question: what happens if two functions (say in two different modules)
are registered for the same type?
Last one wins. Just like with assigning names in a scope, defining methods
in a
Le 23/05/2013 16:10, Łukasz Langa a écrit :
Does this work if the implementation function is called like the first
decorated function?
No, the ``register()`` attribute returns the undecorated function which
enables decorator stacking, as well as creating unit tests for each
variant
On 24/05/13 01:04, Ethan Furman wrote:
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
I feel that the PEP should explicitly allow or disallow for the
implementation to accept dispatch on annotations, e.g.:
@func.register
def _(arg: int):
...
versus
@func.register(int)
def _(arg):
...
On 24/05/13 02:56, Paul Moore wrote:
On 23 May 2013 17:00, Walter Dörwald wal...@livinglogic.de wrote:
Should it be possible to register multiple types for the generic function
with one register() call, i.e. should:
@fun.register(int, float)
def _(arg, verbose=False):
...
be
So I am a strong +1 on allowing multiple types to be registered in one call.
Yeah, agreed. It also fits the pattern set by isinstance(), which
allows a tuple of types, like isinstance(x, (int, str)).
That said, I'm +0 on this PEP itself. It seems no one has provided
decent use-case examples
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt benh...@gmail.com wrote:
It seems no one has provided
decent use-case examples (apart from contrived ones)
Um, copy.copy(), pprint.pprint(), a bunch of functions in pkgutil
which are actually *based on this implementation already* and have
been since
On 05/23/2013 02:02 PM, Ronan Lamy wrote:
2013/5/23 Łukasz Langa luk...@langa.pl mailto:luk...@langa.pl
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org
mailto:mer...@netwok.org wrote:
Question: what happens if two functions (say in two different modules)
are registered
On May 23, 2013 4:37 PM, Steven D'Aprano st...@pearwood.info wrote:
On 24/05/13 01:04, Ethan Furman wrote:
If the stdlib is still staying out of the annotation business, then it
should not be allowed.
Perhaps it is time to relax that ruling? The standard library acts as a
guide to best
On Thu, May 23, 2013 at 7:30 PM, Eric Snow ericsnowcurren...@gmail.com wrote:
If there were more
discussion and consensus on annotations + decorators I'd be more convinced.
However, this PEP should not be gated on any such discussion.
-eric
___
On Fri, May 24, 2013 at 11:45 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
On Thu, May 23, 2013 at 7:30 PM, Eric Snow ericsnowcurren...@gmail.com
wrote:
If there were more
discussion and consensus on annotations + decorators I'd be more convinced.
However, this PEP should not be gated
On Fri, May 24, 2013 at 10:31 AM, PJ Eby p...@telecommunity.com wrote:
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt benh...@gmail.com wrote:
It seems no one has provided
decent use-case examples (apart from contrived ones)
Um, copy.copy(), pprint.pprint(), a bunch of functions in pkgutil
which
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano st...@pearwood.info wrote:
I don't think that they will. Being able to register multiple types with a
single call reads very naturally to me, while multiple decorators still
looks weird. Even after many years of seeing them, I still get a
Hello,
I would like to submit the following PEP for discussion and evaluation.
PEP: 443
Title: Single-dispatch generic functions
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa luk...@langa.pl
Discussions-To: Python-Dev python-dev@python.org
Status: Draft
Type: Standards Track
I like the general idea. Does you have any specific stdlib use cases in
mind?
I thought of pprint, which at some point dispatches on dict versus
set/sequence, but overall it seems more complicated than mere arg type
dispatch.
Unittest.TestCase.assertEqual mostly (but not completely) uses
On 5/22/2013 3:33 PM, Łukasz Langa wrote:
2. does not have a standard way for methods to be added to existing
generic functions (i.e., some are added using registration
functions, others require defining ``__special__`` methods, possibly
by monkeypatching).
I assume you are talking
On 5/22/2013 5:55 PM, Guido van Rossum wrote:
On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
second parameter is as
On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
second parameter is as key to the dispatch as the first.
This (and
On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
second parameter is as key to the dispatch as the first.
While
Funny. I thought that the PEP was quite strong enough already in its
desire to stay away from multi-dispatch. But sure, I don't mind making
it stronger. :-)
On Wed, May 22, 2013 at 7:12 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman
83 matches
Mail list logo
