
The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd <https://docs.python.org/3/library/smtpd.html#module-smtpd> should be considered deprecated" and recommends aiosmtpd <http://aiosmtpd.readthedocs.io/>.
Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.
This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.

I would hope we’d remove it. It’s a toy implementation, unmaintained, probably doesn’t support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!
On Tue, Jun 22, 2021 at 17:51 Irit Katriel via python-committers < python-committers@python.org> wrote:
The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd <https://docs.python.org/3/library/smtpd.html#module-smtpd> should be considered deprecated" and recommends aiosmtpd <http://aiosmtpd.readthedocs.io/>.
Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.
This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido (mobile)

I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!
I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.
-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara <andrewm@object-craft.com.au> wrote:
I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!
I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.
-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.

Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?
For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.
For example, I now wonder how Andrew is different from those people?
On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner <vstinner@python.org> wrote:
Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara <andrewm@object-craft.com.au> wrote:
I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is
probably
full of bugs. Hopefully nobody uses it!
I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.
-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Best, Joannah Nanjekye
*"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis*

Also, it seems this discussion should happen on python-dev so that more people are aware of it.
Regards
Antoine.
Le 23/06/2021 à 14:58, Joannah Nanjekye a écrit :
Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?
For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.
For example, I now wonder how Andrew is different from those people?
On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner <vstinner@python.org <mailto:vstinner@python.org>> wrote:
Hi Andrew, If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository. Create a project on PyPI if you expect contributions. Victor On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara <andrewm@object-craft.com.au <mailto:andrewm@object-craft.com.au>> wrote: > > >I would hope we'd remove it. It's a toy implementation, unmaintained, > >probably doesn't support a lot of newer protocol features, and is probably > >full of bugs. Hopefully nobody uses it! > > I use it and it works well for my specific use case - a Postfix spam > filter. During incoming SMTP transactions, I have Postfix configured to > pass the received message to my daemon via SMTP (smtpd_proxy_filter). My > daemon pronounces judgement, allowing Postfix to potentially reject the > message while the sender is still connected (so no bounce backscatter). My > daemon only receives one connection at a time, and only well formed SMTP > from postfix, so the smtpd module works well - no need for a 3rd party > module or the hassle of async. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ <http://www.object-craft.com.au/> > _______________________________________________ > python-committers mailing list -- python-committers@python.org <mailto:python-committers@python.org> > To unsubscribe send an email to python-committers-leave@python.org <mailto:python-committers-leave@python.org> > https://mail.python.org/mailman3/lists/python-committers.python.org/ <https://mail.python.org/mailman3/lists/python-committers.python.org/> > Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/QA2OVVFX564H5EBARUKODUPMYHTJAMCO/ <https://mail.python.org/archives/list/python-committers@python.org/message/QA2OVVFX564H5EBARUKODUPMYHTJAMCO/> > Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/> -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- python-committers@python.org <mailto:python-committers@python.org> To unsubscribe send an email to python-committers-leave@python.org <mailto:python-committers-leave@python.org> https://mail.python.org/mailman3/lists/python-committers.python.org/ <https://mail.python.org/mailman3/lists/python-committers.python.org/> Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N7FUYCFY3HJ4WV43WOUYJ2VDABZ2LBRU/ <https://mail.python.org/archives/list/python-committers@python.org/message/N7FUYCFY3HJ4WV43WOUYJ2VDABZ2LBRU/> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
-- //Best, Joannah Nanjekye /"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/W... Code of Conduct: https://www.python.org/psf/codeofconduct/

