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

test_form.py: fix test_choose_submit_twice #228

Merged
merged 1 commit into from Aug 22, 2018

Conversation

hemberger
Copy link
Contributor

When a BeautifulSoup object is constructed from an html string,
it will standardize the html. In this case, since the input html
was just a raw <form>, it added <html> and <body> tags around it.

Since the Form ctor now demands that it is passed a <form> element,
we need to extract <form> from the object BeautifulSoup constructs
to pass to the Form ctor.


Side question: The sanity check on Form being passed a <form> is in principle a good one, since I have seen plenty of errors that resulted from passing something that wasn't (or didn't even contain) a form to the Form ctor. But is it too restrictive? Should we expect that passing a <html><body><form>...</form></body></html> to Form should work? And if so, could we allow such a thing without also letting people make more egregious mistakes?

When a BeautifulSoup object is constructed from an html string,
it will standardize the html. In this case, since the input html
was just a raw <form>, it added <html> and <body> tags around it.

Since the `Form` ctor now demands that it is passed a <form> element,
we need to extract <form> from the object BeautifulSoup constructs
to pass to the `Form` ctor.
@hemberger hemberger requested a review from moy August 22, 2018 16:19
Copy link
Collaborator

@moy moy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK.

The absence of check in some case was rather clearly a bug. We've somehow broken the backward compatibility by making the check stricter, but I think it's OK like that.

Another option is to turn the check into a warning, so that code that badly use it still works, but with a warning message.

@hemberger hemberger merged commit 730ca4a into MechanicalSoup:master Aug 22, 2018
@hemberger hemberger deleted the fix-test branch August 22, 2018 16:34
@hemberger
Copy link
Contributor Author

I like your idea of making it a warning. Perhaps it could say something like this?

"Warning! Form must be passed a bs4.element.Tag that is a <form> at the root level, but it was passed a {}. This will be a LinkNotFoundError in a future version.".format(form.name)

... or whatever the correct terminology is...

@moy
Copy link
Collaborator

moy commented Aug 23, 2018

Sounds good. I'd just write "that is a

at its root level". I first read your sentence as "the tag should be the toplovel of the document" which couldn't be right. And perhaps s/will be/may become/, if we don't want to commit to changing it later.

Care to make a patch, or shall I?

hemberger added a commit to hemberger/MechanicalSoup that referenced this pull request Aug 29, 2018
In 4e3fd3c, passing a bs4.element.Tag that was not a "form"
to the constructor of `Form` was escalated to a `LinkNotFoundError`.

Since this breaks backwards compatibility, we soften the error to
a deprecation warning (using the warnings library). In a future
version, this may become an error again.

However, `StatefulBrowser.select_form` has always raised an error
in this case since it began accepting a bs4.element.Tag in a5dec34,
so we continue to do so there.

Related to MechanicalSoup#228.
moy pushed a commit that referenced this pull request Aug 30, 2018
In 4e3fd3c, passing a bs4.element.Tag that was not a "form"
to the constructor of `Form` was escalated to a `LinkNotFoundError`.

Since this breaks backwards compatibility, we soften the error to
a deprecation warning (using the warnings library). In a future
version, this may become an error again.

However, `StatefulBrowser.select_form` has always raised an error
in this case since it began accepting a bs4.element.Tag in a5dec34,
so we continue to do so there.

Related to #228.
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

Successfully merging this pull request may close these issues.

None yet

2 participants