python-trio/general

Discussion of Trio, a friendly Python library for async concurrency and I/O

Quentin Pradet

@pquentin

Kwargs*

Alex Grönholm

@agronholm

@pquentin I fixed the style issues in that PR, so you can go ahead and approve/merge

but, maybe adding py3.11 to the matrix might be prudent?

Alex Grönholm

@agronholm

not yet; even with this change, the test suite won't pass on 3.11

although the rest of the failures seem to be caused by the test suite, not so much trio itself

Alex Grönholm

@agronholm

fantastic – tests won't pass on 3.11 because cffi segfaults

Alex Grönholm

@agronholm

@pquentin I'm gonna merge python-trio/trio#2270 if you don't object

Alex Grönholm

@agronholm

and another trivial 3.11 fix PR: python-trio/trio#2318

Quentin Pradet

@pquentin

Thanks! Merged

Alex Grönholm

@agronholm

does trio really need a testing matrix as massive as it currently has? I mean, there's 3.8-dev, 3.9-dev, 3.10-dev too?

Quentin Pradet

@pquentin

I see the 3.x-dev jobs as a courtesy to the CPython developers as they allow catching bugs before releases - they don't really help us, no

Marcelo Trylesinski

@Kludex

In that sense, if that "extra" runs only on master or daily, it would have the same effect?

Quentin Pradet

@pquentin

yes, at the cost of added complexity - I've approved the PR that removes them, I don't think they actually helped in the past. Using the latest dev provides most of the value

Alex Grönholm

@agronholm

I am having some local difficulties with cryptography because it links to libffi.so.6 which my system does not have (it has libffi.so.8 instead)

Alex Grönholm

@agronholm

ok, trio's test suite now passes on py3.11 on master

Quentin Pradet

@pquentin

Thank you!

this is worth releasing so that projects that depend on us can start their own 3.11 preparations

but I'm seeing movement on the multierror front and would like to get that in too :)

Alex Grönholm

@agronholm

indeed

unfortunately I get a segfault in the pytest collection phase locally

not in CI though

that obnoxious test_checkpoints test is constantly failing on windows/py310

Quentin Pradet

@pquentin

yeah...

we knew it at merge time but still went for it

didn't get much traction on python-trio/trio#2158 :)

Alex Grönholm

@agronholm

yeah I found that myself

I'm just gonna go ahead and merge it

anyio had these mysterious flaky tls tests for a while but I managed to fix the flakiness

Alex Grönholm

@agronholm

the sphinx and jinja2 PRs may require both to be merged at the same time

Quentin Pradet

@pquentin

Sphinx has been broken for some time now, it's not only the jinja2 stuff

Sphinx 5.0 is also around the corner with more breaking changes

Alex Grönholm

@agronholm

@oremanj do you suppose you have time to review my changes in #2213 this week?

Joshua Oreman

@oremanj

@agronholm yes I'll take a look tonight!

Alex Grönholm

@agronholm

:thumbsup:

graingert

@graingert:matrix.org

[m]

Is there a reason to use os.pipe() when you can use socket.socketpair and shutdown the ends you don't need? socket.socketpair appears to work consistently across the unixverse and windows

Joshua Oreman

@oremanj

@graingert:matrix.org for most purposes a socketpair works fine. pipes do support some pipe-specific operations that won't work on a socket though, e.g. splice() syscall, F_GETPIPE_SZ ioctl., etc

so it is not strictly a drop-in replacement

graingert

@graingert:matrix.org

[m]

Ah this is for distributed.process.AsyncProcess

So I just want readability in one direction (to detect the parent's death) and a single message in the other (to send a pickled exception)

Joshua Oreman

@oremanj

yes that sounds like a fine use case for a socketpair! and easier than two pipes for sure

graingert

@graingert:matrix.org

[m]

Currently it's two multiprocessing.Queues two os.pipes() and a multiprocessing.Pipe

On Linux

(that's when it's run by the distributed.Nanny)

And a bunch of Daemon threads (in addition to the threads used in multiprocessing.Queue)

graingert

@graingert:matrix.org

[m]

If someone (another thread) does a fork between

parent, child = subprocess.socketpair()
try:
    p = multiprocessing.get_context("spawn").Process(target=functools.partial(target, child=child)
    p.start()
finally:
    child.close()

That forked process takes a copy of the child fd and that's just "you used a thread with a fork and that's the deadlock we warned you about"?

graingert

@graingert:matrix.org

[m]

I also assume KI has the same issue? And the answer is to not issue KeyboardInterrupt between attribute lookups and method calls?

richardsheridan

@richardsheridan:matrix.org

[m]

Wow asyncprocess is a big hairy ball of threads and weakrefs

Maybe necessary complexity but hard to look at after carefully avoiding threads for so long

Dave Hirschfeld

@dhirschfeld

There's an interesting discussion about using trio over in dask/distributed#6201 which people here may be interested in

lord_fomo

@goodboy:matrix.org

[m]

Nice

Where communities thrive

People

Repo info

Activity