Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ipaddress module, questions, improvements #182

Open
sausix opened this issue Jun 14, 2024 · 3 comments
Open

ipaddress module, questions, improvements #182

sausix opened this issue Jun 14, 2024 · 3 comments

Comments

@sausix
Copy link

sausix commented Jun 14, 2024

I'm curious why you did not use or even extend the standard ipaddress module.
It has some cool features too. You could do great magic! For example creating a MulticastIPAddress automatically.

Technically a pure IP address has no port information. So an IP address with port should instead of "IPv4" be named Endpoint, IPv4Endpoint or similar.

An address with subnet length should also represent a specific class. Speaking of subnet masks, the most difficult and helpful feature would be calculating subnets. First, last address, etc.

But storing an IP address, a subnet length and a port in one object feels odd. Where's the use case? Where do ports and subnet lengths meet? Interface configurations don't have ports. And when you use ports you don't care for the subnet.
Except let me call it SubnetService and I'm thinking of a DHCP server listening on a specific port. But then you should consider multiple ports.

I would not ask these questions if this project was pure Python learning. I made silly or unuseful stuff too. Just for fun and for learning. I barely complete my projects until today. But your project is already on PyPI so it should be solid in a way.

Don't get me wrong. Don't want to criticise you. Your OOP implementation is quite good and I did not find any obvious bugs.

@Diapolo10
Copy link
Owner

The short answer is; I just made this for fun, with no real use-case in mind (aside from a certain game project, but the development there has stalled anyway).

Basically I was taking a university course on networking and I wanted to play around with the concepts and rules as they were taught, so I began to write some Python code to do just that. Over time it kind of snowballed as I started to use the project as a testing ground for other things, like GitHub Actions scripts, publishing on PyPI, tooling, and even project structure.

As it stands the project simply lacks drive and direction. I don't know where I want to take it, or how I'd like to refactor it. Although even if I did my PC is currently a complete mess with all dev tools broken and I'm basically waiting to replace the whole thing... it's just taking a while.

@sausix
Copy link
Author

sausix commented Jun 18, 2024

I have similar projects. 99% chance of learning a lot. 1% chance to be a ready to use project.

This project has potential being "the" project all about IP addresses including their subnet calculations. You already have a good understanding of OOP. Keep going improving and create useful classes all around IP handling :-)

@Diapolo10
Copy link
Owner

I'm not opposed to it, and I'll likely rework parts of it at some point at least (IIRC there was some stuff related to inheritance that should probably be fixed), but what's really needed is some kind of a roadmap for the project. And probably some helping hands.

The project's structure was originally heavily inspired by the built-in pathlib. There were "pathlib.PurePath"-equivalent versions of each IP version type, too, but over time I figured that added complexity didn't really give any tangible benefit so I reworked things, but it's not really perfect yet. I really should've written more notes as over time I've forgotten a lot of the specifics, that's entirely on me.

I wanted to make this thing really flexible, even allowing less strict validation as I wanted to make a game similar to Hacknet and it had a few special servers like 1337.1337.1337.1337 which wouldn't actually be a valid IP in reality, but I wanted iplib3 to at least technically support something like that - which it does, probably unlike anything else similar out there. Not that it was hard to implement or anything.

If you feel like planning a roadmap, you've got free reign to make a suggestion. Then I might work towards that if both parties agree it's a good plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants