Mailman 3 June 2020 - Twisted

[Twisted-Python] mypy: class ThreadPool has workers redefined
by Craig Rodrigues June 17, 2020

June 17, 2020

While looking at these mypy logs: https://dev.azure.com/twistedmatrix/twisted/_build/results?buildId=1904&vie… I found an interesting one: src/twisted/python/threadpool.py:84:6: error: Name 'workers' already defined on line 44 [no-redef] Looking at: https://github.com/twisted/twisted/blob/trunk/src/twisted/python/threadpool…, I see: workers = 0 @property def workers(self): What is the correct way to fix this? Is deleting the workers variable correct? -- Craig

1 0

[Twisted-Python] Question about FileDescriptor.loseConnection() signature found by mypy
by Craig Rodrigues June 16, 2020

June 16, 2020

In twisted.internet.abstract.FileDescriptor.loseConnection, the loseConnection method is defined like: def loseConnection(self, _connDone=failure.Failure(main.CONNECTION_DONE)): while in twisted.internet._newtls.ConnectionMixin , we have: def loseConnection(self): If I run *tox -e mypy* in trunk, mypy complains with this: src/twisted/internet/tcp.py:204:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] src/twisted/internet/tcp.py:527:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] src/twisted/internet/tcp.py:780:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] src/twisted/internet/tcp.py:789:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] src/twisted/internet/unix.py:243:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] src/twisted/internet/unix.py:431:1: error: Definition of "loseConnection" in base class "ConnectionMixin" is incompatible with definition in base class "FileDescriptor" [misc] Do the signatures of loseConnection need to match in order for this to be a valid subclass? Is there any way to fix the code so that the mypy error goes away, or do we need to add a comment to turn off the mypy error here? -- Craig

4 4

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com June 14, 2020

June 14, 2020

1 0

[Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
by Craig Rodrigues June 8, 2020

June 8, 2020

I would like to propose that Twisted drop support for Python 3.5 one year from now in 2021. Reasons: 1. Python 3.5.9 will be the final release of Python 3.5, in November 2019 ( https://www.python.org/dev/peps/pep-0478/ ) 2. Python 3.6.0 was released in December 2016 ( https://www.python.org/dev/peps/pep-0494/ ) 3. PyPy 7.1.1 introduced Python 3.6 support in April 2019 ( https://morepypy.blogspot.com/2019/04/pypy-711-bug-fix-release.html ). PyPy 7.3.1 is the latest PyPy version ( https://morepypy.blogspot.com/2020/04/pypy-731-released.html ). 4. Python 3.6 introduced support for variable annotations ( https://www.python.org/dev/peps/pep-0526/ ) 5. Python 3.6 introduced new string interpolation (f-string) support ( https://www.python.org/dev/peps/pep-0498/ ) 6. Python 3.6 introduced support for asynchronous generators ( https://www.python.org/dev/peps/pep-0525/ ) and asynchronous comprehensions ( https://www.python.org/dev/peps/pep-0530/ ) Based on item 2., Python 3.6.0 has been around for almost 4 years, which is a reasonable amount of time. Based on item 3., PyPy supports Python 3.6. It might be nice to take advantage of some of the language features introduces in items 4-6. I think dropping support one year from now in 2021, would give sufficient notice, and be in line with the Twisted Compatibility Policy ( https://twistedmatrix.com/documents/current/core/development/policy/compati… ). None of these items are critial, but I thought I would ask, to get people's opinions. -- Craig

11 30

[Twisted-Python] log.callWithLogger not used - slows down reactor?
by Barry Scott June 8, 2020

June 8, 2020

I'm hunting down performance issue in our code and spotted this in passing. As far I can tell nothing seems to need callWithLogger. I ran our 6k+ tests with this patch applied and everything worked. Does anything in the twisted world need it? Barry diff --git a/src/twisted/internet/pollreactor.py b/src/twisted/internet/ pollreactor.py index 6db1660b9..6901e5c95 100644 --- a/src/twisted/internet/pollreactor.py +++ b/src/twisted/internet/pollreactor.py @@ -165,7 +165,7 @@ class PollReactor(posixbase.PosixReactorBase, posixbase._PollLikeMixin): # Handles the infrequent case where one selectable's # handler disconnects another. continue - log.callWithLogger(selectable, _drdw, selectable, fd, event) + _drdw(selectable, fd, event) doIteration = doPoll

2 3

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com June 7, 2020

June 7, 2020

1 0

[Twisted-Python] Deprecate and remove t.internet.ssl.DistinguishedName ?
by Wim Lewis June 3, 2020

June 3, 2020

I'm looking at a fix for bug <https://twistedmatrix.com/trac/ticket/9804> (Cannot load a PEM certificate with Unicode in subject). The underlying problem is that the DistinguishedName class can't handle non-ascii AVAs. The fix I've made simply avoids creating DistinguishedName instances when it isn't necessary, but that leaves the question of what to do with the class. I think that the best thing to do is to deprecate the class entirely and replace it with simpler API. Reasons I think that the DN class is broken: - The values in a certificate are conceptually text-strings, not byte strings; they may be in ASCII, UTF8, UTF16, or several other encodings. However - DN represents these textual values as `bytes` instead of `str` - DN can't handle non-ASCII-representable values at all, even if the user never tries to access that value - It can only handle a subset of the attribute-assertions found in a PKIX DN; there's no escape hatch for others (e.g. OID keys or whatever) - It can't represent the full structure of a DN (specific ordering, multiple-value RDNs, AVAs whos values aren't textual, etc.) --- these are not common in the PKIX world but they are valid What I propose as an alternative: - Replace APIs that take `DistinguishedName` classes with ones that take `Union[OpenSSL.crypto.X509Name, dict]` where the `dict` format is parsed with the same convenience semantics as DistinguishedName, except that values are `str` - Replace APIs that return `DistinguishedName` with ones that return OpenSSL.crypto.X509Name, which is already fairly convenient to use (e.g. it has attributes for retrieving/setting commonName and so on without dealing with the full complexity of X.500 names) - Deprecate `DistinguishedName` and the APIs that use it for eventual removal - Expose a convenience function for the dict -> X509Name transform Any objections? Thoughts on how I should go about doing this? Should I do it as part of this Trac ticket or split it out? The only downside I can think of is that this exposes the OpenSSL.crypto.X509Name type as part of Twisted's API. I don't think this is a huge reduction in flexibility --- Twisted's API already somewhat assumes that TLS is implemented using OpenSSL, and only users whose needs are *already* not well met by DistinguishedName will care if that `Union` type changes in the future. Wim Lewis / wiml(a)hhhh.org

2 1