oremanj/tricycle

Experimental extensions to Trio, the friendly Python async I/O library

tricycle's Issues

TrioDeprecationWarning

Hello Joshua,

I would like to ask for your help.

I would be a pleasure if you could release a new version without using trio.hazmat as currently my terminal is full of warning msgs.

I really appreciate your help.

Thanks in advance!

trio-typing is really a heay dependency to install

tricycle 0.2.1 Experiemntal extensions for Trio, the friendly async I/O library
├── trio >=0.15.0
│   ├── async-generator >=1.9
│   ├── attrs >=19.2.0
│   ├── cffi >=1.14
│   │   └── pycparser *
│   ├── idna *
│   ├── outcome *
│   │   └── attrs >=19.2.0 (circular dependency aborted here)
│   ├── sniffio *
│   └── sortedcontainers *
└── trio-typing >=0.5.0
    ├── mypy >=0.780
    │   ├── mypy-extensions >=0.4.3,<0.5.0
    │   ├── typed-ast >=1.4.0,<1.5.0
    │   └── typing-extensions >=3.7.4
    ├── mypy-extensions >=0.4.2 (circular dependency aborted here)
    ├── trio >=0.16.0
    │   ├── async-generator >=1.9
    │   ├── attrs >=19.2.0
    │   ├── cffi >=1.14
    │   │   └── pycparser *
    │   ├── idna *
    │   ├── outcome *
    │   │   └── attrs >=19.2.0 (circular dependency aborted here)
    │   ├── sniffio *
    │   └── sortedcontainers *
    └── typing-extensions >=3.7.4 (circular dependency aborted here)

I have searched trio_typing, and only found one use that in _service_nursery.py.

So should trio_typing be a test-env dependency?

Support TextReceiveStream(..., strip_newlines=True)

Hello oremanj,

I would like to ask for your kind help.

I use your tricycle library in one of my project with great pealsure. 👍

import trio
import tricycle


async def main():
    async with await trio.open_tcp_stream("192.168.0.1", 23) as tcp_stream:  # type: trio.SocketStream
        msg_stream = tricycle.TextReceiveStream(tcp_stream, "utf-8", newline="\r\n")
        async for msg in msg_stream:
            print(msg)


trio.run(main)

I only have a subtle issue, as you can see the new line character is "\r\n" and every message contains this character as well. What I mean is that msg == "#5G9803880F ###*071 RL30217638 *=\r\n". So currently I have to use msg.strip() method.
I think that there is no use leaving control characters in the messages themself.
And it would be super awesome to have messages without new line characters out-of-box. 😃

But off course it is up to you, I just would like to know your opinion about it.

Btw, I find very helpful the your discussion about of graceful shutdown.

Thanks for your help in advance.

edge case of read_biased setter: intended behavior?

I'm implementing a layer of a database, and I'm thinking about relying on a specific corner case of the read_biased setter. In this situation, the DB is going to flush a bunch of cached writes to disk, but I want to allow readers to view the cached data during that time, while simultaneously have writers queue up on the lock so the cache doesn't mutate during the flush.

Specific code if interested

class SomeCustomDB:
    lock = tricycle.RWLock()

    ...

    @contextlib.asynccontextmanager
    async def write_tx(self):
        async with self.lock.write_locked():
            self.lock.read_biased = False
            token = self.checkpoint()
            try:
                yield
            except BaseException as e:
                self.restore(token)
                raise e
            finally:
                # need opportunity to flush even after rollback
                # previous chained writes may have modified the cache
                if self.lock.statistics().writers_waiting == 0:
                    self.lock.read_biased = True
                    with trio.CancelScope(shield=True):
                        await self.aflush()
                else:
                    await trio.lowlevel.cancel_shielded_checkpoint()

I thought that setting self.lock.read_biased = True while holding the write lock would just change the behavior after the lock is dropped, but it has the effect of calling _wake_all_readers, meaning a bunch of readers think they've aquired the lock and start running. But any new readers during the flush will block when acquiring the lock, because _writer is not None so acquire_nowait would raise WouldBlock.

This is all a bit weird, but it happens to be exactly what I want. I could possibly achieve my goal by dropping the lock, setting read_biased = True outside the lock, and re-acquiring it for read to do my flush, so I'm good either way, but I wanted to point out this edge case in the event you wanted to either canonize it or fix it.