mail address handling in mailer.py

C. Michael Pilato wrote:
> Mathias Weinert wrote:
> > I wonder if such a function is needed at all. For
me it would be enough
> > to use the comma instead of whitespaces. But that
may result in problems
> > for people updating to this version (which will
BTW be the same with your
> > proposal).
> 
> Hrm.  I forgot that the existing code splits on
whitespace.  Bummer.
> 
> > What do you think about keeping it very simple and
just changing the
> > split char from whitespace to comma?
> 
> Honestly, that's fine by me.  I just figured folks
would get tripped up when
> they copy addresses from their address books like:
> 
>    "Weinert, Mathias"
<mathias.weinertsomeplace.oroth.er>

Okay, I didn't think of such a use case.

> 
> So, if we want cheap compability without an ugly wart
like
> "to_addr_split_char", we can do this:
> 
>    * add a new 'to_addrs' (or 'to_addresses')
option that has
>      whatever splitting rules we want
>    * deprecate the 'to_addr' option
>    * for kicks, stick an X-Subversion-Mailer-Warning:
header in mails
>      that are generated by instances that still use
'to_addr'  
>      generated by mailer.py
> 

Adding a new option 'to_addrs' is okay for me. So the
following questions
have to be answered:

o Do we use to_addr only if to_addrs isn't set or do we
combine them?
  -> I would say use only one of them.

o Which character will be used for splitting?
  -> Although several (most) mail clients use ',' I
could also accept to
     use the semicolon ';'. So is it ',' or ';'?

o Do we want to use your code example to make the splitting
process more
  smart?
  -> In order to not make it too complicated I would say
'No' (although
     I appreciate your code example).

What do you think?

Mathias

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Mathias Weinert wrote:
> C. Michael Pilato wrote:
>   
>> Mathias Weinert wrote:
>>     
>>> I wonder if such a function is needed at all.
For me it would be enough
>>> to use the comma instead of whitespaces. But
that may result in problems
>>> for people updating to this version (which will
BTW be the same with your
>>> proposal).
>>>       
>> Hrm.  I forgot that the existing code splits on
whitespace.  Bummer.
>>
>>     
>>> What do you think about keeping it very simple
and just changing the
>>> split char from whitespace to comma?
>>>       
>> Honestly, that's fine by me.  I just figured folks
would get tripped up when
>> they copy addresses from their address books like:
>>
>>    "Weinert, Mathias"
<mathias.weinertsomeplace.oroth.er>
>>     
>
> Okay, I didn't think of such a use case.
>
>   
>> So, if we want cheap compability without an ugly
wart like
>> "to_addr_split_char", we can do this:
>>
>>    * add a new 'to_addrs' (or 'to_addresses')
option that has
>>      whatever splitting rules we want
>>    * deprecate the 'to_addr' option
>>    * for kicks, stick an
X-Subversion-Mailer-Warning: header in mails
>>      that are generated by instances that still use
'to_addr'  
>>      generated by mailer.py
>>
>>     
>
> Adding a new option 'to_addrs' is okay for me. So the
following questions
> have to be answered:
>
> o Do we use to_addr only if to_addrs isn't set or do
we combine them?
>   -> I would say use only one of them.
>
> o Which character will be used for splitting?
>   -> Although several (most) mail clients use ','
I could also accept to
>      use the semicolon ';'. So is it ',' or ';'?
>
> o Do we want to use your code example to make the
splitting process more
>   smart?
>   -> In order to not make it too complicated I would
say 'No' (although
>      I appreciate your code example).
>
> What do you think?
>   

I think it's a waste of time to write this kind of parser
in Python. 

Teach mailer.py to expect a Python list in the to_addr
option it the
character in the option value is a bracket. So, if you
write:

   to_addr = [ 'list', 
               'of',
               'mail',
               'addresses' ]

you can simply evaluate the option's value and get a Python
list object.\
On the con side, the list elements would have to be valid
Python
strings, using Python's quoting rules.

-- Brane

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org