Mailman 3 March 2019 - Twisted

[Twisted-Python] Buildbot downtime
by Tom Prince 03 Mar '22

03 Mar '22

I am plannig to upgrade twisted's buildbot in the near future. In preperation for that, I am going to take down the production buildbot on Tuesday, June 26, around 1600 UTC[1]. During that time, the result of any builds done will be lost. Thus, I'd ask that people avoid committing to trunk during that time. I will send a reminder before I take down the buildbot both here, and on #twisted and #twisted-dev. Tom [1] http://timeanddate.com/worldclock/meetingtime.html?iso=20120626&p1=80&p2=22…

2 8

[Twisted-Python] Twisted Python 0.7.0 Prerelease Testing
by Glyph Lefkowitz 05 Aug '21

05 Aug '21

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. Thanks. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/

4 5

[Twisted-Python] Real Viagra Professional - for real sex pros
by Tamika 01 May '19

01 May '19

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <center> <a href="http://rqf.entercompassion.com"><img src="http://mediapix.ru/pics/685207b3dd437eff7f15c0744b5c1d3a.gif"> <title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="stylesheet" href="http://gfx8.nnt.com/mail/12.0.1187.0824/positioning.css" /> </head> <body style="overflow:auto;"> <div id="PrintShellToolbar"> <div class="ContainerPadding"> <span class="FloatRight"> <a href= > <img alt="" src="http://gfx1.nfi.com/mail/w2/pr02/ltr/glyph_close_rest.gif" /> <Close window> <a href= > <img alt="" src="http://gfx2.czb.com/mail/w2/pr02/ltr/i_print.gif" /> <Print> </a> </span> </div> </div> <div> <div class="BorderContainerOutline ContainerPadding"> <div class="ClearBoth"> <span class="HeaderData" style="font-size:large;"> <TuPostal.com Cambia de nombre?> </span> </div> <div class="ClearBoth"> <span class="HeaderLabel"> <From:> </span> <span class="HeaderData"> <b><TuPostal.com></b> </span> </div> <div class="ClearBoth"> <span class="HeaderLabel"> <Sent:> </span> <span class="HeaderData"> <div class="ClearBoth"> <span class="HeaderLabel"> To: </span> <span class="HeaderData"> Mikelelliott (mikelelliott(a)rlo.com) </span> </div> <br /> </div> </div> <div class="MessageBody" style=""> <br /> <div id="MessageBodyText" class="ExternalClass" style="border: 1px solid #fff ;"> <pre>Hola!<br> <br>Tupostal es ahora parte de Sonico!<br> <br>Para conocer nuestro nuevo sitio, haz clic en el siguiente link:<br><a href='http://www.gwpcom/index1.php' target='_blank'>http://www.bjncom/index1.php</a><br> <br>Sonico es un sitio donde puedes...<br>- Guardar fotos ilimitadas<br>- Re encontrarte con viejos amigos<br>- Recibir novedades de tus amigos.<br> <br>Te Esperamos! Ya somos mas de 21 millones de usuarios!!<br> <br>Sonico - Amigos Conectados<br> <br> <br>PD: Ahora tambien podras guardar tus postales<br> <br> <br>------------------------------------------<br>Haz recibido este email porque te encuentras registrado en fdm.com.<br>Si no deseas recibir mas mensajes como este, por favor haz clic en el siguiente link:<br><a href='http://www.cehcom/unsubscribe.php?type=2' target='_blank'>http://www.fyocom/unsubscribe.php?type=2</a><br> <br></pre> </div> </div> </div> </body> </html>

8 10

[Twisted-Python] txsni + alpn + acme (letsencrypt)
by Daniel Holth 23 Apr '19

23 Apr '19

Hello. Can you help me to learn to debug tls problems in twisted? I was disappointed that txacme, an automatic way to get certificates for twisted web, stopped working, so I'm trying to add a responder for the new challenge type. It sends a special certificate if the CA negotiates acme using alpn, proving domain control, then you get a certificate. Seems to work with openssl s_client but letsencrypt says "no application protocol". Anyone know where that error comes from? https://github.com/glyph/txsni/pull/26

