Niklas Fiekas

Fixed via #1100. Targetting [one final 1.x release](https://github.com/niklasf/python-chess/milestone/5) before making the jump to 2.x.

Maintaining an additional stack like that has significant runtime overhead for everyone who doesn't need it. But a custom wrapper could always provide both in sync. Something along the lines...

This is mostly Stockfish and derivates, right? Maybe not standardized enough to add to the API, but your snippet makes for a good example of custom engine communication. Then again,...

Hi, some thoughts about these: * (1), (2), (3): Sure, if the new code would be more readable. For (2), the code was ported line by line from a C...

Thanks for reporting. The spec vaguely implies that `info` is meant to be sent during search, but I don't think it's clearly stated. So I guess this should be allowed...

Hi, it's definitely something to consider. The existing modules `chess.pgn`, `chess.polyglot`, `chess.gaviota`, `chess.syzygy`, `chess.engine`, `chess.svg` all benefit significantly from sharing types like `chess.Move` and `chess.Board`. `TRF` on the other hand...

Hi. It's currently not really possible (except by subclassing [`chess.pgn.StringExporter`](https://github.com/niklasf/python-chess/blob/8628abbb65386f6622cf38d519209e123a654b8b/chess/pgn.py#L1366)), but I think it makes sense to add. By the way, which PGN viewer has this requirement?

I think this looks good. I wonder if it's acceptable to just change `__str__`, or if that would be considered a breaking change.

> One question is, how do you see `board.mirror()` affecting things? `board.mirror()` should not need special consideration. It's not to be confused with changing the orientation of looking at the...

Sorry to reject this. In the current design, `chess.Board` instances should carry no more information than is required to describe the position and its history (in particular no orientation and...