#6 rtf2xml script has name conflict with rtf2xml package

closed-fixed
nobody
None
5
2005-07-23
2005-07-19
Jason R. Coombs
No

Using Windows Server 2003 and Python 2.4, I installed
rtf2xml.

This puts rtf2xml (the script) in C:\Python24\Scripts
and the rtf2xml package in
c:\Python24\Lib\site-packages\rtf2xml.

If I start Python from any folder other than
C:\Python24\Scripts, I can invoke the rtf2xml modules
correctly.

C:\>"\Python24\python"
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import rtf2xml.ParseRtf
>>>

If I start Python from the Scripts folder or if I
attempt to execute the rtf2xml script in any way, I
cannot import ParseRtf because in the import directive,
rtf2xml is resolved as the script and not as the package.

C:\>"\Python24\python" "\Python24\scripts\rtf2xml"
Traceback (most recent call last):
File "\Python24\scripts\rtf2xml", line 51, in ?
import rtf2xml.ParseRtf
File "C:\Python24\Scripts\rtf2xml.py", line 51, in ?
ImportError: No module named ParseRtf

Renaming the script to something else (e.g. rtf2xml_sc)
resolves the problem. Does this only happen in Windows
where "" is in sys.path?

Discussion

    • status: open --> wont-fix
     
  • Logged In: YES
    user_id=663081

    Thanks for your comment.

    No, this is not just a problem with Windows. In any system,
    this would create a conflict.

    Someone else reported on this as well. Perhaps I should
    have taken more care when I named the script. I have never
    had this problem because I have never tried to import
    directly from the same directory as the script. But to be
    clear, any machine that runs python would have this problem.
    The only other way to resolve it would be to change the
    order of how your modules load, and put "" last, or after
    Lib/site-packages. But that would mean that your
    site-packages would always load before "". You probably
    don't want that.

    The simplest way to solve the problem is exactly as you have
    done.

    Maybe in the future I will rename my script. Any
    suggestions? rtftoxml? Rtf2xml? rtf_2xml? rtf2xml_convert?

     
    • status: wont-fix --> open
     
  • Logged In: YES
    user_id=599869

    Well, after I posted this bug, I deleted it... because I made
    some mistakes.

    In particular, the problem does not seem to occur if the file
    does not have the .py extension (under Windows).

    The reason I thought this was because I had done the
    following:

    1) Renamed the script rtf2xml to rtf2xml.py (so I could
    execute it from the command line).
    2) Executed rtf2xml.py, which executed the script,
    attempted to impart rtf2xml.py as the package, which in turn
    created rtf2xml.pyc.
    3) When I renamed the file back to rtf2xml (without the
    extension), the .pyc file was still there, and _that_ was what
    python was attempting to import in the second example of
    the original request.

    I found that (under Windows again) if I restored the
    configuration to the stock configuration (that is, only one
    rtf2xml file in scripts without any extension), and run the
    second example above, there is no problem.

    Unfortunately, that configuration under Windows doesn't work
    well because then it can't be executed directly.

    To address the solution, I would target the code itself... or
    consider renaming the library.

    To me, the command rtf2xml is perfect and well named, and
    that's why I wouldn't want to see it polluted with an
    underscore or a capital letter. Furthermore, I'm not certain
    with the case insensitivity of Windows that renaming the file
    as Rtf2xml would even address the problem.

    So, since we know the script rtf2xml cannot exist in the
    same folder as rtf2xml (the package), perhaps it would be
    wise to remove "" from sys.path before importing the rtf2xml
    package and then replace it immediately after.

    While this is somewhat of a hack, it could potentially
    address the problem at a fundamental level while still
    maintaining the elegance and backward compatability of the
    existing naming scheme.

    I've re-opened this bug to make it visible to others. I hope I've
    bene clear. Let me know if you would like me to draft a
    patch.

     
  • Logged In: YES
    user_id=663081

    Yes, you are correct. There will not be a conflict if the
    script is named rtf2xml. The conflict only occurs if you
    rename the script to rtf2xml.py. That would be on all
    platforms, not just Windows. I had forgotten about needing
    the .py extension in order to create a conflict.

    I didn't realize Windows needed a .py ending to execute the
    script directly. I don't see an easy way to fix this
    problem, except warning users about it, and telling them not
    to import from the same directory as the script.

    At first I wanted to change the name of the library.
    However, think about how many problems this creates for
    anyone who already uses import rtf2xm.xxx. All their code
    would have to be changed. Likewise, if I change the name of
    the script, a lot of code might have to be changed as well.

    I guess your idea is best. You could test to see if the
    script exists in the current directory, and if it does,
    change the sys.path. On a unix system, the current directory
    is ".", not "". So this might be a problem.

    I almost just want to change the library to rtftoxml. I
    wonder how many users would find this a problem. I know *I*
    would, because I have lots of import rtf2xml.ParseRtf.

     
  • Logged In: YES
    user_id=663081

    I've written a script called rtf2xml.py. It is in the
    scripts directory in the CVS repository. It works by moving
    the present directory last in sys.path.

    I don't want to make this script the default. I am unsure as
    to why I need to change the current configuration. Could you
    clear things up for me?

    1. Wouldn't it be easier for Windows users to simply change
    the name of their script to something like rtftoxml.py?

    2. What are advantages versus the disadvantags to changing
    the library to rtftoxml?

    3. What are the advantages versus the disadvantages to
    chaning the permenant script to rtftoxml? Or rtftoxml.py?

    4. If a script named rtf2xml.py is executed directly on a
    Windows machine, what does one t ype? rtf2xml or rtf2xml.py?

    Maybe I'll ask some of these questions on the python mailing
    list as well.

     
  • Logged In: YES
    user_id=663081

    The newest beta release fixes this problem.

     
    • status: open --> closed-fixed