Closed xrotwang closed 3 years ago
Very cool, we should definitely use that!
I can have a look at the package later, and add this.
Thanks, that would be very cool. The basic functionality is not much divergent from python-newick, but adds this dict-access, which is useful for parsimony, and we may also use the code for tree differences, which @PhyloStar has in other projects, plus add functionalities for tree traversals later.
Any reason why the repos is called tree
and not pylotree
like the package?
Aesthetic reasons only. I also have the plan to use the tree namespace when wrapping these tiny packages into pylogeny/pylogeny
. So one can import pylogeny.tree
, etc. But maybe it is not that good an idea, I am not sure.
Ah, ok. So the plan is a namespace package pylogeny
with a subpackage tree
? Should I move the tree package there already?
I was not sure how to do this best. My idea was to have these sub-packages as standalones, so one could use the Tree package, for example, in LingPy, where it might be needed for reference tree computation, as well as the cluster package, but where the bayes package would be too much. So each package should be standalone, on pypi, but for convenience, pylogeny/pylogeny
will use these as dependencies and add access for reading and writing, which the individual packages do not provide.
So pylogeny/tree
would have the standalone namespace pylotree
, so it can be posted on pypi and re-used in other projects.
If pylotree
is a separate package, I don't think it should be repackaged in pylogeny, but rather required and imported, no?
Yes, that is what I meant, sorry for confusion, you can see a draft here.
So essentially, pylogeny/pylogeny depends on the packages pylogeny/tree aka pylotree, pylogeny/cluster aka pylocluster, etc., the shortening of the suffix was merely for aesthetic reasons on github.
ok. But then I'd rename this repos to pylotree. I find it confusing when repos and package have different names - as is the case with python-newick
:)
Yes, I see the point. This would mean, we should then rename all repos (pylocluster, etc.). But that's fine. @PhyloStar, so our new convention is then: pylo
is always the prefix, and concordance
would be pyloconcordance
, also on github.
Edge is a bit of a misnomer here, though, right? It's rather internal nodes that are labelled. Or is it common to use the node name in a tree as label for the incoming edge?
Johann-Mattis List @.***> schrieb am Di., 4. Mai 2021, 11:48:
Yes, I see the point. This would mean, we should then rename all repos (pylocluster, etc.). But that's fine. @PhyloStar https://github.com/PhyloStar, so our new convention is then: pylo is always the prefix, and concordance would be pyloconcordance, also on github.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pylogeny/tree/issues/1#issuecomment-831817440, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGUOKBHI53YP4EFIBXCCJDTL67FVANCNFSM44CKQ4RA .
Yes, this is from pycogent, they call it Edge. So calling it Node is also fine. But the phylogeny folk uses Edge for node, you can see that from the code by @PhyloStar ;) But I also prefer "Node".
Ok, I'll send a PR
Yes. Node/Edge confusion. :(
Yes, this is from pycogent, they call it Edge. So calling it Node is also fine. But the phylogeny folk uses Edge for node, you can see that from the code by @PhyloStar ;) But I also prefer "Node".
I found it confusing when working with Tree package. I prefer Node for internal nodes.
@LinguList Is the code in bayes package? I thought I am using numbers for internal nodes.
No, I don't think it is in there.
Rather than parsing the newick string here https://github.com/pylogeny/tree/blob/d5e2bca1c272cbbe36571401e7cdd20f7fcf2efb/src/pylotree/tree.py#L5
add_edges
could be implemented as node visitor fornewick.Node.visit
: