hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
Using windows 10 with Python 3.5, importing pretty much anything gives
me the following error. Not sure if there's something wrong with my
configuration or if it's a bug... I seem to remember something a while
back, should I file a ticket?
Traceback (most recent call last):
File "<string>", line 1, in <module>
line 38, in <module>
from twisted.internet import default
line 56, in <module>
install = _getInstallFunction(platform)
line 50, in _getInstallFunction
from twisted.internet.selectreactor import install
18, in <module>
from twisted.internet import posixbase
line 18, in <module>
from twisted.internet import error, udp, tcp
File "C:\python35\lib\site-packages\twisted\internet\udp.py", line
53, in <module>
from twisted.internet import base, defer, address
File "C:\python35\lib\site-packages\twisted\internet\base.py", line
23, in <module>
from twisted.internet import fdesc, main, error, abstract, defer,
File "C:\python35\lib\site-packages\twisted\internet\defer.py", line
29, in <module>
from twisted.python import lockfile, failure
File "C:\python35\lib\site-packages\twisted\python\lockfile.py", line
52, in <module>
_open = file
NameError: name 'file' is not defined
I'm trying to configure logging of my application depending on whether
or not the -y (--nodaemon) option of twistd is given. Actually very
similar to the default behavior, I would just like to switch to daily
log files. But it seems the application created has no access to the
config (used by underlying twistd and the ApplicationRunner).
What's the best way to switch to daily log files using twistd?
Working off the example ampserver.py and ampclient.py examples, I
wanted to build a client which maintains a single connection while
allowing the passing of messages back and forth. However I'm stuck at
one of the most basic steps, getting back the result (without
'completing' the connection).
The ampclient.py example simply connects, does a callRemote on the
resulting protocol, and adds callbacks to extract the result from a
dictionary and print it. The deferred being used in this case is
produced by connectProtocol.
I'm trying to write a client (inheriting from amp.AMP) which is
embedded in a kivy GUI, something which is quite possible using the
On connection, I use the connectionMade method to save the 'self' (in
this case, the client inheriting from amp.AMP) in my kivy app. I can
then call a function which does a callRemote on this saved client,
which indeed triggers the server appropriately.
The callRemote returns a deferred (from reading docs online, a remote
reference). I can't figure out what to do with it, specifically in
terms of getting the result ('total', when calling Sum from
Assistance much appreciated.
As many know, one of the things that makes the Twisted project so unique is our conformance to our Compatibility Policy. This policy means that users of Twisted can freely upgrade between versions with all incompatibilities being warned about before causing code to break. However, for a while, one part of the compatibility policy has caused issues - what we do with code that has been deprecated for a long time, and at least the release + 2 & 1 year after.
The existing policy states:
"Removal should happen once the deprecated API becomes an additional maintenance burden. For example, if it makes implementation of a new feature more difficult, if it makes documentation of non-deprecated APIs more confusing, or if its unit tests become an undue burden on the continuous integration system. Removal should not be undertaken just to follow a timeline."
This makes the only reasonable cause for any code being removed from Twisted is if it is a maintenance burden, but does not take into account the effect that keeping large amounts of deprecated code has on new, existing, and future Twisted users. It does specify that it should be removed if it makes documentation of non-deprecated APIs confusing, but by its very existence, it makes what should be "best practice" more confusing -- especially if the deprecated API is "simpler" at first glance, but was deprecated because of vast underlying issues,
Discussions have come to the conclusion that the exact reverse of this policy should be instated:
"Removal of code should occur as soon as the deprecation grace period has ended."
The reason for this is that a leaner Twisted is a better Twisted -- we should strive to not break existing applications, but we have the deprecation policy in place to ensure that breakage is, if all goes to plan, never out of the blue. Less code surface means that Twisted is easier to learn for new users and Twisted-using projects onboarding new people, easier to use for established users with a clear best practice, and easier to maintain because the codebase is not a web of things we deprecated and then never removed. We believe this change benefits everyone.
This is also similar to the deprecation policy of another time-based releasing project, Django (https://docs.djangoproject.com/en/1.8/internals/release-process/#internal-r…), where releases are every 9 months and code is *always* removed in Release where deprecated + 2, giving them a deprecation grace period of up to 1 and a half years.
If you have any opinions on this change, please let me know, and we'll take it all into account before changing the policy.
Amber "Hawkie" Brown
Twisted Release Manager
A couple of days ago I asked on Stack Overflow about returning a deferred
from an SNI callback and have pyOpenSSL wait for it to fire before
continuing handling the request.
Thanks to some pointers by Gyph I've found a solution ("workaround") for my
problem, involving a fake TLSMemoryBIOProtocol to handle the client hello
until the SNI is received, firing the SNI callback, waiting for it to
callback and then re-feeding the resulting context to the real
The implementation of this solution is available at
https://gist.github.com/GaretJax/124c523a62ba48c9eec1, and I'd like to
contribute it back to Twisted, however, it has no unit tests and needs some
I've opened a ticket to track it at
https://twistedmatrix.com/trac/ticket/8065. Real-life impediments
permitting, I'm willing to work on it and get the feature supported in
Anyone willing to help me getting a proper patch?
P.S.: A big shout-out to Twisted for its excellent TLS support out of the
box. We got a straight A rating out of the box on ssl labs!
A few months ago, the question of an official process for obtaining commit access was raised.
The discussion lead to this proposal - https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath>. I like that proposal, but it is still incomplete: to wit, it defines a template for how roles might be defined but does not actually define any roles. It also seems to be a bit overly ambitious, just from the observed reaction of nobody having the time to implement it :).
So I have a proposal for a scaled back process that nevertheless would give us something official-ish:
Not all committers are actively involved in the project at all times, so we should form a "committer committee" of people who are interested in evaluating candidates. If you would like to do that and you're already a committer, please contact me and I'll add you to the list. I want to do this so there's somewhere to apply to which isn't just a public mailing list or discussion, since public discussions can create social pressure to grant someone commit just to be nice, and rejections might be perceived as mean.
Candidates should submit an application to this new list, commit(a)twistedmatrix.com <mailto:email@example.com> which is a list of links to at least 10 tickets, at least 5 of which are patches they've submitted, and at least 5 of which are code reviews they've done which have been accepted by a committer. At least 2 of their authored patches should have gone all the way through the process to be landed.
As with the other parts of our process, if there is at least one sponsor, and no objections from anyone on the committee within 7 days, any member of the committee may add the committer.
New committers should then be announced on the mailing list.
This is not really an ideal process - particularly, it lacks a good way to give contributors something specific and useful to do - but it's something at least. If there is general assent that this is an improvement, I'll go make a wiki page and a mailing list.
This message is based on https://twistedmatrix.com/trac/ticket/5911#comment:14
In twisted/web/http.py we have the addCookie method which has the
In the current code, the max_age is used as just anything which can be
converted into a text.
cookie = cookie +"; Max-Age=%s" % max_age
The latest patch documents max_age as requiring an int and adds tests
for the addCookie method... so to handly Py3 support the code looks
cookie = cookie + b"; Max-Age=" + intToBytes(max_age)
Should this code continue to handle str/int/long ?
Is there a way to deprecate a single argument from a method/function?
Since max_age does not comply with the coding convention, can we
deprecated max_age with support for str/int/log and create a new
maxAge argument which only supports bytes.