Comment on revision r5d974fcbe7d652a0c73d3d3fb796d3fcc5c2d38f in pychess
pyc...@googlecode.com
General Comment:
Can we no longer parse fan then?
The case where san and fan are most different is in pawn captures.
A tip: If we add the unicode header in the top of a file, we dont need
those u" strings.
For more information:
http://code.google.com/p/pychess/source/detail?r=5d974fcbe7d652a0c73d3d3fb796d3fcc5c2d38f
pyc...@googlecode.com
General Comment:
Have you ever seen any FAN games other than _printed_ periodicals/books?
I feel parsing FAN is rather theoretical use case, aren't you?
pyc...@googlecode.com
General Comment:
I guess on top of my mind the only use for parseFAN I can think of is unit
testing toFAN.
Hm, and perhaps if we create a loader for the chess diagrams that we are
currently only able to save.
pyc...@googlecode.com
General Comment:
Restored parseFAN, but without that strange pawn capture part. It's not a
valid notation IMO.
I can't exactly understand your tip about those u" strings, so feel free to
fix anything you like :)
pyc...@googlecode.com
General Comment:
which can be indicated by writing '# -*- coding: UTF-8 -*-' in the top of a
file. But u" is fine too.
I thought ♙xe4 would be valid fan, but I see most people never use the ♙
symbol, which is probably nicer. And given the reasons we have for
parseFAN, there is no need handling cases we don't create our self, so
that's all good.
pyc...@googlecode.com
General Comment:
The u" here is not needed just for typing these symbols, but for creating a
translation table (a mapping, in case for unicode strings). If I just use
uft-8 encoded strings (no u"") the translation table have to be a 256
length string, which can be created with string.maketrans(from, to), where
from and to have to be the same length string, but figurine letters are 1
wide and utf-8 encoded figurine simbols are 3 wide strings, so I don't now
how to create a usable translation table in this case. All-in-all I used
unicode, and seems it works.