Hi Noel,
I think I understand your idea, and it's totally compatible with the current
design we're
following. Indeed, the API is going to be for the atom.
In fact, in the actual syntax of the datafile I sent before has an extra column
(which I
omitted) that specifies the element of the
The previous discussion was about having such a function in the public API.
But anyway, let's say you do use smarts, you can still combine it with a
switch statement on element and maybe on something else so that you don't
end up testing the oxygen patterns against a nitrogen (this will already
Noel,
I'm not sure how to describe all the cases with a switch statement.
The original idea of using SMARTS came from your suggestion:
> The thing is, if I was matching a functional group, I would just use a
> SMARTS pattern. This is a general solution for 99% of cases, rather
> than having a
The presence of a class or not is an "implementation detail", as they
say. That is, the user doesn't need to know anything about that.
However, as I am currently replacing the use of SMARTS patterns for
atom typers with switch statements, I'd recommend you to avoid using
SMARTS for this in the
Noel,
thanks for the clarification, the only reason why I was looking at the lazy
mechanism was
because of previous code.
I'm OK with the simple function, although I think there's still a need for a
dedicated
class behind which gets called to parse the different SMARTS patterns from a
data
Typo: "But the guidelines are not unfortunately the existing code. "
On 2 March 2017 at 10:22, Noel O'Boyle wrote:
> Hi Stefano,
>
> Sounds good. But the guidelines are not unfortunately the existing
> guide. I'm currently in the process of rewriting/removing as much of
>
Hi Stefano,
Sounds good. But the guidelines are not unfortunately the existing
guide. I'm currently in the process of rewriting/removing as much of
the croft as possible and the Lazy Evaluation mechanism is in my
sights. It's a legacy from the original codebase. It'll be difficult
to change this
Noel,
quite the contrary, I'm far from being pissed at you, by all means.
I like your suggestion, but I don't know if I can do it right away, there are
still a few
things about the facade programming paradigm that escape my hobbist programming
training.
Following up on the discussion about the
> About the PDB atom name, unfortunately I don't fully understand the
> performance issue implied in my suggestion, but from an interface point of
> view, it seems more intuitive to access an atom property from OBAtom instead
> of going back to the OBResidue (and pass the OBAtom).
The OBAtom
: [OpenBabel-Devel] Convenience functions
Hi Noel,
I agree with you and must say that in 99.99% of cases it's the right way to do.
Although I still believe the convenient functions, especially the ones that
loop over stuff, are extremely useful when called from Python - they are just
so much
Hi there,
As some of you know, I would like to remove all convenience functions
from classes in Open Babel. I would like to explain why.
It's hard to exactly define a convenience function, but it's an
addition to the API that is implemented entirely using existing API
calls and that makes it
11 matches
Mail list logo