This blog post is 12 years old! Most likely, its content is outdated. Especially if it's technical.
One really annoying thing about PIL is that it's importable as Image and PIL. It leads me and other newbies to think if it's different. I don't want choices:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
>>> import Image
>>> ?
When PIL/Image is put into standard lib, can we call the module: imaging?
- Previous:
- Messed up columns in Django Admin 16 October 2009
- Next:
- What makes my website slow? DNS 23 October 2009
- Related by category:
- How much faster is Redis at storing a blob of JSON compared to PostgreSQL? 28 September 2019 Python
- Best practice with retries with requests 19 April 2017 Python
- Fastest way to find out if a file exists in S3 (with boto3) 16 June 2017 Python
- Interesting float/int casting in Python 25 April 2006 Python
- Fastest way to unzip a zip file in Python 31 January 2018 Python
- Related by keyword:
- ImageMagick conversion comparison 09 December 2006
-
Dynamic image replacement technique 24 February 2006
At least on my machine these two are not the same:
In [14]: import PIL
In [15]: PIL.__file__
Out[15]: '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PIL/__init__.pyc'
In [16]: import Image
In [17]: Image.__file__
Out[17]: '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PIL/Image.pyc'
In [18]: dir(PIL)
Out[18]: ['__builtins__', '__doc__', '__file__', '__name__', '__path__']
In [19]: dir(Image)
Out[19]:
['ADAPTIVE',
'AFFINE',
'ANTIALIAS',
'BICUBIC',
'BILINEAR',
'CONTAINER',
'CUBIC',
'DEBUG',
'EXTENSION',
'EXTENT',
'FLIP_LEFT_RIGHT',
'FLIP_TOP_BOTTOM',
'FLOYDSTEINBERG',
'ID',
'Image',
'ImageMode',
'ImagePalette',
'IntType',
'LINEAR',
'MESH',
'MIME',
'MODES',
'NEAREST',
'NONE',
'NORMAL',
'OPEN',
'ORDERED',
'PERSPECTIVE',
'QUAD',
'RASTERIZE',
'ROTATE_180',
'ROTATE_270',
'ROTATE_90',
'SAVE',
'SEQUENCE',
'StringType',
'TupleType',
'UnicodeStringType',
'VERSION',
'WEB',
'_E',
'_ENDIAN',
'_ImageCrop',
'_MAPMODES',
'_MODEINFO',
'_MODE_CONV',
'__builtins__',
'__doc__',
'__file__',
'__name__',
'_conv_type_shape',
'_getdecoder',
'_getencoder',
'_getscaleoffset',
'_imaging_not_installed',
'_initialized',
'_showxv',
'_wedge',
'blend',
'composite',
'core',
'eval',
'fromarray',
'frombuffer',
'fromstring',
'getmodebandnames',
'getmodebands',
'getmodebase',
'getmodetype',
'init',
'isDirectory',
'isImageType',
'isNumberType',
'isSequenceType',
'isStringType',
'isTupleType',
'merge',
'new',
'open',
'os',
'preinit',
'register_extension',
'register_mime',
'register_open',
'register_save',
'string',
'sys',
'warnings']
I believe this is the real problem:
>>> from PIL import Image as A
>>> import Image as B
>>> B.__file__ == A.__file__
True
zen of python
"There should be one-- and preferably only one --obvious way to do it"
The PIL API is far too horrible to put in the standard library - are they really considering this? Just because it's the only library available for this sort of thing doesn't mean it should end up included as standard.
Fair points. I'm not saying they are but IF they do I have an opinion about the naming.
Whatever it is, it better be consistent.
What about PythonMagick, using it for years despite the bugs in combination with PIL and numpy. The buglist gains speed according to my inbox so there is slight hope on better image processing routines in Python.