Skip to content

Makes Selenium2Library compatible with both Python 3.4 and 2.7 - #556

Closed
HelioGuilherme66 wants to merge 3 commits into
robotframework:masterfrom
HelioGuilherme66:python3and2
Closed

HelioGuilherme66 wants to merge 3 commits into
robotframework:masterfrom
HelioGuilherme66:python3and2

Conversation

@HelioGuilherme66

Copy link
Copy Markdown
Member

Tested in Linux x64.

@pekkaklarck

Copy link
Copy Markdown
Member

If the idea is to keep the code base Python 2 compatible, using 2to3 is not a good idea. Converting code manually and using future or six as the compatibility layer works much better. For more details see e.g. http://python-future.org/.

In my opinion we should first decide together what approach to use when porting. That covers deciding what compatibility layer to use (future, six, create own, Robot's utils) and do we want the code to look more like Python 2 or Python 3.

@HelioGuilherme66

Copy link
Copy Markdown
Member Author

I did use future after analysis of Robot Framework code. The 2to3 converter surprised me for its efficiency, and I think is a very good starting point. I go now see why Travis is failing.

@HelioGuilherme66

Copy link
Copy Markdown
Member Author

I fixed the problem. There is a launcher for testserver depending if we are on Python 2 or 3. (forgot to add the files). Now the Travis failing should be related with timeout when starting server (locally runs fine).

@pekkaklarck

Copy link
Copy Markdown
Member

I totally disagree about 2to3. It has done lot of stupid changes to the code. I'm strongly -1 on using it. Much better do the conversion manually from the start than trying to fix mess 2to3 has created. Manually going through the code also makes it possible to enhance code otherwise. All that is going to help with future maintenance.

@aaltat

aaltat commented Dec 25, 2015

Copy link
Copy Markdown
Contributor

Because many other projects have abandoned 2to3, for good reasons, I think we should not repeat their mistakes. Also I agree that code does not look good.

I have not read Robot utils code, but my first gut feeling would be to go with future. But because it's just a gut feeling, I don't feel strongly about it.

Because Python 3 is the future (on could even argue that it's a present), I think code must look like Python 3.

@pekkaklarck

Copy link
Copy Markdown
Member

A big problem with using robot.utils as Python 2/3 compatibility layer is that it requires RF 3.0. I agree that future or a little more lower level six is a good choise.

@aaltat

aaltat commented Dec 25, 2015

Copy link
Copy Markdown
Contributor

I think we should update the #479, when we agree on something. Also setting up CI to test against Python 3 would be good too. And dropping 2.6 would be nice too, in my personal opinion. I think we should have some sort of consensus, how we are going to do this.

@pekkaklarck

Copy link
Copy Markdown
Member

Dropping Python 2.6 support is a good idea. It cost us way too many hours with RF 3.0. RF 3.1 will drop it.

…d 3.

Used the tool `futurize`from http://python-future.org/.

The unit test "test_create_remote_browser_with_string_desired_prefs" in
keywords/_browsermanagement.py was removed, because it became incompatible
with Python 2.7.

List of modified files:
build_dist.py
setup.py
src/Selenium2Library/__init__.py
src/Selenium2Library/keywords/__init__.py
src/Selenium2Library/keywords/_alert.py
src/Selenium2Library/keywords/_browsermanagement.py
src/Selenium2Library/keywords/_cookie.py
src/Selenium2Library/keywords/_element.py
src/Selenium2Library/keywords/_formelement.py
src/Selenium2Library/keywords/_javascript.py
src/Selenium2Library/keywords/_logging.py
src/Selenium2Library/keywords/_runonfailure.py
src/Selenium2Library/keywords/_screenshot.py
src/Selenium2Library/keywords/_selectelement.py
src/Selenium2Library/keywords/_tableelement.py
src/Selenium2Library/keywords/_waiting.py
src/Selenium2Library/keywords/keywordgroup.py
src/Selenium2Library/locators/__init__.py
src/Selenium2Library/locators/customlocator.py
src/Selenium2Library/locators/elementfinder.py
src/Selenium2Library/locators/tableelementfinder.py
src/Selenium2Library/locators/windowmanager.py
src/Selenium2Library/utils/__init__.py
src/Selenium2Library/utils/events/__init__.py
src/Selenium2Library/utils/events/event.py
src/Selenium2Library/utils/events/scope_event.py
src/Selenium2Library/utils/librarylistener.py
src/Selenium2Library/webdrivermonkeypatches.py
src/ez_setup.py
test/lib/mockito/__init__.py
test/lib/mockito/inorder.py
test/lib/mockito/invocation.py
test/lib/mockito/matchers.py
test/lib/mockito/mock_registry.py
test/lib/mockito/mocking.py
test/lib/mockito/mockito.py
test/lib/mockito/spying.py
test/lib/mockito/verification.py
test/resources/statuschecker.py
test/resources/testserver/testserver.py
test/run_tests.py
test/run_unit_tests.py
test/unit/keywords/test_browsermanagement.py
test/unit/utils/test_browsercache.py
Added script for dependencies according to Python version.
For Python 2.7 installs current robotframework.

(If there is a better solution, please improve this one).
@HelioGuilherme66

Copy link
Copy Markdown
Member Author

Closing in favor of #564 (better commits/PR changes).

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.

3 participants