#twisted

Tickets pending review: https://tm.tl/#5406 (MostAwesomeDude), #9305, #9333 (markrwilliams), #9337, #9210 (markrwilliams), #9390, #7705, #9398, #9399, #9118 (the0id), #4964 (jameshilliard), #9138, #9176

markrwilliams submitted <https://tm.tl/#9343>; - Add a ensureBytes() helper function (assigned to rodrigc) for review

Tickets pending review: https://tm.tl/#5406 (MostAwesomeDude), #9305, #9333 (markrwilliams), #9337, #9210 (markrwilliams), #9390, #7705, #9398, #9399, #9118 (the0id), #4964 (jameshilliard), #9138, #9176

new core enhancement https://tm.tl/#9400 by markrwilliams: Request.getRequestHostname should fail explicitly on non-TCP transports

Tickets pending review: https://tm.tl/#5406 (MostAwesomeDude), #9305, #9333 (markrwilliams), #9337, #9210 (markrwilliams), #9390, #7705, #9398, #9399, #9118 (the0id), #4964 (jameshilliard), #9138, #9176

Tickets pending review: https://tm.tl/#5406 (MostAwesomeDude), #9305, #9333 (markrwilliams), #9337, #9210 (markrwilliams), #9390, #7705, #9398, #9399, #9118 (the0id), #4964 (jameshilliard), #9138, #9176

hi, i'd like to call a blocking method but don't need any return values so would like to return to the caller immediately. how would i do that?

call the method and move on. let that method do its thing.

rajesh: you can use http://twistedmatrix.com/documents/current/api/...

EACFreddy: thought about it. is there any other way/

reactor.callInThread maybe, but I never used that before

EACFreddy: i'll use deferToThread. thanks.

rajesh: what does the blocking method do?

teratorn: makes a request to another service.

rajesh: why is it blocking, then?

it's another service provider whose api i call. there can be many requests to that provider lining up on my side. so i'd like to trigger them as i enqueue them, and i don't care about the results of the operations on their end.

deferToThread may not be sufficient for that

why not?

a) if your API library is not thread-safe you don't have control over it being used from a single thread b) it's not going to queue them up one-by-one if that is what you need

just having your own dedicated thread and a queue might be better?

teratorn: yes of course, a separate queue and a thread per request to the other service.

i imagine i only need manage the append/pop of the queue elements.

shouldn't be too hard... twisted isn't magic, it's just python code

yeah, no i don't have a problem with that.

is anyone else seeing this?: travis-ci OS-X builds of a project that depends upon twisted are failing as they try to install "incremental>=16.10.1", claiming "Couldn't find index page for 'incremental' (maybe misspelled?)"

the travis linux builds are fine, a local OS-X build is fine

and the build appears to be able to find other dependencies without problems, so I'm not convinced it's related to the TLS<=1.2 brownouts that PyPI is running in preparation for disabling older TLS entirely in a week or two

Tickets pending review: https://tm.tl/#5406 (MostAwesomeDude), #9305, #9333 (markrwilliams), #9337, #9210 (markrwilliams), #9390, #7705, #9398, #9399, #9118 (the0id), #4964 (jameshilliard), #9138, #9176

'brownouts', that an interesting way to handle deprecation for SaaS stuff :)

yeah. I kinda like it, although apparently some versions of pip don't report the error in the most helpful manner

i guess better "some" bug-reports from users rather than all of a sudden a bunch can't make anything work

(i kinda like it too :)

warner: it's not documented well, but in addition to the official brownout ("all requests during this time period will fail"), there's also a probabilistic brownout happening ("x% of requests will fail randomly"), so it could potentially be that

warner: certainly if you're on MacOS and you don't have either the very latest pip (9.0.3) or the very latest MacOS (10.13), you need to upgrade one or the other

njs: does Travis say what MacOS version they're running?

meejah: probably somewhere, but I don't know off the top of my head

their docs say 10.12.6

there's one beta image available that has 10.13, but all the rest are 10.12 or older

but it looks like we've got pip-9.0.3

one build just passed, so it's not consistent

(I suppose one way to figure out if it's the brownout or not is to just wait two weeks :)

is there any "all requests that start with the letter 'i' will fail" aspect?

warner: you should probably ask in #pypa-dev, they're pretty on top of this stuff right now for obvious reasons :-)

I can't figure out why it fails when it gets to Incremental, but appears to get good responses up until just a moment earlier, on multiple builds

good point, thanks