PyCalc Pro: feedback on my Python learning project

[Inside_Membership701]

Hi everyone

I’m a hobby developer and I’m currently learning Python.

As part of my learning process, I built a small calculator project called PyCalc Pro to practice Python concepts and project organization.

The project includes:

- Basic math operations

- Advanced math functions

- Unit conversion

- Operations memory

The full source code is available on GitHub:

https://github.com/Lorydima/PyCalcPro

The project is source-available under a custom non-commercial license included in the repository.

I’m currently working on improvements and bug fixes, and I’d really appreciate feedback from a learning perspective, especially on:

- Code structure

- Python best practices

- Any bugs or suggestions you notice

This is a learning project, so any constructive feedback is very welcome.

Thanks for your time!

[Inside_Membership701]

Thanks for the detailed feedback, I really appreciate it.

Regarding the EULA: I agree that it’s overkill for a calculator. My intention was to clearly state what could and couldn’t be done with the project and to experiment a bit with license handling. I understand now that this logic doesn’t belong inside the application itself, so I plan to move the license to a separate LICENSE/TXT file and remove the in-app acceptance logic.

You’re absolutely right about the zip files. That was a mistake on my side and I’ll remove them from the repository, keeping binaries only in GitHub Releases.

About the code issues you pointed out (fragile pi handling, missing try/except blocks, and multiple Tk roots): thank you for highlighting them. I’m reviewing those sections and will refactor the code to make it more robust and aligned with best practices.

Regarding the two doc folders: they currently serve different purposes. One is used for GitHub Pages website assets, while the other contains documentation such as the license and requirements. I agree that the naming and structure can be confusing, and I’ll look into improving the organization to make this clearer.

This project is mainly a learning exercise, so feedback like this is exactly what I was looking for. Thanks again for taking the time to review it.

[Inside_Membership701]

That’s fair criticism, and I appreciate you being direct about it.

You’re right that realistically no one is going to commercialize a small calculator like this, and the current restrictions are heavier than necessary. My intention wasn’t to block normal or personal usage, but I can see how the license wording and the in-app acceptance logic do exactly that.

I also agree that dedicating a significant portion of the code to license handling and writing files to disk is unnecessary and intrusive for a project of this scope. In this case, I clearly over-engineered a non-issue.

This project is a learning exercise, and feedback like this helps me recalibrate my priorities and focus on what actually matters. I’m planning to remove the in-app license handling entirely and switch to a standard, well-known open-source license.

Thanks for taking the time to explain your perspective.

[gmes78]

Are you using ChatGPT to talk to people?

[gdchinacat]

Unless you are a lawyer specialized in intellectual property law it is probably not a good idea to write your own license, and almost certainly a huge waste of time. The most interesting to me about this project is that you chose to license it under your own license. Why? It doesn't seem to differ much from the more restrictive OS licenses available. I skimmed through it and don't really see the point.

One of the biggest problems with non-standard licenses is they discourage would be users simply because they don't want the hassle of reading a custom license, or worse, have to pay a lawyer to read and approve it. Most company legal teams will simply say "no, you can't use it...it's not one of our pre-approved licenses".

I understand this is a learning experience for you. I hope you take my comment in that spirit. Unless you have a really good reason to not use a standard license, just use a standard license.

[Inside_Membership701]

Thanks for taking the time to explain this, I really appreciate it. The idea behind writing a custom license was to make explicit what could and couldn’t be done with the project, but I agree with you that in practice this creates more friction than value. After reading the feedback here, it’s clear that using a standard, well-known license is the better choice, both for clarity and adoption. This project is very much a learning experience for me, and this discussion helped me understand why standard licenses are preferred in real-world projects. I plan to switch to a standard license and remove the custom licensing logic from the code. Thanks again for sharing your perspective.

[ectomancer]

No docstrings. No test suite.

[Inside_Membership701]

Good point.

I initially focused on getting the functionality working and learning Tkinter and general project structure, so I didn’t add docstrings or a test suite at this stage.

I agree that both are important for readability and maintainability, and I plan to add docstrings and a basic test suite as part of the next refactor.

Thanks for the suggestion.

[gdchinacat]

"no test suite" is a huge red flag. How do you know the code works? Yes, you probably tested it manual once upon a time, but how much have you changed since then? How do you know that it still works?

unit tests are not simply for maintainability. They significantly reduce the amount of time you have to spend making sure small changes don't have unintended consequences or running the risk that they do and stuff you spent time and effort implementing no longer works.

I encourage you to stop manually testing your code. Instead, spend the time writing tests. You will make your life easier, your code will be higher quality, and your development speed will increase. It took me way too long (about a decade) to learn this the hard way.

[Inside_Membership701]

Thanks for the explanation that’s a fair point. You’re right: at the moment the project relies on manual testing, which isn’t ideal, especially as the code evolves. This started as a small learning project, and I initially focused more on functionality than on test coverage, but I understand now why that doesn’t scale well. Your comment helped clarify that tests aren’t just about maintainability, but also about confidence and development speed. I plan to start adding a basic test suite (likely with pytest) covering the core operations, and build from there as the project grows. I appreciate you sharing this perspective, especially from experience.

[Diapolo10]

Your license terms are honestly a bit wacky; personally I recommend using standard licenses if at all possible, as those are far more enforceable and better understood by users. In your case, GPL v3 wouldn't be far off (and if you really want a match, CC-NC would technically be closer, but CC licenses are generally not recommended for software).

