Ideas for breaking changes

[niklasf]

Changes to consider when the opportunity arises.

• chess.svg.board(..., flipped) -> chess.svg.board(..., orientation)
• Remove chess.pgn.BaseVisitor.parse_san()

[PedanticHacker]

(1) Niklas, why do you want to rename the flipped argument name of chess.svg.board() to orientation? 🤔 If you think of renaming it, you can do it right now. Make it as a 1.x breaking change. Everyone have not upgraded to 1.x yet, so the opportunity is basically right now. Version 1.0.2 can introduce this. The changelog should explain this and people will adapt. And there's only one simple name to change, not a hassle at all.

(2) Do you want to remove parse_san() abstract method of the BaseVisitor() abstract base class altogether, or just remove return board.parse_san(san) and make it pass instead?

[PedanticHacker]

Here's an idea of a breaking change: since the introduction of passing a dictionary as the colors argument to chess.svg.board(), we can now remove the style argument in there. Thoughts?

[niklasf]

Good point about style. And no, I will not sneak breaking changes into minor releases. This is just a list of things to consider in the future.

[niklasf]

• Remove chess.engine.PovWdl bc for Tuple[int, int, int].

[PedanticHacker]

• Remove flipped and style parameters of chess.svg.board().

[niklasf]

• Distinguish PGN root and child nodes for typing. (possible with bc)

[khink]

Not sure if i should post here, but here goes:

I'm looking at what is needed to create an interface/engine for a 5x5 board. Am i correct in assuming this would be a major, breaking change in this module? Looking at the constants like SQUARES, FILE_NAMES, RANK_NAMES, and also the various variants, this is not easily changed in the current situation, right?

The reason i'm asking is that i saw the mini chess app which uses a 5x5 board. I was hoping to play it on my computer in some way. Having looked at a YouTube video where someone coded a chess engine+interface from the ground up, i was inspired but also realized that there are many projects out there, and i was hoping to re-use / contribute whenever possible.

Edit:

I've toyed around a bit in https://github.com/khink/flexboard-chess. In many ways, python-chess is very mature and flexible. I would love to be able to use it for this. Main thing would be to store the dimensions somewhere.

(I've kind of gone around python-chess's solution by creating a Square class that is not a simple int, but has an is_last_of_rank attribute. That should be done differently, by storing nr_of_ranks and nr_of_files on the Board, i think.)

Apart from that and the constants mentioned above, the 8x8 is also internalized in methods like _set_board_fen (c in ["1", "2", "3", "4", "5", "6", "7", "8"], this range could be as long as the board is wide). But all that is do-able to change, i think.

[niklasf]

Hi, I tried mini chess a while back and it's definitely fun. For this particular library I would consider it out of scope, with so many places using bitboards with 64 squares it would complicate everything significantly.

[niklasf]

• Status.IMPOSSIBLE_MATERIAL, merging the various individual reasons but also more pedantically counting promoted pieces.

[niklasf]

• More flexible SVG rendering. Composable layers?

[niklasf]

• Remove max_fds from Syzygy. File descriptors can be closed after creating memory maps. (not possible, see 12c6211)

[niklasf]

• Positional only arguments