Lines Matching refs:your

12    use, it is good to have your project available for both major releases of
29 To make your project be single-source Python 2/3 compatible, the basic steps
36 #. Use Futurize_ (or Modernize_) to update your code (e.g. ``pip install future``)
37 #. Use Pylint_ to help make sure you don't regress on your Python 3 support
39 #. Use caniusepython3_ to find out which of your dependencies are blocking your
41 #. Once your dependencies are no longer blocking you, use continuous integration
44 #. Consider using optional static type checking to make sure your type usage
45    works in both Python 2 & 3 (e.g. use mypy_ to check your typing under both
53 **today**! Even if your dependencies are not supporting Python 3 yet that does
54 not mean you can't modernize your code **now** to support Python 3. Most changes
58 Another key point is that modernizing your Python 2 code to also support
65 your code to support Python 2 & 3 simultaneously.
78 to your code should continue to look and feel like idiomatic Python code. At
91 Make sure you specify the proper version support in your ``setup.py`` file
94 In your ``setup.py`` file you should have the proper `trove classifier`_
95 specifying what versions of Python you support. As your project does not support
105 Once you have your code supporting the oldest version of Python 2 you want it
106 to, you will want to make sure your test suite has good coverage. A good rule of
107 thumb is that if you want to be confident enough in your test suite that any
108 failures that appear after having tools rewrite your code are actual bugs in the
109 tools and not in your code. If you want a number to aim for, try to get over 80%
118 Once you have your code well-tested you are ready to begin porting your code to
119 Python 3! But to fully understand how your code is going to change and what
127 Update your code
131 it's time to update your code! You have a choice between two tools in porting
132 your code automatically: Futurize_ and Modernize_. Which tool you choose will
133 depend on how much like Python 3 you want your code to be. Futurize_ does its
142 Regardless of which tool you choose, they will update your code to run under
145 your test suite first and visually inspect the diff to make sure the
146 transformation is accurate. After you have transformed your test suite and
147 verified that all the tests still pass as expected, then you can transform your
150 Unfortunately the tools can't automate everything to make your code work under
155 for you and what you may have to fix on your own (e.g. using ``io.open()`` over
169 have not been doing this then you will need to go through your code and do two
172 #. Add ``from __future__ import division`` to your files
177 an object defines a ``__truediv__`` method but not ``__floordiv__`` then your
234 decoding between binary data and text at the edge of your code. This means that
236 your code needs to send text as binary data then encode it as late as possible.
237 This allows your code to work with only text internally and thus eliminates
240 The next issue is making sure you know whether the string literals in your code
282 #. Decide which of your APIs take text and which take binary data
283 #. Make sure that your code that works with text also works with ``unicode`` and
342 Once you have fully translated your code to be compatible with Python 3, you
343 will want to make sure your code doesn't regress and stop working under
355 compatibility issues your code triggers during execution. If you turn warnings
359 You can also use the Pylint_ project and its ``--py3k`` flag to lint your code
360 to receive warnings when your code begins to deviate from Python 3
362 over your code regularly to catch compatibility regressions. This does require
367 Check which dependencies block your transition
370 **After** you have made your code compatible with Python 3 you should begin to
371 care about whether your dependencies have also been ported. The caniusepython3_
377 The project also provides code which you can integrate into your test suite so
379 you from using Python 3. This allows you to avoid having to manually check your
383 Update your ``setup.py`` file to denote Python 3 compatibility
386 Once your code works under Python 3, you should update the classifiers in
387 your ``setup.py`` to contain ``Programming Language :: Python :: 3`` and to not
388 specify sole Python 2 support. This will tell anyone using your code that you
396 Once you are able to fully run under Python 3 you will want to make sure your
398 your tests under multiple Python interpreters is tox_. You can then integrate
399 tox with your continuous integration system so that you never accidentally break
405 comparisons simply return ``False``, but if you made a mistake in your
410 And that's mostly it! At this point your code base is compatible with both
413 you typically run your tests under while developing.
419 Another way to help port your code is to use a static type checker like
420 mypy_ or pytype_ on your code. These tools can be used to analyze your code as
422 your code is running under Python 3. By running a static type checker twice like
424 of Python compared to another. If you add optional type hints to your code you
425 can also explicitly state whether your APIs use textual or binary data, helping