2 14

[Twisted-Python] Twisted 19.2.0rc2 Release Candidate Announcement
by Amber Brown 04 Apr '19

04 Apr '19

Hello everyone! 19.2.0rc2 is now out. Sorry for the delay! This fixes the Cryptography dependency being set to 1.5, when we actually require at least 2.5. You can get the tarball and the NEWS file at https://twistedmatrix.com/Releases/rc/19.2.0rc2/ , or you can try it out from PyPI: python -m pip install Twisted==19.2.0rc2 Please test it, and let me know how your applications fare, good or bad! If nothing comes up, 19.2 will release in a week. Twisted regards, Amber Brown (hawkowl)

4 3

[Twisted-Python] A Proposal for reducing the burden of developing on Twisted by dropping Python 2 support
by Amber Brown 02 Apr '19

02 Apr '19

Hi everyone, Since the Python 2 EOL date is rapidly approaching, I thought it was time we consider dropping Python 2 support. I personally find that Python 2 compat adds a huge amount of overhead when working on and maintaining Twisted, and think that with the current maintainer availability, dropping it sooner rather than later would have a beneficial effect on how much work we spend on shims/compat, complexity, and our ability to ship new features, as well as onboarding people who are interested in the project, but have no interest (or experience!) in Python 2.7. It is basically summed up by doing a feature freeze on an agreed-upon version of Twisted, that will be the last version released for 2.7. It would be abnormal in that it would get security fixes (our current policy is to only release them for current versions) and critical bugfixes, but would otherwise be frozen. One of my rationales is that from some analysis of PyPI download statistics, the vast majority of Python 2 users are using old versions of Twisted, while nearly all our Python 3 users are on the latest version. As such, I believe freezing a version that will get security updates but no new features would not be a massive loss to those stuck on Python 2 for whatever reason. Twisted's compatibility policy would still apply, ensuring that Python 2/3 compatible software using Twisted would be able to use the older Twisted version on Python 2, and the newer version on Python 3, as you would usually expect. You can find the proposal here, in this handy-dandy Google Doc: https://docs.google.com/document/d/1S4CGgZC09blLIdk3Zo7wBa75A9_JuuH_3akkyjN… Comments are welcome, as well as which timeline seems reasonable. - Amber

11 13

[Twisted-Python] stop/start client connections with loseConnection in ReconnectingClientFactory
by Chris Satterthwaite 02 Apr '19

02 Apr '19

