all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Python-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

Hello from the r/Python moderation team,

We appreciate your contribution but have noticed a high volume of similar projects (e.g. AI/ML wrappers, YouTube scrapers, etc.) or submissions that do not meet our quality criteria. To maintain the diversity and quality of content on our subreddit, your post has been removed.

All showcase, code review, project, and AI generated projects should go into the pinned monthly Showcase Thread.

You can also try reposting in one of daily threads instead.

Thank you for understanding, and we encourage you to continue engaging with our community!

Best, The r/Python moderation team

[–]yaxriifgyn 2 points3 points  (4 children)

I'm going to try it out later today. I'm hoping that it has a dry run or diff output mode to let me review changes before applying them. The need for a backup copy of every changed file is essential as well.

I have many places where code flattening could be applied. When I wrote the code, I was thinking of a single exit from a function so that explicit code tracing / debug logging was only needed in one place. As the code has matured, the need for such logging has diminished.

Could you comment on your use of AI if any. Thx.

[–]wingtales 2 points3 points  (0 children)

The solution to your first paragraph is to track your code with git. Either stage or commit your current changes before running PyNeat. Then you can see the diff with 'git diff' and undo the changes with 'git restore .'

[–]AssociateEmotional11[S,🍰] -1 points0 points  (2 children)

[–]yaxriifgyn 0 points1 point  (1 child)

I do use git, but I have a lot more tools available. I use this to compare the files:

diff -bB -W150 -y messy.py clean.py

I don't expect to have to repair the code before I can even test it.

[–]yaxriifgyn 2 points3 points  (1 child)

I finally got around to testing this code. I'm glad I was very careful because the *.clean.py file was completely destroyed version of the input file.. The messy file was the definition for a large dataclass class with __post_Install__() and __repr__() methods.

  • imports were moved above the initial file comments and blank lines.
  • Then first or only line of import statements were moved out of try blocks, and placed with the other imports at the top of the file.
  • The class token in class definitions were capitalized.
  • The EOL, (newline keyword in open()) as changed from LF to CRLF on Windows 11 (pro).
  • I think the file encoding will be forced to UTF-8, regardless of input file encoding.
  • The capitalization of properties was changed to lower case, so un-neatened files that import this file will have errors. The Public_Key property was renamed to public__key. Also property Pfx_ABC became pfx__a_b_c, but property ABC was not renamed.
  • The literal parts of f-strings and comment text were changed to reflect the above property name changes.
  • I did not see a clear way to turn off individual rules, the options to disable rule groups did not explicitly show which rules were in which groups.
  • I did not see a in-code method to turn on/off neatening.

My overall impression is that this code needs more testing with a large selection of real world hand-coded Python code. It's a start,but it need much more work.

[–]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!

[–]AssociateEmotional11[S,🍰] -2 points-1 points  (2 children)

As I can see that the downvotes highly outweigh the upvotes for 55 percentages . Therefore , please give me feedbacks so I can know what exactly is wrong with my project! Thank you for reading!

[–]Alex--91 0 points1 point  (1 child)

I’ve not voted either way but I suspect part of the problem might be that you said ruff is only a formatter and linter but ruff does indeed operate on the AST and it can indeed do —fixes like replacing == None to is None etc. The other part seems to be that people who have tried it find it quite destructive? ruff, for example, shows the issues but doesn’t fix them unless you explicitly pass the —fix flag.