NYT 2022-05-01 crashes about xword-dl HOT 4 CLOSED

from xword-dl.

Thanks for reporting! I was able to repro this and figure out the issues.

That third prong of the conditional set is for rebus answers, and the .puz file requires a single letter in the solution spot. The double slice thing (square[0][0]) grabs the first letter of the first acceptable rebus answer provided.

In this case, and this puzzle's tech was kind of a fiasco, the first acceptable option provided is an empty string. There isn't a public spec that these are built to, so they're not strictly in violation of anything by doing that, but it didn't work well with solvers (and the .puz format doesn't let you use an empty string in that slot anyway.)

The fix for this would be to check whether the first provided acceptable answer is an empty string and if so... provide an X instead of its first character? Or move onto the second string? (In this case, the second acceptable answer was the string NOTHING so this would somewhat confusingly jam N into the solution.)

I'm inclined to say that this is enough of an edge scenario that we shouldn't overfit to it with a special case. But if you have thoughts I'd be happy to hear them!

from xword-dl.

from xword-dl.

The LAT issue should be fixed by the latest release, which you can upgrade through pip or this repo, whichever you've previously done. (The new version with the fix will be 2022.5.21.) In that case it's not a weird gimmick, but a change in how they're read into the online solver.

I'm closing this issue but feel free to open a new one or be in touch if you run into any problems!

from xword-dl.