orthonym.input_mol#
Note
Internal API. Names and behaviour may change between releases.
An RDKit molecule as the input of a public naming call.
The public functions (name_compound, name_with_tree, classify_limit and
the Orthonym methods name, name_tiered, name_with_tree,
name_with_confidence) take a SMILES string or an RDKit Chem.Mol. A string is
named as it always was. A Mol is named through RDKit’s SMILES of it: each public
call turns a Mol into that SMILES with:func:smiles_for and names the string, so
a Mol gets exactly the result its SMILES gets.
smiles_for() writes the SMILES, Chem.MolToSmiles of a copy of the Mol
(the caller’s object is never changed), and first proves that the SMILES holds the
molecule RDKit reads from the Mol. Where the proof fails it raises
InvalidInputError, a ValueError, rather than let the call name another
molecule or another stereoisomer:
RDKit reads the SMILES back (
Chem.MolFromSmiles).RDKit’s standard InChI of the Mol as given (without its conformers, which the InChI writer would read instead of the stereo tags, and before any sanitization, which can change what the InChI writer reads) equals the InChI of that reading. RDKit makes no InChI for some molecules (a dummy atom, for one); then the other checks decide.
Atom for atom, through the order in which the writer wrote the atoms (
_smilesAtomOutputOrder), the reading has the atoms and bonds of the Mol (sanitized on a copy) and every tetrahedral centre and double bond of the Mol that can be stereogenic has the same configuration in the reading, or none in both (a tag on an atom that cannot be a stereocentre, as RDKit’s PDB reader sets, is dropped by the SMILES writer and not compared). This sees stereo that InChI does not (an amidine C=N, for one) and stereo a SMILES cannot hold (a double bond left open between two set ones gets a configuration in any SMILES). In a symmetric molecule the writer can write the configurations of a symmetric equivalent, so other matchings of the atoms are tried as well.Every lone-pair stereocentre of the SMILES has the same configuration in RDKit’s reading as in the standard reading of SMILES, which the naming of a string follows (
_lone_pair_centres_read_alike()).
A Mol with stereo this check cannot compare is declined before the SMILES is
written: an AND or OR stereo group (a SMILES holds no stereo group), an atropisomer tag (a SMILES holds no axis configuration) or a CHI_OTHER
chiral tag (RDKit’s SMILES writer can crash the process on one). Square-planar,
trigonal-bipyramidal and octahedral tags pass: a SMILES holds them and no name states
them, so the Mol gets the result of its SMILES.
Only a caller’s own call (outside any naming) hands None or another type to
smiles_for(), where it raises; a non-str the engine itself passed to one of
its entries keeps the path it had before Mol input existed (handles()).
- exception orthonym.input_mol.InvalidInputError#
Bases:
ValueErrorNone, or a Mol whose SMILES does not hold the molecule RDKit reads from it, given to a public call; a ValueError, as for a SMILES RDKit cannot read.
- orthonym.input_mol.handles(arg)#
Whether a public entry turns
arg(not astr) into a SMILES withsmiles_for(): a Mol always; any other type when the call is a caller’s own (outside any naming), where it raises.
- orthonym.input_mol.smiles_for(arg)#
The SMILES a public call names for its non-str argument
arg: RDKit’s canonical SMILES of the Mol, once the proof in the module docstring holds.An empty Mol gives
"", named as the empty string is. RaisesInvalidInputErrorforNoneand for a Mol that the proof declines or that RDKit cannot sanitize or write; TypeError for any other type.