For Windows filetype, is dot in "Application.File" significant?

Question

On Windows, I see that Python and many other programs use the filetype name convention of Python.File, with a dot, as opposed to something like ApplicationFile (no dot), which I've also seen a lot of. Is the dot significant? What for?

I'm working on project which adds it's own filetype to the registry, and would like do to the right thing, and know why it's the right thing.

Edit: I'm referring to filetype and not (directly) the file extension. To continue with the python example, the file associations (extensions) are:

C:\>assoc | find ".py"
.py=Python.File
.pyc=Python.CompiledFile
.pyo=Python.CompiledFile
.pyw=Python.NoConFile

and it's filetypes are:

C:\>ftype | find "python"
Python.CompiledFile="C:\Python32\python.exe" "%1" %*
Python.File="C:\Python32\python.exe" "%1" %*
Python.NoConFile="C:\Python32\pythonw.exe" "%1" %*

It's the most correct naming of the filetype I'm after (the left side of = in the last example, right side in first).

Answer 1

These names are the ProgIDs of the file. It's common (though not required) for them to also be the ProgID of a COM object that implements various shell extension interfaces to manipulate that file type; in that case it's conventional (though again not required) to name the object LibraryName.ClassName, based on the name of the COM typelib that will be providing the object.

The COM object isn't necessary if you just want the behavior to be "run this exe and pass the filename in argv[]", but it's good practice to pick a name that would make sense for this purpose, just in case you ever want more sophisticated features (open with an already-running instance, provide extra metadata for search, etc).It's not actually necesssary (you get to specify the various Shell Extension Handlers separately anyway), it's just tidy.