Reportlab leaks Python 2 builtin replacements on Python 3

Issue #117 new
Dan Palmer
created an issue

We're in the process of upgrading to Python 3, and were surprised to find the bitstring package failed to work on Python 3, despite claiming full Python 3 support. After investigation, we found that bitstring (and possibly other packages) check whether they are on Python 3 by seeing if accessing xrange throws a NameError. Unfortunately, Reportlab patches xrange to range under Python 3 and leaks that patch, so the Python 3 check was failing.

I'll be opening an issue on bitstring, as I don't think that's a great way of checking Python 3 compatibility, but I also think it's unexpected and incorrect behaviour to leak patches like this, so it would be great to fix this in Reportlab as well.

The leaks appear to be:

  • cmp on Python 3
  • xrange on Python 3
  • ascii on Python 2

Lines: https://bitbucket.org/rptlab/reportlab/src/ddf3d4f5066a03ca4bf9de7942ab28fb4eeb862e/src/reportlab/init.py?at=default&fileviewer=file-view-default#init.py-20,21,33

Comments (4)

  1. Robin Becker

    Hi Dan, yes this is a hack.; have discussed with Andy Robinson and he says we should use our own names for these. I hope to get a patch in place in the near future. We are likely to use rlRange, rlCmp & rlAscii as the faked builtins.

  2. Dan Palmer reporter

    Thanks for the response!

    I assume you've already decided against using six?

    I'd be interested to know why, but if that is the case I think namespacing the patches is a good pragmatic solution. I'd probably suggest a clearer namespace like __reportlabRange, as I don't think it would be reasonable for any other package to use or depend on that, whereas rlRange is a little generic. I don't feel strongly about this though as I think it's unlikely to be an issue. The __ prefix might be worth it though to signify that this is explicitly not for external use.

    Another thing I'd suggest would be to add a docstring – when I found builtins.range I started trying to poke it in various ways to figure out where it was coming from. A __doc__ or something like that, which explains the hack, could be really useful.

    Thanks, and let me know if you need a hand with the patch – I'm happy to review and might be able to contribute bits.

  3. Robin Becker

    Hi Dan,

    I eliminated the builtins abuse by using direct assignments in the reportlab/__init__.py; now to use xrange we have to do an import from reportlab if we are using python 3. I think the abuse should be gone since builtins is not accessed in __init__.py any longer. Latest code is in bitbucket and 3.4.15 packages are available at https://www.reportlab.com/pypi/

  4. Log in to comment