Re: Why does ModelForm do validation and not Model

[Aymeric Augustin]

Hi Curtis,

Le mer. 17 avr. 2019 à 22:32, Curtis Maloney  a écrit :

> It's mostly for performance reasons, since validation can be expensive.
>
> Really? My memory was that it was (a) backward compatibility [model
> validation was added later], and (b) practicality [try catching
> everywhere in your code you save a model, and enforce catching
> validation exceptions there].
>

These arguments are absolutely valid.

I can't say for sure if some concerns ranked higher than others.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mXP3P%2BBeKnU4Mu8WuC3Gh9PWh-2GDaC7H0Kzc6%2BEtcexg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelForm do validation and not Model

[Václav Řehák]

Dne čtvrtek 18. dubna 2019 10:56:55 UTC+2 Aymeric Augustin napsal(a):
>
> Le mer. 17 avr. 2019 à 22:32, Curtis Maloney  > a écrit :
>
> > It's mostly for performance reasons, since validation can be expensive. 
>>
>> Really? My memory was that it was (a) backward compatibility [model 
>> validation was added later], and (b) practicality [try catching 
>> everywhere in your code you save a model, and enforce catching 
>> validation exceptions there].
>>
>
> These arguments are absolutely valid.
>
> I can't say for sure if some concerns ranked higher than others.
>

The question is if there is consensus that model validation should really 
be opt-in.

 As a veteran Django user, I am quite used to it but as I work on financial 
project (with strong requirements on data consistency) with a team of 
senior developers kind of new to Django I face a lot of confusion about why 
does Django let us save invalid data (actually last week I spent almost 3 
days on fixes caused forgotten calls to full_clean and on data migration to 
clean up the mess). If it was possible, e.g. in settings, to force model 
validation in save(), it would help us a lot.

Vaclav

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c7fc8f6-1329-456a-985c-5f0771084b1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jani Tiainen]

