BaseRequest: misleading name of has_body attribute

[ku3o]

Long story short

class BaseRequest has attribute has_body that has an unfortunate name as it checks if there are more bytes to read from its body. And when the body is read it changes its value to False. This fact is not obvious from attribute name neither documentation and it causes confusion and bugs.

Expected behavior

has_body should stay static over a lifetime of a request. Or the attribute name and a related documentation should be more specific about the fact that once a body of a request is read, the value has changed.

Actual behavior

has_body return False if a request has a body but was read by another method such as await request.json().

Steps to reproduce

Simple handler that shows this behavior.

async def handler(request):
    """Simple request handler."""
    #  Let's say request has a JSON body
    request.has_body  # This returns True
    body = await request.json()
    request.has_body  # This returns False

Your environment

Not an environment specific.

[asvetlov]

Oops. IIRC many ages ago the attribute behavior was exactly that its name means.
But now it's misleading, I agree.
We need deprecate the property and invite a brand new one with better name.
.can_read_body maybe?

[ku3o]

Is there a use case that validates the existence of .can_read_body attribute? I like the idea of .has_body which indicates that there is a body in a request. So maybe a solution is to fix the behavior?

[asvetlov]

Sorry, no. I like the name too but aiohttp is open source project.
We don't know all our users and their use cases.
The only safe way for reusing existing name with other semantics is deprecating it, waiting for a while, removing and resurrecting.
Otherwise we will break backward compatibility.
It's possible sometimes but I feel now is not the case.
Between every stage we should make several releases.
It takes more than year for the whole process.

For example I prefer resp.start() to resp.prepare() but .start() was used for non-coroutine. We deprecated the method in 2015 but removed this year. Maybe we will able to switch back next year with deprecating .prepare() but honestly I not sure if benefits worth it.

[asvetlov]

.can_read_body name is not used by our API and we could start switching from .has_body to .can_read_body.
And we free to make a new attribute with proper .has_body functionality but under different name.

[ku3o]

Agree. That actually makes sense and I didn't realize this when I proposed the behavior modification. In that case `.can_read_body` sounds to me as a proper attribute name for tue functionality. I will try to make a PR.

…

On Fri, 23 Jun 2017 at 17:27, Andrew Svetlov ***@***.***> wrote: .can_read_body name is not used by our API and we could start switching from .has_body to .can_read_body. And we free to make a new attribute with proper .has_body functionality but under different name. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2005 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF5ecLkAm28c6sZy0THXTSrFnHXIPe8lks5sG9lggaJpZM4ODbBx> .

[asvetlov]

Please do. Thank you.

[ghost]

Any thoughts on what to call the new attribute with proper .has_body functionality?
.body_present? .body_exists? .body_received?

[cecton]

Is there anything else for this issue or can we close it?

[asvetlov]

@cecton thank you for question.
Yes, the issue is done.
Fixed by #2169

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new