Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@vegerot

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Notes:
I have signed the CLI, but the check yourself link says otherwise.

I did put an issue # in the title.

@vegerot

I have signed the CLI, but the check yourself link says otherwise.

It usually takes around 24-48 hours before the CLI status is updated on GitHub, I'd recommend periodically using the check yourself link to manually refresh the status.

If it's been more than 48 hours since you submitted the CLA, you can reach out to the PSF at either:

1. contributors@python.org
2. psf@python.org

@ericvsmith @remilapeyre thanks for reviewing my PR so in depth

@vegerot Please try to avoid force-pushing to the branch after opening the PR, as it messes with the reviews and makes it more difficult to look over the relevant commit history. See the devguide for details.

My bad. I will look over that now. I messed up my fast-forward and ended up with thousands of commits in this PR

My bad. I will look over that now. I messed up my fast-forward and ended up with thousands of commits in this PR

I've certainly done that before (when I first started contributing). My recommendation is to use git pull upstream master --ff-only for keeping the local master branch up to date, and using the following for updating PR branches that have local commits:

git checkout some-branch
git fetch upstream
git merge upstream/master
git push origin some-branch

See the git bootcamp section of the devguide for details.

@asvetlov mentioned taking a more generalized approach in the original bpo issue:

I mean if we implement something like PathLike [1] but for IP addresses to socket module and teach all socket APIs to accept IPLike objects along with str -- no asyncio change is required.

Andrew, do you still have the same thoughts on the issue, or should we consider a more simplified solution? I would certainly prefer something like an IPLike approach so we don't have to make changes in future and current asyncio APIs that accept IP addresses, but if that's going to be significantly far away, it may be worthwhile to consider the convenience benefits for just the high-level parts of asyncio (such as asyncio.start_server()).

@aeros
Looking through the dev guide, very helpful. I agree tackling this in a way that doesn't require changes to asyncio would be great. But as a one-line change, no reason we couldn't do both. But I would also be interested in working on another method too 🙂

Any update on this?

Closing as won't fix as discussed on issue.

Closing as won't fix as discussed on issue.

@kumaraditya303 Where is the issue?

Where is the issue?

#79200