Change package name to pydicom

[suever]

From darcymason@gmail.com on May 17, 2009 14:12:54

It's considered bad practice for the library name and it's import name to be different -- it is confusing for users.

So, should change the import name to "pydicom", which would require:

• update all documentation to use "pydicom" rather than "dicom"
• update all example files
• ?possibly provide a converter tool to search and replace:
  • from dicom import --> from pydicom import
  • import dicom --> import pydicom
  • dicom. --> pydicom.

Original issue: http://code.google.com/p/pydicom/issues/detail?id=45

[suever]

From darcymason@gmail.com on June 11, 2009 20:31:06

Set difficulty. Not too hard but needs folder rename in svn repository, and a big search and replace throughout all source files. ?Is it possible to somehow install a "dicom" as well, with a deprecation warning?

Labels: Difficulty-Medium

[suever]

From Suever@gmail.com on September 18, 2012 14:38:34

I've been thinking about this change and have a few thoughts.

Ideally, we would allow the users to import dicom and then get a deprecation warning; however, asking around on the Python irc and other forums, it doesn't seem to be possible (without some severe abuse of distutils).

It seems that the unanimous answer to this issue was to create a new package (pydicom) and create a new release for the old one that throws deprecation warnings in init.py and tells the user to upgrade to the new package and informs them of the name change.

There are still a few issues with this though:

• I'm not completely sure how this would work for users that get their pydicom package through package management software rather than from source (i.e. Say the person had access to the old package, they get the warnings, however, they cannot 'import pydicom' until they've downloaded the new package, which wouldn't be available concurrently through the package manager). I guess they could just stick with the old version until the repo manager upgrades to 1.0.
• Then there's the other chance that an experienced user downloads the new and improved 1.0 only to find that when they import dicom (which they already have on their system), they get 0.9.x instead and wonder why everything looks the same. They would have to read the release notes to know to use pydicom

These are just some things that probably need to be thought through. It seems that the user-base for the library is large enough that we need to be careful with these large changes. I do agree that if we make this change though, that it should accompany addition of python3 support in 1.0.