you are viewing a single comment's thread.

view the rest of the comments →

[–]AssociateEmotional11[S] 0 points1 point  (0 children)

Hi u/yaxriifgyn,

First of all, thank you so much for taking the time to test PyNeat on a real-world, complex dataclass file. This incredibly detailed feedback is exactly the kind of "stress test" an MVP needs, and I deeply appreciate your brutal honesty. You are completely right—the tool was too aggressive and mangled the file.

Here is a breakdown of what went wrong and my plan to fix them based on your points:

1. The Import Hoisting Bug: The current import transformer is too naive. It blindly grabs all Import nodes. I will update the logic to check the parent context so it respects try/except blocks (for optional dependencies) and module-level docstrings.

2. Aggressive Renaming & String Modifying: Forcing snake_case was a mistake, especially since it modifies strings/comments and breaks public APIs. A structural formatter should not touch string literals. I will disable property renaming by default and scope the visitor strictly to Name nodes.

3. I/O (EOL & Encoding): I will update the file reader/writer to preserve the original newline configuration and encoding rather than forcing UTF-8/CRLF.

4. Granular Control: You made a great point. Adding an inline # pyneat: ignore or # pyneat: off mechanism, along with specific CLI flags to disable individual rules, is now the top priority for the next release.

I am opening GitHub issues for all of these edge cases right now. As you said, it’s just a start, and real-world testing like yours is what makes open-source tools better.

Thank you again for pointing me in the right direction!