PEP 594: Update with discussion items

[tiran]

Updates from discussions on python-dev and Twitter.

• socketserver
• wave's dependency on audioop can be removed
• clarify crypt
• elaborate problems with NNTP tests
• smtpd is documented as deprecated since 3.4.7, 3.5.4, and 3.6.1.
• ask Pablo about pgen2 / lib2to3.
• @gvanrossum wants to deprecated the parser module. Maybe add it to the PEP, too?
• keep fileinput
• mention that Twisted plans to remove NNTP support (thx Nathaniel)

[tiran]

@gvanrossum @pablogsal I'm going to add the parser module to the PEP. The parser and grammar part of the Python interpreter is not my area of expertise. I'd appreciate a better wording from you.

[gvanrossum]

I'd propose to add the parser module to the list. If it were just up to me I'd remove it in 3.8, but I'm fine with deprecating now and removing in 3.9. The reason is that this module causes a lot of maintenance churn each time the grammar changes, and we have a better alternative in the ast module. Also, if we ever were to change our parsing technology (e.g. use a PEG grammar and a packrat parser), we'd likely do away with the entire CST, and generate AST nodes directly from the grammar. (For more color, see the python-dev thread "Parser module in the stdlib" started today by Pablo, and also https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379, and https://discuss.python.org/t/preparing-for-new-python-parsing/1550.)

[tiran]

Thanks! I'll update the PR with your feedback tomorrow.

[njsmith]

Some points you might or might not want to incorporate somehow:

• Twisted is also looking at removing their NNTP support, b/c they've been totally unable to find anyone interested in porting it to python 3: https://twistedmatrix.com/trac/ticket/9405

• The password hashing algorithms exposed by the crypt module are considered pretty lousy these days. They're sufficiently bad that the glibc itself is working on getting out of the business of maintaining crypt entirely, in favor of third party libraries that can do a better job keeping up with things: See: 1, 2

  It's possible someone out there is using crypt to hash passwords in their database or something, but there are much better options on PyPI: passlib, argon2, etc.

[gvanrossum]

I'm a little sad to see crypt go -- it would be useful for checking passwords against /etc/passwd as long as crypt(3) exists. TBH I liked it better when it just wrapped crypt(3) -- maybe it could be deprecated in two stages, leaving the original crypt(3) wrapper undeprecated until it's actually gone from libc on most platforms?

[tiran]

I'm a little sad to see crypt go -- it would be useful for checking passwords against /etc/passwd as long as crypt(3) exists. TBH I liked it better when it just wrapped crypt(3) -- maybe it could be deprecated in two stages, leaving the original crypt(3) wrapper undeprecated until it's actually gone from libc on most platforms?

This works only under some circumstances and does not verify that account fully:

• script runs as root and unrestricted execution context (otherwise SELinux and AppArmor don't allow access to /etc/shadow)
• user is actually stored in a file and not provided through other APIs like LDAP, SSSD, SQL database, NIS/YP, ...
• account restrictions (HBAC, session, ...) aren't checked

You can always install it from PyPI. I have added a ctypes-based interface to https://github.com/tiran/legacylib/tree/master/crypt/src, so you don't need a C compiler to install it.

[mcepl]

* Twisted is also looking at removing their NNTP support, b/c they've been totally unable to find anyone interested in porting it to python 3: https://twistedmatrix.com/trac/ticket/9405

And that means what? I hope you meant to say we should keep nttplib included, because we are the only ones to keep the support, right?

[tiran]

* Twisted is also looking at removing their NNTP support, b/c they've been totally unable to find anyone interested in porting it to python 3: https://twistedmatrix.com/trac/ticket/9405

And that means what? I hope you meant to say we should keep nttplib included, because we are the only ones to keep the support, right?

For me, it means nobody cares enough about NNTP to maintain NNTP code.

[njsmith]

And that means what?

It's a piece of information. It can support multiple arguments. I'm not pushing some predetermined agenda.

Also, I deleted one of your comments, because it was some kind of vague, passive aggressive insinuation. That's not appropriate here; if your want to make an argument, just say it and provide supporting evidence.