Polynomial real root finder (First real python project)
Posted by MoatazProAtAll@reddit | Python | View on Reddit | 20 comments
https://github.com/MizoWNA/Polynomial-root-finder
What My Project Does
Hello! I wanted to show off my first actual python project, a simple polynomial root finder using Sturms's theorem, bisection method, and newton's method. A lot of it is very basic code, but I thought it was worth sharing nonetheless.
Target Audience
It's meant to be just a basic playground to test out what I've been learning, updated every so often since I dont actually major in any CS related degrees.
Comparison
As to how it compares to everything else in its field? It doesn't.
turkoid@reddit
Before I get into my criticisms, I want to say you should not be discouraged by mine or anyone else's. You seem to be learning and to your own admission, this is your first git project. Everyone had to start somewhere.
First thing I noticed is you included your pycache as well as your vscode settings for this project. As a general rule of thumb, you should only include files that are required for your code to run. You can include resource files that may be needed. The only time an IDE settings file should be included really is when you're working on a team, and you want consistent settings, but even this is pretty rare IMO.
Your folder and file name scheme. Technically, it's not against any specific rule to use mixedCase like you did, but all modern python projects using lower_case_with_underscores for python files/packages. Also, is "Helper Tools" a package? Or just a folder for some random python files. If it's a package that you want to import from, always include a
__init__.pyfile.Function names - same thing about not using mixedCase.
It's good you're getting into the habit of typehints, but you didn't include return ones. Not having typehints is not going to break anything, but it was weird to not fully commit to it.
Variable/Argument names. I see a lot of single letter variables, as well as a couple single letter uppercase ones. So again using lower_case_with_underscores for naming. Classes use CamelCase. Also, I would recommend using longer descriptive variable names. Single letter variables make it hard to look back on the code and figure out what you did (even if you commented the hell out of it).
You make extensive use of doing shallow copies of lists using
[:]. There is nothing wrong with this, except I feel you did it because you are modifying the list when you pass it to other functions. IMO, this is just waiting for bugs to be introduced. Unless memory is a concern, it's usually best practice to keep some measure of immutability when passing arguments. So in your case, you create a new list in the calling function and return that. If your function is editing the list in place, that needs to documented or the function named so anyone else using it can infer what it does.All right, now the following suggestion is not truly needed, but you really should be in habit of doing this regardless of how small your project is:
Use some kind of virtual environment. I'd recommend using
uvit's fast and simple, but using the built in onevenvis just as good. Technically speaking if your project uses no external packages, this is not needed, but IMO it's always smart to start in a virtual environment so that other projects to interfere with others.Sorry for the long post.
MoatazProAtAll@reddit (OP)
Wow! Thank you so much for all your tips. You raise some very intersting points that I'll keep in mind for future projects.
Can you please explain to me why i shouldn't use wildcard imports and what exactly a virtual enviroment does/used for?
Thanks again!
kw_96@reddit
Imagine
“from utils import func; from otherlib import func2; func()” compared to
“from utils import ; from otherlib import ; func()”
The first option gives better clarity on where func originated from. IMO an even better option for most cases would be “import utils; utils.func()”. You trade off having additional verbosity for clarity, which unless your module has lots of sub-modules, I think is ok.
Virtual environments give you a “fresh slate” to install only libraries that you need for this project. It improves reproducibility (you test on a fresh environment, using only libraries you specify), and compartmentalization/organizing when you work on multiple projects.
billsil@reddit
The improved reproducibility is exactly why I don’t use virtual environments. It should work on a range of versions. If I test on the oldest available version and the new version and actually fix my tests/warnings, my code will be pretty robust.
turkoid@reddit
I couldn't disagree with this more. What happens when you do hit a regression? What if it's an external library that causes it?
If you are only doing pure python, technically yes you don't need to, but that's because Python versioning guarantees that there will be breaking changes between versions in the same minor branch. Python has stated that they will try and avoid major breaking changes like they did with version 2 to 3, but that is not guaranteed.
billsil@reddit
You run your tests daily right? What happens is I support new versions incrementally instead of having to migrate 10 releases in one go. Just because you test against something doesn’t mean you have to use it in production. It doesn’t mean other packages don’t have limitations on supporting the latest version of some dependency. It means you already dealt with your bottleneck.
Python versioning does not guarantee there will not be breaking changes. That is highly package dependent. Python doesn’t even follow semantic versioning and even doing that doesn’t mean things functionally changed. A package like setuptools is on 80.9.0. A year ago it was on 72.2.0. Other packages have different definitions of breaking.
turkoid@reddit
Well, you seem to be differentiating dev vs prod environments. Yes, in a dev environment you can be more lax with package requirements, etc. When you run tests, I'm assuming you create virtual environments or VMs to ensure clean testing environments and use version locking? For prod I would never just say
install package-latest. For a dev env, I probably would and make sure it passes all its tests using the locked version.However, It still would be beneficial to use venv in your dev as if you need to reset a corrupt environment, you can easily do it. You're telling me you clear out your global Python environment if you need to start clean? That sounds extremely inefficient.
For personal projects or small packages, you have the benefit of be able to updating frequently. Even companies with fast turnaround times don't update willy-nilly. Enterprise, big companies, are obviously even slower and are usually 3+ major releases behind and usually only update for CVE reasons.
Lastly, yes Python does not follow semver, but they try to stick with it, with a few exceptions. From their own site
Personally, I think it's bad advice to say virtual environments shouldn't be used. It is very minimal overhead to give you more assurances that different projects don't conflict with each other.
MoatazProAtAll@reddit (OP)
Thanks for your answer! Also happy cake day!
marr75@reddit
I'll go a step further: You shouldn't import classes, functions, or variables from modules. Import the module and use the classes and functions with a dot (
.) attribute access.There are several important benefits:
kick_off_process_that_costs_5_dollarsto run automatically. If you dofrom big_library import kick_off_process_that_costs_5_dollarsall over the place, you have a lot of work to do to mock/patch that (you have to do it in every bit of consuming code). If you ALWAYS opt forimport big_library; big_library.kick_off_process_that_costs_5_dollarsyou can always mock/patch one place.MoatazProAtAll@reddit (OP)
Thats a very good point you make about the 5dollarsomething, since I keep hearing from all the programming subs about people overspending with AWS accidentally, so that may be a related concept?
Ill keep all your points in mind for any future hobby projects I work on!
turkoid@reddit
The biggest reason is unintended import collisions. If you import everything from one package and then import a single thing from one, and it has the same name, or vice versa, you could be using the wrong one.
The next reason is just better for diffs (git), so you or anyone else can quickly see if a new import was added/removed.
In very rare cases, you'll see someone do a wildcard import for a common library that will likely never change. IMO, this is still bad practice. Either alias the library to use it as a prefix, or import each thing you need line by line. The first option is a nice trade-off between wildcard imports and importing each item, as it doesn't suffer from the big disadvantage i mentioned earlier (namespace collision). For example
import some_ui_lib as ui, then you access each item asui.somethingandui.something_else.In the simplest terms, it's a self-contained environment to run your code in. This is not to be confused with a virtual machine, which technically does the same, but on a way larger scale and partitions system resources.
As I said before, when you use pure python, no external imports, there really is no need to use it. However, say you are working on a project
Project Onethat requirespackage a. Well, if youpip installthat puts it into global python environment. If you have another projectProject Twothat imports it, you don't have topip installas it's already available.Technically, this is still fine. However, now let's say
Project 2needs a newer version ofpackage athat either has a new feature or fixes a bug. You update the package, but nowProject 1is using this updated package. Again, this is fine if there are no breaking changes. What if the package does alter somethingProject Oneuses and causes it to break, or worse not break, but return wrong results?Project OneandProject Tworequire 2 different versions of the same package.This is where virtual environments save the day. When you install a package in one virtual environment, it's isolated from any others. This gives you assurance that your project will run exactly the same no matter out, which makes testing reliable. Also, usually there is a file that you include in your repo that lets others just use that to install all external packages needed, in their own virtual environment.
For more info, I highly recommend researching on your own about them. I might get flamed for this, but I would use AI tools to give you a jumpstart on this and all other questions you have. I've been a software dev for about 25 years now, and I think it's an invaluable tool. Don't just copy its produced code or trust its answers fully. I like to think of it as another person to bounce ideas off of. Then I do my own research into why it suggested it.
MoatazProAtAll@reddit (OP)
I see! So virtual environments when I dont want my versions to have problems with each other, which trust me, is a problem Im very used to when using Linux!
From what I understand, my use of wildcard imports isn't THAT bad since im just using it to separate my functions into "categories" but its still bad practice, especially when im importing libraries that arent of my own creation.
I cant thank you enough for all your tips and explanations, But thanks anyways for taking the time to explain everything to me!
Fenzik@reddit
Great review!
ectomancer@reddit
Lightweight, Pure Python, no imports, well done.
MoatazProAtAll@reddit (OP)
I wasn't too sure about return type hints, mostly because im not FULLY sure how theyre written or how theyre handeled if i change the data type of the variable inside the function, but i guess doing that would be stupid anyways.
Thanks for your comment!
forthepeople2028@reddit
Don’t import * either import the functions you need or import the file and use file.some_function()
MoatazProAtAll@reddit (OP)
I'll keep that in mind!
marr75@reddit
You gitignored your tests but source control your pyc files. That's an... unusual combination.
Are you looking for a review or additional resources?
MoatazProAtAll@reddit (OP)
Ah anything really!
There are no tests, just an empty py file, and left my pyc files in because why the hell not. Its also my first time using git ever so, i was still figuring stuff out.
commy2@reddit
You should delete them, commit, then add __pycache__ to .gitignore and commit again.