Hello community, First of all - thanks for an awesome platform! I'm brand new to this community, but have been using Twisted a couple years. Reason for posting: I've hit a condition with ReconnectingClientFactory that I'm not sure is per design. I have a work around right now, but need your perspective. Seems like there should be a better/right way to do this. Attempted design: I'd like to have long running TCP clients (forever until stopped), with a long running TCP server. When a long running client hits a problem with a dependency (database is down, kafka bus unavailable, external API not responding, etc), I want the client to go offline for a while and then come back online. an automated, self-recovery type action. Since it's not ok to start/stop/restart the Twisted Reactor, I am letting the client finish whatever it can do, disconnect from the service, destruct the dependencies, wait for a period of time, and then attempt a clean re-initialization of those dependencies along with reconnecting to the Twisted Server. Problem case: I'm using the ReconnectingClientFactory in my client. When the client hits a problem, it calls transport.loseConnection(). But whenever the client calls this, after the disconnect - it does not reconnect; stopFactory is called and everything exits. Work around: I noticed some Twisted source code that works off factory.numPorts. If numPorts is 1 and the client loses the connection, it goes to 0 and calls the cleanup. So I conditionally increase this number right before intentionally disconnecting, and then reset that after reconnecting. This solves the problem, but it's a hack. I'll attach the test scripts to this post (if attachments are allowed), but the main code is with these functions in the factory: def clientConnectionLost(self, connector, reason): print(' factory clientConnectionLost: reason: {}'.format(reason)) # if self.disconnectedOnPurpose: # ## Hack to keep reactor alive # print(' factory clientConnectionLost: increasing numPorts') # self.numPorts += 1 # self.numPortsChanged = True # self.disconnectedOnPurpose = False print(' ... simulate client going idle before attempting restart...') time.sleep(5) ReconnectingClientFactory.clientConnectionLost(self, connector, reason) print(' factory clientConnectionLost: end.\n') def clientConnectionMade(self): print(' factory clientConnectionMade: starting numPorts: {}'.format(self.numPorts)) # if self.numPortsChanged : # ## Resetting from hacked value # print(' factory clientConnectionMade: decreasing numPorts') # self.numPorts -= 1 # self.numPortsChanged = False print(' factory clientConnectionMade: finished numPorts: {}'.format(self.numPorts)) def cleanup(self): print('factory cleanup: calling loseConnection') if self.connectedClient is not None: self.connectedClient.transport.loseConnection() self.disconnectedOnPurpose = True With the above lines commented out, once the cleanup call does transport.loseConnection(), the factory stops at the end of clientConnectionLost. Sample scripts/logs: I've tried to create short test scripts and corresponding logs (with the client failing, and then with it restarting when I use the workaround). I've cut out several thousand lines to get down to something simple for the example test scripts, but I know the client is still a little long. Again, I'm not sure if attachments work on the mailing list, but I'll attempt to attach the client/server scripts with the corresponding pass/fail logs. Thanks! -Chris

6 12

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com 31 Mar '19

31 Mar '19

1 0

[Twisted-Python] Drop support for Python 3.4?
by Craig Rodrigues 29 Mar '19

29 Mar '19

What do people think of dropping Twisted support for Python 3.4? According to https://devguide.python.org/#status-of-python-branches Python 3.4 EOL'd on March 19, 2019. In the Python 3 world, we have Python 3.4, 3.5, 3.6, 3.7, and at the end of this year we will have Python 3.8. That's quite a lot of Python versions to support. Python 3.5 introduced async/await keywords, which are very relevant to Twisted: https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-pep-492 If it makes sense, it would be nice to use these keywords as first-level features in Twisted. Since Amber brought up discussion of dropping Python 2.7 here: https://twistedmatrix.com/pipermail/twisted-python/2019-March/032234.html I thought I would raise dropping Python 3.4 also. -- Craig

6 5

Re: [Twisted-Python] A Proposal for reducing the burden of developing on Twisted by dropping Python 2 support (Craig Rodrigues)
by Julian Berman 27 Mar '19

27 Mar '19