Well let me add my two cents here since I was also in the group in DCEU
that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a
comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually
depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't
get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some
other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In
my short experience with black (I've been using it for work projects) it
does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I
don't have to. Black does it for a "greater good". And after a while black
actually vanishes from the flow.

On Sat, Apr 13, 2019 at 6:35 PM Herman S  wrote:

> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I recommend reading the the projects
> README.
> The short version: it aims to reduce bike-shedding and non value-adding
> discussions; saving time reviewing code; and making the barrier to entry
> lower
> by taking some uncompromissing choices with regards to formatting.  This is
> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>
> Personally I first got involved contributing to Django couple of weeks
> back,
> and from anecdotal experience I can testify to how 'formatting of code'
> creates
> a huge barrier for entry. My PR at the time went multiple times back and
> forth
> tweaking formatting. Before this, I had to research the style used by
> exploring
> the docs at length and reading at least 10-20 different source – and even
> those
> were not always consistent. At the end of the day I felt like almost 50%
> of the
> time I used on the patch was not used on actually solving the issue at
> hand.
> Thinking about code formatting in 2019 is a mental energy better used for
> other
> things, and it feels unnecessary that core developers on Django spend
> their time
> "nit-picking" on these things.
>
> I recently led the efforts to make this change where I work. We have a
> 200K+
> LOC Django code-base with more than 30K commits. Some key take-aways: it
> has
> drastically changed the way we work with code across teams, new engineers
> are
> easier on-boarded, PR are more focused on architectural choices and "naming
> things", existing PRs before migration had surprisingly few conflicts and
> were
> easy to fix, hot code paths are already "blameable" and it's easy to blame
> a
> line of code and go past the "black-commit", and lastly the migration went
> without any issues or down-time.
>
> I had some really fruitful discussions at DjangoCon Europe this week on
> this
> very topic, and it seems we are not alone in these experiences. I would
> love to
> hear from all of you and hope that we can land on something that will
> enable
> *more* people to easier contribute back to this project.
>
> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no string normalization:
> https://github.com/hermansc/django/pull/2
>
> Please have a look at the Black documentation. It explains the benefits
> better
> than I possibly could do here.
>
> With kind regards,
> Herman Schistad
>
> [0]: https://github.com/ambv/black
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen
Software wizard

https://blog.jani.tiainen.cc/

Always open for short term jobs or contracts to work with Django.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit th

Re: django_chatterbot

[Meow]

Hi, Abhineet, could you show us the code ?
On Apr 18, 2019, 06:47 +0800, Abhineet Baranwal , 
wrote:
> Hello there,
> I am using django chatterbot but whenevere i typed any new sentence and hit 
> enter then the bot returns always the current time.I do not know why it 
> always respond with the current time .Any ideas?
>
> And can anyone tell me how we can train my personal data with django 
> chatterbot ?
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/02cefd26-feed-49be-9dc8-19cb80827a6c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e4060833-68bc-42b3-b86e-b33d7636fe41%40Spark.
For more options, visit https://groups.google.com/d/optout.

Running Django test suite foo first time on windows Hanging

[Chris Wedgwood]

Hi 

I am running django's test suite for the first time on windows as part of 
the onboarding tutorial(
https://docs.djangoproject.com/en/dev/intro/contributing/)
 and one of the instructions is to run

...\> runtests.py

 when I run this the file is opened in vscode and I dont see any output. It may 
be running in the background.

When I use

...\> python runtests.py

It works.

Do I need to configure something in windows for it to work without the python 
prefix?

Or should the python prefix be added to the docs?

Thanks

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/302f6a44-cb02-40fc-825b-be0dd2922b3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelForm do validation and not Model

[Tobias Kunze]

On 19-04-18 05:07:53, Václav Řehák wrote:
>If it was possible, e.g. in settings, to force model 
>validation in save(), it would help us a lot.

Would it help you even if this would only apply to actual `save()`
calls, no bulk creates, no bulk updates, and no modifications of
m2m relationships via add/remove? I'm not sure if "forced validation …
on some cases" wouldn't be even more confusing in those tricky cases.

Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20190418152718.pvdhxgsyeudzrdls%40cordelia.localdomain.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Running Django test suite foo first time on windows Hanging

[Adam Johnson]

Hi Chris!

I'm not a Windows user, but I guess something in your Windows configuration
is making the Python file open in VSCode rather than get run by the Python
interpreter. Probably installing VSCode after Python reconfigured Windows
to do this.

The first line of runtests.py is a shebang:
https://github.com/django/django/blob/master/tests/runtests.py#L1 . This
tells unix systems how to run the file, which is why ./runtests.py works
there. I don't believe Windows has such a feature.

Probably the documentation for should be updated to show "python
runtests.py" as you suggest. This will show for both unix and windows,
since they are sourced from the same line (the "windows" mode is just some
different formattting). That line is:
https://github.com/django/django/blob/master/docs/intro/contributing.txt#L208

A good first contribution - if you find anything else problematic with the
tutorial on Windows, add it to your PR!

Thanks,

Adam

On Thu, 18 Apr 2019 at 16:02, Chris Wedgwood  wrote:

> Hi
>
> I am running django's test suite for the first time on windows as part of
> the onboarding tutorial(
> https://docs.djangoproject.com/en/dev/intro/contributing/)
>  and one of the instructions is to run
>
> ...\> runtests.py
>
>  when I run this the file is opened in vscode and I dont see any output. It 
> may be running in the background.
>
> When I use
>
> ...\> python runtests.py
>
> It works.
>
> Do I need to configure something in windows for it to work without the python 
> prefix?
>
> Or should the python prefix be added to the docs?
>
> Thanks
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/302f6a44-cb02-40fc-825b-be0dd2922b3f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2tOo%3DqRnDHP%3DPhw10f7CHuW%3D8EFdGk6uWtGLtFS2dqJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Django test suite foo first time on windows Hanging

[Chris Wedgwood]

Thanks Adam will do!

On Thursday, 18 April 2019 16:36:48 UTC+1, Adam Johnson wrote:
>
> Hi Chris!
>
> I'm not a Windows user, but I guess something in your Windows 
> configuration is making the Python file open in VSCode rather than get run 
> by the Python interpreter. Probably installing VSCode after Python 
> reconfigured Windows to do this.
>
> The first line of runtests.py is a shebang: 
> https://github.com/django/django/blob/master/tests/runtests.py#L1 . This 
> tells unix systems how to run the file, which is why ./runtests.py works 
> there. I don't believe Windows has such a feature.
>
> Probably the documentation for should be updated to show "python 
> runtests.py" as you suggest. This will show for both unix and windows, 
> since they are sourced from the same line (the "windows" mode is just some 
> different formattting). That line is: 
> https://github.com/django/django/blob/master/docs/intro/contributing.txt#L208
>
> A good first contribution - if you find anything else problematic with the 
> tutorial on Windows, add it to your PR!
>
> Thanks,
>
> Adam
>
> On Thu, 18 Apr 2019 at 16:02, Chris Wedgwood  > wrote:
>
>> Hi 
>>
>> I am running django's test suite for the first time on windows as part of 
>> the onboarding tutorial(
>> https://docs.djangoproject.com/en/dev/intro/contributing/)
>>  and one of the instructions is to run
>>
>> ...\> runtests.py
>>
>>  when I run this the file is opened in vscode and I dont see any output. It 
>> may be running in the background.
>>
>> When I use
>>
>> ...\> python runtests.py
>>
>> It works.
>>
>> Do I need to configure something in windows for it to work without the 
>> python prefix?
>>
>> Or should the python prefix be added to the docs?
>>
>> Thanks
>>
>> Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-d...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/302f6a44-cb02-40fc-825b-be0dd2922b3f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4c8de217-42a4-4146-aa0a-2684b91bb633%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PR review request https://github.com/django/django/pull/11157

[Petr Glotov]

Not sure if posting review requests to mailing list is part of the process, 
but could we get https://github.com/django/django/pull/11157
 reviewed/merged?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fdc935fd-43e8-4627-a033-37c6100e5e9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PR review request https://github.com/django/django/pull/11157

[Mariusz Felisiak]

Posting review request is not a part of our workflow. You should uncheck 
"Patch needs improvement" flag on the ticket if you think that it is ready 
for review. Currently it is not in tickets waiting for review (see Patches 
needing review 
).
 
You need to be patient we have +30 tickets waiting for review.

Best,
Mariusz

W dniu czwartek, 18 kwietnia 2019 17:46:51 UTC+2 użytkownik Petr Glotov 
napisał:
>
> Not sure if posting review requests to mailing list is part of the 
> process, but could we get https://github.com/django/django/pull/11157
>  reviewed/merged?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1108e489-ec01-43ee-9198-ac5830795661%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django_chatterbot

[Aymeric Augustin]

Hello,

This mailing list is for the development of Django itself, not for support 
using Django or third-party apps.

Please use the support channels for the django-chatterbot project or a site 
like Stack Overflow.

-- 
Aymeric.



> On 18 Apr 2019, at 10:39, Meow  wrote:
> 
> Hi, Abhineet, could you show us the code ?
> On Apr 18, 2019, 06:47 +0800, Abhineet Baranwal 
> , wrote:
>> Hello there,
>> I am using django chatterbot but whenevere i typed any new sentence and hit 
>> enter then the bot returns always the current time.I do not know why it 
>> always respond with the current time .Any ideas?
>> 
>> And can anyone tell me how we can train my personal data with django 
>> chatterbot ?
>> 
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com 
>> .
>> To post to this group, send email to django-developers@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/02cefd26-feed-49be-9dc8-19cb80827a6c%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/e4060833-68bc-42b3-b86e-b33d7636fe41%40Spark
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12D51EAB-AE27-4439-9EDD-0F414BCBEB0C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Development story for CBV FormViews using GET

[Jamesie Pic]

Hi Kye,

Sorry for mispelling your name above, but it's a really long thread and
non-native. And I can tell, there's rarely a better way than discussing in
foreign languages to make a nice little fool of myself xD This time I will
share my story with CBV, a story with love, and code and aggressive design
patterns in it. This is all because one of you consulting for yourlabs made
a comment about my shitty JS code: it was non aggressive. I've been working
that state of mind and then ...

The first violation I made to any bare common sense was to add support for
magical getters ... now view.url can return the result of view.get_url()

... And then I went on breaking Python by adding support in the type as
well ... now View.url can also return the result of View.get_url()

... At the price of thread safety, I guess I'm lucky it was always an easy
fix "just use the right variable you're allowed to but keep on refactoring"

... And then it became even more obscure when the magical getter also was
able to detect if {V,v}iew.get_url(view) would have not returned anything,
but did set {V,v}iew.url as attribute ... now caching became absolutely
free ...

... And then added a Controller in-between Model and its set of View ...
now Django knows MVC and can generate object level menus with efficient
permission management thanks to the Django permission backend that has so
many plugins or whatever implementation you put to override per controller
or view ...

... And then added a rich experience from out of the box templates because
why not after all django-webpack-loader by @alihazemfarouk is dope to
upgrade front end development workflow to a level like Python ...

... Don't ask what front-end framework cause what matters to me is the
practice of an modular development workflow, not which JS framework ...

... All this because a friend of mine who didn't understand Django, didn't
understand why we should hardcode menu HTML code, and cried in my laps for
help to refactor for days, the first name for the Controller class was
"Drycrud", do you imagine, instanciating a new Drycrud object ? Even more
obscure. Well at least it's named Router for now but in its final version
it needs to be called Controller because it sits between the Model and it's
set of class Based views ...

... So the generic ListView for example is like:
class ListView(mixins.ListMixin, mixins.SearchMixin, mixins.FilterMixin,
mixins.TableMixin, mixins.ObjectsMixin, TemplateView):
def get_object_list(self):
if self.filterset:
self.object_list = self.filterset.qs
else:
self.object_list = self.queryset
if self.search_form:
self.object_list = self.search_form.get_queryset()
return self.object_list
def get_listactions(self):
return self.controller.get_menu('list_action', self.request)

The view.listactions variable allows a view to override programmatically
what items the default list view template will propose for selected items.
It takes the request object for permission checking which is pretty raw but
turns out to just work: router.get_menu() returns a list of View classes of
the same Controller (thus same Model in practice), for which
view.has_perm() returns true. has_perm() is called once the view has been
hydrated with the passed request object in view.request. Your high level
code uses view.object instead of view.get_object(), because get_object()
will already be called automatically as a magic getter

As for get_object_list horror ... hopefully it's the only class in the
whole crudlfap.views.generic that encapsulates this kind of coupling, but
at the same time the coupling in there depends on what the parent mixins
offer and that is quite tricky to get right, but at the end of the day it's
just gluing the mixins together.

Please forgive this horror story from being loaded with absolutely
non-impressive material:

https://gitpitch.com/yourlabs/crudlfap
http://crudlfap--jpic.repl.co/
http://crudlfap.rtfd.io/

Want to share more use cases with CBVs ? Reply to the list now !

Thanks for reading and have a great day ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_bK7PJLBHOJUaUaAFRVtMNVS-J080f2SnUZmfSLzY%2B1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.