FWIW: PEP 594 doesn't seem to have been updated with all the discussions we had around it, e.g. the nntplib is still marked for removal, even though the only reason is related to servers used in the test suite sometimes causing delays, which I will be fixing with Ee by setting up our own test server.
Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.
On 23.06.2021 15:16, Antoine Pitrou wrote:
Also, it seems this discussion should happen on python-dev so that more people are aware of it.
Regards
Antoine.
Le 23/06/2021 à 14:58, Joannah Nanjekye a écrit :
Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?
For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.
For example, I now wonder how Andrew is different from those people?
On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner <vstinner@python.org <mailto:vstinner@python.org>> wrote:
Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara <andrewm@object-craft.com.au <mailto:andrewm@object-craft.com.au>> wrote: > > >I would hope we'd remove it. It's a toy implementation, unmaintained, > >probably doesn't support a lot of newer protocol features, and is probably > >full of bugs. Hopefully nobody uses it! > > I use it and it works well for my specific use case - a Postfix spam > filter. During incoming SMTP transactions, I have Postfix configured to > pass the received message to my daemon via SMTP (smtpd_proxy_filter). My > daemon pronounces judgement, allowing Postfix to potentially reject the > message while the sender is still connected (so no bounce backscatter). My > daemon only receives one connection at a time, and only well formed SMTP > from postfix, so the smtpd module works well - no need for a 3rd party > module or the hassle of async. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ <http://www.object-craft.com.au/> > _______________________________________________ > python-committers mailing list -- python-committers@python.org <mailto:python-committers@python.org> > To unsubscribe send an email to python-committers-leave@python.org <mailto:python-committers-leave@python.org> > https://mail.python.org/mailman3/lists/python-committers.python.org/ <https://mail.python.org/mailman3/lists/python-committers.python.org/> > Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q...
<https://mail.python.org/archives/list/python-committers@python.org/message/Q...>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
-- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- python-committers@python.org <mailto:python-committers@python.org> To unsubscribe send an email to python-committers-leave@python.org <mailto:python-committers-leave@python.org> https://mail.python.org/mailman3/lists/python-committers.python.org/ <https://mail.python.org/mailman3/lists/python-committers.python.org/> Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N...
<https://mail.python.org/archives/list/python-committers@python.org/message/N...>
Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
-- //Best, Joannah Nanjekye /"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/W...
Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N...
Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 23 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

On Jun 23, 2021, at 09:46, Marc-Andre Lemburg <mal@egenix.com> wrote:
Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.
That’s basically what PEP 594 suggests, and I think that’s a good approach while we’re working out the details and process for removing dead batteries.
-Barry

On 23.06.2021 19:17, Barry Warsaw wrote:
On Jun 23, 2021, at 09:46, Marc-Andre Lemburg <mal@egenix.com> wrote:
Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.
That’s basically what PEP 594 suggests, and I think that’s a good approach while we’re working out the details and process for removing dead batteries.
Ah, found that section at the very bottom of the PEP now. Thanks.
It may be better to move this all the way up, since I'm pretty sure that it'll make people feel better.
The attic repo would need to go unter the Python Github account though to make it more official and also make sure the licensing aspect it dealt with properly (the PSF would have to officially distribute the package to be able to use the CLA relicensing).
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 24 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye <nanjekyejoannah@gmail.com> wrote:
Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?
For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.
For example, I now wonder how Andrew is different from those people?
asynchat and asyncore are deprecated since 3.6. Doesn't this mean that the decision to remove them was already taken?

On 23. 06. 21 15:21, Irit Katriel via python-committers wrote:
On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye <nanjekyejoannah@gmail.com <mailto:nanjekyejoannah@gmail.com>> wrote:
Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains? For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain. For example, I now wonder how Andrew is different from those people?
asynchat and asyncore are deprecated since 3.6. Doesn't this mean that the decision to remove them was already taken?
"Deprecation" was much more vague in 3.6 than it is now. I don't think the current process from PEP-387 was followed with these modules -- I don't see any deprecation warnings being raised.

Hi Irit,
Since it's documented as deprecated, asyncore and asynchat are deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest to remove these 3 modules right now. I would prefer to make such incompatible change early in the development cycle, to give more time to users to adapt their projects.
We should explain to users how to handle this incompatible change in What's New in Python 3.11. IMO suggesting to copy the required modules into their project is an acceptable trade-off.
Victor
On Wed, Jun 23, 2021 at 2:51 AM Irit Katriel via python-committers <python-committers@python.org> wrote:
The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd should be considered deprecated" and recommends aiosmtpd.
Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.
This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.

I've created https://bugs.python.org/issue44498, so we can continue the discussion there.
Once we remove the libraries, we could create a list of all open issues, put this list in another issue, link to it from what's new and then close all issues (including the one with the list). This way the known bugs will not be lost in case someone wants to maintain the code outside the stdlib.
On Wed, Jun 23, 2021 at 9:14 AM Victor Stinner <vstinner@python.org> wrote:
Hi Irit,
Since it's documented as deprecated, asyncore and asynchat are deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest to remove these 3 modules right now. I would prefer to make such incompatible change early in the development cycle, to give more time to users to adapt their projects.
We should explain to users how to handle this incompatible change in What's New in Python 3.11. IMO suggesting to copy the required modules into their project is an acceptable trade-off.
Victor
participants (9)
-
Andrew McNamara
-
Antoine Pitrou
-
Barry Warsaw
-
Guido van Rossum
-
Irit Katriel
-
Joannah Nanjekye
-
Marc-Andre Lemburg
-
Petr Viktorin
-
Victor Stinner