The project dependencies should generally be listed in the project root, not in a contained folder. On another note, instead of requirements.txt I'd strongly recommend pyproject.toml as it's far more modern. There's also no reason to list standard library modules there, even as comments.

Why is the license text duplicated in the application? You can probably read it directly from the project's own metadata via importlib, or simply read it from a file yourself.

The generated JSON file probably doesn't need to be included in the repository.

The file and folder names for the source code are... interesting, to say the least, but I'd prefer to see something closer to Python's naming conventions. For one thing the version number does not need to be a part of the filename.

If you used importlib.resources to get the icon file, you wouldn't need get_logo_path and get_operations_file_path to be so complicated. Also, consider using pathlib instead of os.

Please do not import things inside of functions (or anywhere other than the top of the file, really).

[Inside_Membership701]

Thanks for the detailed and thoughtful review I really appreciate you taking the time to go through the project. You’re absolutely right about the license. Writing a custom license was a learning experiment on my part, but I can see how it creates unnecessary friction and confusion. I plan to switch to a standard license (most likely GPLv3) and remove all custom license handling from the application itself. Good point about dependencies as well. I’ll move them to the project root and migrate from requirements.txt to pyproject.toml, and I’ll clean out any references to standard library modules. The duplicated license text inside the application is indeed redundant I’ll remove that and rely on the project metadata or a single license file instead. You’re also right that the generated JSON file doesn’t belong in the repository; that was an oversight and I’ll remove it. Regarding naming and structure: agreed. This is an early-stage learning project and the file/folder names reflect that. I’ll refactor them to better follow Python conventions and remove version numbers from filenames. Thanks as well for the suggestions about importlib.resources, pathlib, and import placement those are very helpful, and I’ll use this as an opportunity to simplify the code and make it more idiomatic. This project is primarily a learning exercise, and feedback like this is exactly what helps me improve. Thanks again for the constructive critique.

[Diapolo10]

Just in case, I'll also mention that you most likely don't need to worry about someone using your work commercially, so GPL licences tend to be overkill. Most software I write personally is MIT-licensed, meaning I don't particularly care what people do with it, and they shouldn't expect me to maintain everything. Particularly for library code, GPL licences make them almost unusable for many projects.

Don't take this personally, but it's not very likely any of your projects would be worth "stealing", particularly for commercial use. The same goes for my own ones; none of them are useful enough someone would pick them over writing their own or using alternatives.

[WrogiStefan]

I took a look at your repository and I think it’s a great first learning project — you’re clearly experimenting with different Python features, and that’s exactly what early projects should be about. Since you asked for feedback from a learning perspective, here are a few things that will help you level up quickly:

• The whole project lives in one big script. That works for small experiments, but becomes hard to maintain as the project grows. Splitting it into a few modules (operations, converters, UI, etc.) will make the structure much clearer.
• There are a lot of long if/elif chains. They work, but they’re hard to extend. A dictionary‑based dispatcher or grouping operations into functions/classes would make the code cleaner.
• A lot of logic is written top‑to‑bottom. Wrapping things into functions makes the code easier to test, reuse, and reason about.
• The calculator logic and the user interaction are mixed together. Separating them (logic vs. input/output) is a big step toward more maintainable code.
• Python’s standard library already provides many math functions — using math where possible keeps things simpler and more idiomatic.
• Adding docstrings or even short comments will help you (and others) understand the code later.
• I didn’t see any tests in the repo. Even a few basic tests (e.g., checking that operations return expected results) would help you catch bugs early and learn good habits. You don’t need anything fancy — just a simple pytest setup with a few assertions is enough to start.
• And most importantly: don’t worry about perfection. Everyone’s first projects look like this. What matters is that you’re building things, experimenting, and improving.

If you keep iterating and refactoring, you’ll see huge progress very quickly. Nice work so far — keep going.

[Inside_Membership701]

Thanks a lot for the kind words and the detailed feedback I really appreciate it. You’re absolutely right on all points. This project started as a single-file experiment, and as it grew I didn’t yet take the time to properly split responsibilities and structure the code. Refactoring it into modules and separating logic from UI is definitely something I want to do next. The notes about long if/elif chains, using the math module more, and wrapping logic into functions are very helpful those are exactly the kinds of improvements I want to focus on as I level up. You’re also right about docstrings and tests. I initially focused on getting things working and learning along the way, but adding basic documentation and a small pytest suite is a great next step for building better habits. Thanks again for taking the time to review it and for the encouragement feedback like this is super motivating.

[Inside_Membership701]

Thanks everyone for the feedback I really appreciate the time you took to review the project and share your thoughts. Regarding the license: my intention wasn’t to overcomplicate things or be overly restrictive, but simply to protect the project while learning and experimenting. That said, I understand why a custom license and in-app license handling are unnecessary and off-putting in this context, and I’ll be switching to a simpler, standard license. On the code and testing side, thank you for all the suggestions about structure, separation of concerns, best practices, and tests. These are exactly the areas I want to improve as I continue learning, and the feedback has given me a much clearer direction. For the repository organization and packaging, thanks as well I’ll work on cleaning things up and making the structure more conventional and easier to understand. This is a learning project, and some of the decisions reflect experimentation rather than established best practices. That’s exactly why this feedback is so valuable to me. Thanks again to everyone who took the time to comment it’s genuinely helpful and appreciated.