Change package name to pydicom

[GoogleCodeExporter]

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 reported on code.google.com by darcymason@gmail.com on 17 May 2009 at 6:12

[GoogleCodeExporter]

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?

Original comment by darcymason@gmail.com on 12 Jun 2009 at 3:31

• Added labels: Difficulty-Medium

[GoogleCodeExporter]

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.

Original comment by Suever@gmail.com on 18 Sep 2012 at 9:38