Georg Brandl comments

Results 206 comments of


                                            Georg Brandl

Support for implementing a separate `connect` method

I guess once Client is Sync it is not a problem anymore to get rid of the lifetime...

Tree doesn't include subsections for `self` in toctree

TBH, I don't know anymore :)

() to empty tuple conversion is confusing

FWIW, I agree with Armin. None kind of plays two roles in Python, which are covered by None:: and () in Rust, while the empty Python tuple is seen rarely,...

() to empty tuple conversion is confusing

> For me storing () somewhere does not make a lot of sense, because it does not have a meaningful value (beyond type system trickery). And the same is true...

Problem with default sys.stdout.encoding producing UnicodeEncodeError

Can you show some code or details where the string comes from and what you do with it? In particular, is there stdin/stdout or files involved? Normal string conversions between...

Problem with default sys.stdout.encoding producing UnicodeEncodeError

The Rust string is not involved here, neither is Rust's string encoding. You get the same exception from this: ``` py.eval("print('ß')", None, None).unwrap(); ``` or even by importing a second...

Problem with default sys.stdout.encoding producing UnicodeEncodeError

> I think this is not entirely correct. Rust Strings and &strs are UTF-8 encoded [0]. The raw, byte representation (UTF-8 encoded) is then directly handed over to the Python...

Problem with default sys.stdout.encoding producing UnicodeEncodeError

HOWEVER: I just realized that with `LANG=C` (or `LANG=bogus`) there are two different outcomes in the interpreter and a PyO3 generated executable with embedded Python: Python defaults to UTF-8 stdout...

Problem with default sys.stdout.encoding producing UnicodeEncodeError

I'm not sure that we should switch from not matching `python` in one way to doing it in another way :) The least surprising behavior would be to match the...

Automatically implement Python getters and setters for public Rust struct fields

Why does it have to be this implicit? A single new attribute or argument (on the struct, not the members) isn't too much to write, and makes it explicit that...