#137 PIL import error

closed-fixed
nobody
None
5
2012-05-03
2010-04-28
Anonymous
No

Docutils uses "import Image" to use the Python Imaging Library, which conflicts with django's "from PIL import Image" (essentially the module is imported twice and chokes. See this post http://jaredforsyth.com/blog/2010/apr/28/accessinit-hash-collision-3-both-1-and-1/ for more info).

I've attached a patch which fixes this problem.

Discussion


  • Anonymous
    2010-04-28

     
    Attachments
  • David Goodger
    David Goodger
    2010-04-28

    • status: open --> pending
     
  • David Goodger
    David Goodger
    2010-04-28

    Perhaps it's Django that's the real problem? Or PIL/Image itself? (Or maybe an import problem in Python?)

    If we fix this here, won't projects that use Docutils and also do "import Image" see the same problem?

    I'd like to see some justification as to why this is problem for Docutils to fix.

     

  • Anonymous
    2010-04-28

    • status: pending --> open
     

  • Anonymous
    2010-04-28

    From looking around, I have determined that "from PIL import Image" is the more accepted, standard usage. I would also hope to change PIL such that "import Image" would be impossible, but indeed that seems unlikely to happen.

    Although whichever way docutils implements there will still be a way to break it, would suggest working toward standardization.

     
  • David Goodger
    David Goodger
    2010-04-28

    Can you provide some evidence please? A URL to an authoritative doc would be best.

    Your blog post refers to three projects, two of which use the "non-standard" form... which pre-date the project using the "standard" form. I'm leaning toward "won't fix".

     
  • PIL has long had this split personality, where it tries to support both ways of using it. (This is an insane behavior on PIL's part.)

    Apps I'm involved in use "from PIL import Image".

    I've no hope that PIL will ever be changed to require one or the other uses, and I'm not sure I would advocate doing so, because either is likely to break some non-trivial number of apps.

     
  • David Goodger
    David Goodger
    2010-04-28

    The PIL docs (http://www.pythonware.com/library/pil/handbook/introduction.htm) say to use "import Image".

    If we change Docutils, it may just break somebody else's code. Closing as "invalid": this is a PIL problem.

    Try this workaround in your own code (import PIL.Image once in advance, and make multiple references in Python's modules table):

    >>> import sys
    >>> import PIL.Image
    >>> sys.modules['Image'] = PIL.Image
    >>> import Image
    >>> from PIL import Image as Image2
    >>> id(Image)
    9901296
    >>> id(PIL.Image)
    9901296
    >>> id(Image2)
    9901296

     
  • David Goodger
    David Goodger
    2010-04-28

    • status: open --> closed-invalid
     
  • Günter Milde
    Günter Milde
    2012-05-03

    The momentom seems to go towards PIL.Image:

    The PIL documentation has both variants: http://www.pythonware.com/library/pil/handbook/image.htm uses
    from PIL import Image.

    Fredrik Lundh pronounced at http://mail.python.org/pipermail/image-sig/2011-January/006650.html that as of PIL 1.2 pre-alpha "PIL now lives in the PIL namespace only". So it would be more future-proof to change all "import Image" statements to "from PIL import Image".

    Pygments (now also imported by Docutils for code highlight uses "from PIL import ..." in recent versions.

    Docutils 0.9(svn) uses

    try: # check for the Python Imaging Library
    import PIL
    except ImportError:
    try: # sometimes PIL modules are put in PYTHONPATH's root
    import Image
    class PIL(object): pass # dummy wrapper
    PIL.Image = Image
    except ImportError:
    PIL = None

    since Dec 2011.

     
  • Günter Milde
    Günter Milde
    2012-05-03

    • status: closed-invalid --> closed-fixed