Hi! Figured it might be helpful to just throw in the other viewpoint (that I'd hold). Which is -- I use a Python 2.7 [PyPy] not end of lifing in 2020 (or in the forseeable future -- and one by the way I'd wholeheartedly have recommended more of us use even before now :). At work, we develop even new applications on it, and likely will not have any plans to move anything really until at least a year or two, until PyPy3 matures and until we have time to do extensive benchmarking showing it isn't slower than PyPy2. So my personal opinion would be obviously "drop Py2 support immediately" -- nope kidding, just making sure you're still reading -- it's "keep it forever and we all suffer, hooray". I don't contribute to Twisted as much as I'd like (or should), and I fully recognize the huge efforts of others who hey shouldn't do free work just on my behalf -- but, in case it's valuable, FWIW dropping Py2 support would make me *less* likely to contribute :), since I couldn't rely on being able to use my own contributions -- perhaps though a decent solution to this side of things is for twisted to continue to pursue being more modular than it is today (i.e. break it up). -J On Wed, Mar 27, 2019 at 4:45 AM <twisted-python-request(a)twistedmatrix.com> wrote: > Send Twisted-Python mailing list submissions to > twisted-python(a)twistedmatrix.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > or, via email, send a message with subject or body 'help' to > twisted-python-request(a)twistedmatrix.com > > You can reach the person managing the list at > twisted-python-owner(a)twistedmatrix.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Twisted-Python digest..." > Today's Topics: > > 1. Re: A Proposal for reducing the burden of developing on > Twisted by dropping Python 2 support (Craig Rodrigues) > 2. Drop support for Python 3.4? (Craig Rodrigues) > 3. Re: Drop support for Python 3.4? (Glyph) > 4. Re: A Proposal for reducing the burden of developing on > Twisted by dropping Python 2 support (Adi Roiban) > > > > ---------- Forwarded message ---------- > From: Craig Rodrigues <rodrigc(a)crodrigues.org> > To: Twisted general discussion <twisted-python(a)twistedmatrix.com> > Cc: > Bcc: > Date: Tue, 26 Mar 2019 19:35:58 -0700 > Subject: Re: [Twisted-Python] A Proposal for reducing the burden of > developing on Twisted by dropping Python 2 support > > > On Mon, Mar 25, 2019 at 3:15 AM Amber Brown <hawkowl(a)atleastfornow.net> > wrote: > >> >> >> >> You can find the proposal here, in this handy-dandy Google Doc: >> >> https://docs.google.com/document/d/1S4CGgZC09blLIdk3Zo7wBa75A9_JuuH_3akkyjN… >> >> >> > Thanks for writing that doc. > I think option 3 of making Twisted 19.4 the last Python 2 release, with > security updates until 2021 is > actually pretty reasonable. > > -- > Craig > > > > ---------- Forwarded message ---------- > From: Craig Rodrigues <rodrigc(a)crodrigues.org> > To: Twisted general discussion <twisted-python(a)twistedmatrix.com> > Cc: > Bcc: > Date: Tue, 26 Mar 2019 19:59:01 -0700 > Subject: [Twisted-Python] Drop support for Python 3.4? > What do people think of dropping Twisted support for Python 3.4? > > According to https://devguide.python.org/#status-of-python-branches > > Python 3.4 EOL'd on March 19, 2019. > > In the Python 3 world, we have Python 3.4, 3.5, 3.6, 3.7, and at > the end of this year we will have Python 3.8. > > That's quite a lot of Python versions to support. > > Python 3.5 introduced async/await keywords, which are very relevant to > Twisted: > https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-pep-492 > > If it makes sense, it would be nice to use these keywords as first-level > features in Twisted. > > Since Amber brought up discussion of dropping Python 2.7 here: > https://twistedmatrix.com/pipermail/twisted-python/2019-March/032234.html > > I thought I would raise dropping Python 3.4 also. > -- > Craig > > > > ---------- Forwarded message ---------- > From: Glyph <glyph(a)twistedmatrix.com> > To: Twisted general discussion <twisted-python(a)twistedmatrix.com> > Cc: > Bcc: > Date: Tue, 26 Mar 2019 22:04:17 -0700 > Subject: Re: [Twisted-Python] Drop support for Python 3.4? > > > On Mar 26, 2019, at 7:59 PM, Craig Rodrigues <rodrigc(a)crodrigues.org> > wrote: > > What do people think of dropping Twisted support for Python 3.4? > > According to https://devguide.python.org/#status-of-python-branches > > Python 3.4 EOL'd on March 19, 2019. > > In the Python 3 world, we have Python 3.4, 3.5, 3.6, 3.7, and at > the end of this year we will have Python 3.8. > > That's quite a lot of Python versions to support. > > Python 3.5 introduced async/await keywords, which are very relevant to > Twisted: > https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-pep-492 > > If it makes sense, it would be nice to use these keywords as first-level > features in Twisted. > > Since Amber brought up discussion of dropping Python 2.7 here: > https://twistedmatrix.com/pipermail/twisted-python/2019-March/032234.html > > I thought I would raise dropping Python 3.4 also. > > > I'll let any 3.4 users speak for themselves if they're out there, but > while I can imagine a host of reasons we might want to still support 2.7, I > can't think of any that we'd want to hang on to 3.4 any longer than > necessary. 3.5 still has the lingering benefit of a production(-ish) pypy, > so we might not want to jump to 3.6-only anyway, but if it's unsupported by > python core, let's get rid of it. Faster round trips through CI are reason > enough :-). > > -g > > > > > ---------- Forwarded message ---------- > From: Adi Roiban <adi(a)roiban.ro> > To: Twisted general discussion <twisted-python(a)twistedmatrix.com> > Cc: > Bcc: > Date: Wed, 27 Mar 2019 08:45:13 +0000 > Subject: Re: [Twisted-Python] A Proposal for reducing the burden of > developing on Twisted by dropping Python 2 support > On Tue, 26 Mar 2019 at 04:52, Glyph <glyph(a)twistedmatrix.com> wrote: > > > > On Mar 25, 2019, at 3:15 AM, Amber Brown <hawkowl(a)atleastfornow.net> > wrote: > > > > > > Hi everyone, > > > > Since the Python 2 EOL date is rapidly approaching, I thought it was > time we consider dropping Python 2 support. > > > > I personally find that Python 2 compat adds a huge amount of overhead > when working on and maintaining Twisted, and think that with the current > maintainer availability, dropping it sooner rather than later would have a > beneficial effect on how much work we spend on shims/compat, complexity, > and our ability to ship new features, as well as onboarding people who are > interested in the project, but have no interest (or experience!) in Python > 2.7. > > > > > > Personally, I don't have this problem, but I'm certainly willing to > believe it's a bigger deal for others; especially others who perhaps have > not even learned Python 2 at this point. > > I am still using python 2.7 on all my projects, and I remember the > sending patches supporting python 3 was an extra effort... I had to > learn python 3 things, and then search for ways / workaround to > implement something in a py2 + py3 way... read six documentation. > > I guess that many Twisted developers don't have too much free time, > this can add up. > > For me learning py3 was ok as at some point I will use it...but I > guess that for people who will never use py2 is just unwanted work. > > > > > > > Here's my question about this: > > > > Who will do this work? > > > > Personally, I'm not willing to commit to this. I know from experience > both on Twisted and other projects that maintaining multiple release > branches, even one that's "maintenance only", requires at least one > point-person for each branch at all times (usually a "release manager"). > And backporting fixes inevitably gets harder and harder as the > "maintenance" branch diverges from top-of-tree. If I have time to work on > Twisted in my increasingly scarce spare time, I want it to be on something > at least plausibly interesting, and manually backporting manual fixes to an > unmaintained py2 branch that I don't even use doesn't qualify. > > > [SNIP] > > > > Do we have py2-only users who are willing to take ownership of this > branch? Specific people willing to sign up for this responsibility for the > next... how long? Three years? Five years? > > > > > I can help with backporting security fixed for the next 5 years, as I > will use it. > > I am still using 15.5 due to lack of python cryptography on all > systems, and I have a fork for twisted.web with support for resources > which can add custom `Expect: 100-continue` behaviour. > > I am doing backporting and as long as there is a CI, is not that hard. > > I hope there will be at least another person to help reviewing the > backports. > > > So I'd rather be quite explicit that while we would not object to anyone > filling these roles, someone still needs to step forward and fill them, and > I'm not willing to commit the current team, such as it is, to work that I > myself am unwilling to do. If nobody does step forward we should not claim > to have security support for a dead / unmaintained branch. > > Well.. this is free/libre software so I guess that nobody will be sued > if we commit to something, and later we found out that this can't be > done. > > > One of my rationales is that from some analysis of PyPI download > statistics, the vast majority of Python 2 users are using old versions of > Twisted, while nearly all our Python 3 users are on the latest version. As > such, I believe freezing a version that will get security updates but no > new features would not be a massive loss to those stuck on Python 2 for > whatever reason. > > > > > > I know that you detailed some of this on IRC, but: how old? > > > > My sense would be that of course users stuck on py2 would have a more > conservative upgrade cadence than py3 users, but that doesn't mean they > never upgrade. How far behind are these py2 users, and does the curve > suggest they're catching up or are most twisted downloads just like, > version 1.3 on python 1.5.2 forever? > > > > >From my experience the upgrade is between 5 to 10 years. > But the upgrade is done only because the system will be obsolete. > Old version run in private networks, without Internet access with > nobody willing to touch a working system. > > PCI don't help. So far, they have only asked for TLS1.2 and removal of > CBC Mode ciphers in SSH...and that is all. > They have never complained about old OpenSSH or OpenSSL versions... > and when you have custom old software, the PCI auditor have no clue. > > I know more than 3 big companies which still have not upgraded to TLS > 1.2 even with all the PCI audits...they always get extensions and > workarounds. > > > Twisted's compatibility policy would still apply, ensuring that Python > 2/3 compatible software using Twisted would be able to use the older > Twisted version on Python 2, and the newer version on Python 3, as you > would usually expect. > > > > > > We have 2 big blockers here right now that would prevent doing this as > things stand right now: > > > > Twisted is not yet fully ported to Python 3, so there's no version where > you can use all of Twisted on Python 3. This picture is way, way smaller > than it has ever been, though - grab a module and start porting: > http://blog.habnab.it/twisted-depgraph/ > > We still have Python 2 in production ourselves that requires Twisted; > specifically: > > > > Trac and several of our ancillary utilities around it. Happily this > does seem to be fairly actively worked on: "opened 4 years ago, last > modified 12 days ago" https://trac.edgewall.org/ticket/12130 > > Do we really need Trac? > Maybe is time to move the tickets and wiki to GitHub. > > > Dogfood DNS: twisted.names doesn't work on python 3: > https://twistedmatrix.com/trac/ticket/9496 > > I have never used Twisted.names in production. > I tried to help with the review of twisted.names patches, and I > remember there was not much interest for twisted.names > So maybe we can get rid of it and move it to a separate project. > > I don't think that we need to have everything in twisted core... if > ldaptor is an external project, why we can't have twisted.names > > > > Our front-end webserver might work on pypy3, but we have yet to move it > over. Maybe that would be a good place to start? > > > > > > If this proposal lights a fire under some folks to drive any of these > projects to completion, that would be great! > > My hope is that this proposal will light a fire and people using > Twisted will more about Twisted. > > I feel that Twisted stability and reduce number of defects is not > helping the open source dev model. > People will use Twisted, it just work and they forget about it. > Or if it doesn't work, they can fix something on their project > relatively easy...but takes a lot of effort to send upstream..so they > will never put the effort required to have a fix upstream. > > > You can find the proposal here, in this handy-dandy Google Doc: > https://docs.google.com/document/d/1S4CGgZC09blLIdk3Zo7wBa75A9_JuuH_3akkyjN… > > > > Comments are welcome, as well as which timeline seems reasonable. > > > > > > Personally I feel like Option 1 is the most reasonable. We can't do > option 3 because of the above blockers, and option 2 just seems random to > me - why commit to 4 months of additional maintenance beyond when py2 > itself is EOL? Maybe there's an option like, 1.5, where we de-support py2 > at max(2020-01-01, "the date at which we no longer have any py2 code in > production ourselves")? > > If we keep the current prod infrastructure, I am not confident that we > will no longer have py2 code in prod by the end of this year. > > I don't feel that the current Twisted team have resource to maintain a > custom infrastructure. > I think that things will be better for everyone if for example of > Twisted names we will just use the credit on Azure to keep the DNS and > use more Software as a Service so that the team will spend more time > on developing new feature than doing sysadmin work. > > Dogfooding is a good thing, but in this case, I fell that it does not help. > > -- > Adi Roiban > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >

1 0