Skip to content

Documentation: _imaging incompatible with ucs4 #297

Description

@macfreek

It seems that the _imaging submodule in Pillow (and PIL?) does not work when Python is compiled with the --with-wide-unicode option (causing all internal string representations to be stored as 4-byte Unicode UCS4 instead of 2-byte Unicode UCS2).

Everything seems to work fine:

PIL SETUP SUMMARY
--------------------------------------------------------------------
version      Pillow 2.1.0
platform     darwin 3.2.5 (default, Jul 22 2013, 21:29:27)
             [GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.10.1)]
--------------------------------------------------------------------
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- TIFF G3/G4 (experimental) support available
--- FREETYPE2 support available
--- LITTLECMS support available
--- WEBP support available
--------------------------------------------------------------------

But importing PIL.Image does not work:

>>> from PIL import Image
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/PIL/Image.py", line 149, in <module>
    if hasattr(core, 'DEFAULT_STRATEGY'):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/PIL/Image.py", line 39, in __getattr__
    raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed

The underlying cause seems that --with-wide-unicode, the _PyUnicodeUCS2_FromString function is no longer available:

>>> from PIL import _imaging
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/PIL/_imaging.so, 2): Symbol not found: _PyUnicodeUCS2_FromString
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/PIL/_imaging.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/PIL/_imaging.so
>>> 

I suspect this problem no longer occurs with Python 3.3 and up, since that has implemented PEP 393 (Flexible string representations, as either UCS2 or UCS4).

I don't think code changes to Pillow are in order, but I certainly would appreciate a better error as to the problem. The message "The _imaging C module is not installed" was wrong and put me on the wrong foot. If this error can be improved, that would be of great help.

Thanks!

Activity

  1. aclark4life commented on Jul 22, 2013

    @aclark4life
    Member

    Thanks for the report, are you able to send a pull request containing a better handling of the error? I think we have a lot of room for improvement in this area.

  2. wiredfool commented on Jul 22, 2013

    @wiredfool
    Member

    It appears that in Image.py, 63:74, we're trapping a couple of import errors that we're expecting and warning about them, but silently doing nothing for unexpected errors like this one. I'd say at the very least that every import error should be at least a warning. I don't know if anyone intentionally runs Pillow without the compiled extensions, but I think erroring out sooner rather than later with an actual exception rather than a canned "not installed" one would be reasonable and pythonic. It really doesn't make sense to silently catch an import error and then fail at the first access to the imaging core.

  3. aclark4life commented on Jul 22, 2013

    @aclark4life
    Member

    +1

  4. macfreek commented on Jul 23, 2013

    @macfreek
    ContributorAuthor

    A small correction to the original error report. The problem only occurs when the _imaging extension is build with a different UCS setting than the Python used at runtime. So the error Symbol not found: _PyUnicodeUCS4_FromString can also occur.

  5. aclark4life commented on Sep 27, 2013

    @aclark4life
    Member

    OK I guess we need someone to send a pull request

  6. macfreek commented on Sep 27, 2013

    @macfreek
    ContributorAuthor

    I think this has been fixed in #298 and #299. I'll close it.
    I'll test this weekend and if this error error message resurfaces, I'll reopen.

  7. aclark4life commented on Sep 27, 2013

    @aclark4life
    Member

    Great, thanks

  8. added a commit that references this issue on Sep 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions