Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed thePSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username onbugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please followthe steps outlined in the CPython devguide to rectify this issue.

You cancheck yourself to see if the CLA has been received.

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

Don't forget CLA@alanyee

@eamanu I have signed it, though it says that it will take a business day for it to show up online. I am willing to review the code on my own, slowly transforming the code to convention. I don't think such an effort will bother other efforts.

@eamanu:

IMHO this PR does not represent an improve on cpython (sorrr). I think will be complicated
review whole the code on cpython to follow the conventions.

@alanyee:

I am willing to review the code on my own, slowly transforming the code to convention. I don't think such an effort will bother other efforts.

By reviewing the code, I believe@eamanu was referring to the review process which has to be done by core developers before the PR can be merged. It might take a bit of time for them to get around to fully reviewing this PR, but having a proper docstring and formatting for anything in the public API does provide some value. Using the correct formatting (as opposed to an inline comment above the object's definition) allows for the usage ofobject.__doc__ to view the docstring.

Agreed with@eamanu . In general convention only changes are not merged but it would be good if new code follows the convention. This also causes git blame to be less useful. Also I am not sure of using code comments as docstrings since the tone seems to vary.

@tirkarthi:

In general convention only changes are not merged but it would be good if new code follows the convention.

Also I am not sure of using code comments as docstrings since the tone seems to vary.

Good point. It would be significantly more helpful to work on converting some of the existing older code comments into appropriate docstrings which provide a succinct summary of the object's purpose. As the docstrings are created, the appropriate formatting could be applied. However, this would have to be done across multiple PRs (one for each object preferably) rather than an entire file at once.

Edit: For clarification, this is not suggesting the current PR wouldn't be a valid change, just that creating dedicated docstrings would be especially helpful rather than just directly using the existing comments as docstrings.

IMHO this PR does not represent an improve on cpython (sorrr). I think will be complicated
review whole the code on cpython to follow the conventions.

Sorry if I don't explain correctly. I mean that for example (just an example) try to fix the pep8 into the aprox 7000 files on cpython project can be complicated. Thinking about this well, it would be great for new contributor, isn't? A good opportunity to learn the workflow on cpython project. :-)

Thinking about this well, it would be great for new contributor, isn't? A good opportunity to learn the workflow on cpython project. :-)

Those were my thoughts as well.

Very frequently, we've merged fairly minor documentation related changes into CPython that provided new contributors with a valuable experience. Take a look at my first merged PR as an example:#14069. Although it fixed the grammar in the section, it could have definitely been passed up as an overly trivial change that ultimately provided minimal benefit to readers of the documentation.

It's important that we allow new contributors especially to make these types of PRs, in order to gain experience working within the workflow. They serve as a fantastic learning experience, not only for working within CPython, but also for contributing to open source in general. This can help significantly with increasing the number of active contributors in the long term and improving the ecosystem as a whole.

Normally I would avoid ccing Guido directly, but since he's the only active author of PEP 257, I think his feedback would be especially valuable here. The other author, David Goodger, is not a member of the Python GitHub organization or active on GitHub as far as I can tell (https://github.com/goodger).

/cc@gvanrossum

Let's not do this. Conforming to a formatting standard is not enough reason to change existing code that works just fine -- it's perfectly readable as it is.

@gvanrossum

Let's not do this. Conforming to a formatting standard is not enough reason to change existing code that works just fine -- it's perfectly readable as it is.

I can understand not conforming to the formatting standard, but one thing of important note that I just realized was thatFTP.__init__ is missing a docstring (the PEP explicitly specified any public__init__ should have one). Could the author potentially open a new PR to just add a docstring forFTP.__init__ (without all of the other formatting changes)?

That would be much easier to review and provide more of a benefit than just changing the formatting.

Edit: For quick reference, it's on line 106.

Sure. You can also reopen this PR and the OP can submit an update -- up to you two.

@gvanrossum

Sure. You can also reopen this PR and the OP can submit an update -- up to you two.

Thanks! Especially since this is the author's first PR to any@python repository, I wanted to give them a chance to provide a meaningful contribution. I'll wait on@alanyee to decide what they want to do since it's their PR, either way works me.

I am open to reopening this PR and making the requested changes.

Great!

Sorry, I can't merge this PR. Reason:Base branch was modified. Review and try the merge again..

Thanks@alanyee for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

I'm having trouble backporting to3.8. Reason: 'Error 110 while writing to socket. Connection timed out.'. Please retry by removing and re-adding theneeds backport to 3.8 label.

Thanks for persevering! This will be backported to 3.8.