Pythonic: code name conflicting with the built-in

Question

I am currently creating code called "SET". The codename is an abbreviation that has been defined for many (non-programmable) reasons and therefore cannot be changed.

Problem: The simplest one, and I think that a less painful way for the end user to use my code would be to give the package name "set". But, of course, this is a problem, as it conflicts with the built-in set function.

Question: What are the possible solutions? Some may be (maybe more):

• change the package name (e.g. setb).

  import setb 

  I really would not want to do this, because then it will be different from the real name

• enter the package name in uppercase (SET)

   import SET 

  This would be a direct solution, but I wonder: is this a pythonic name for the package? In addition, I find this a bit painful, since all modules defined in the code will have something like "import SET.xy .." (i.e., in uppercase, written many times). But this is not a very big deal, if it is a pythonic path.

• save the name "set"

   import SET 

  Well, this is clearly not good. But this will only be a problem if the user uses the "import set", right? This should not happen under “normal conditions of use,” since the code will contain some scripts to use it, but rather use it as a standard python module. But we never know, and it can be imported as such, and there may even be some problems that I do not see (with a built-in set).

I am considering solution 2., but I'm really not sure. Maybe this is wrong, or maybe you have a better solution.

PS: I found several similar topics on the Internet and on stackoverflow, but usually it has names inside a script or module inside a package. The problem here is really related to the code name (which only makes sense) and therefore is related to the correct name of the package name.

---

EDIT

Selected solution: I decided to use "SET" as the package name. Although many good suggestions have been suggested here: pyset, semt, setool ... or the more explicit "starexoplanettool" (acronym explanation). Thank you all.

CHANGE No. 2

I like the "funny" solution to have a package named S and a subpackage of E ... for final completion:

  import SET 

Thanks, Don.

Answer 1

Is this actually pythonic for package naming?

In the circumstances, it does not matter.

Leading uppercase is rare (ConfigParser, HTMLParser). Camel case rarely (cStringIO). But this does not make the upper case incorrect.

It just means that next time you should choose the best acronym.

"set" is the English word with the most definitions. This is the single poorest choice of abbreviation.

It is not a matter of conforming to the “standard” of a community of more or less acceptable behavior.

The point is to write something that works.

(i.e. uppercase written many times).

Hardly a problem. People actually run software more often than they write.

People read and tune more often than write.

If you are worried about spelling, copy and paste.

In addition, even a cheap IDE, such as Komodo Edit, can determine how to encode a completed installed module with a long name.

Answer 2

Why not describe the meaning of the abbreviation, and if the user desperately needs a shorter name, they can do import someetymologyterm as SET or whatever they prefer. Python gives them a choice, so this is not the end of the world in any case.

Answer 3

If you need to choose such a misfortune, you can make the pain in the ass an ironic anathema! Just create the main package "S" with subpackage "E" and in it subpacket "T". Then you can do the following:

 import SET 

or

 from set import xyz 

or

 import set as set_ 

you could even do vodoo in the __init__.py main-pacakge file; -)

Only my 2 cents!

Answer 4

I may not get it, but it just looks like a namespace problem.

Here is one way out. Prepare the path to set.py on sys.path before importing. You can wrap this in a function that returns changes after import.

I am on the train, so I can’t check it, but this is what I will try.