Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Read accessible from python #1492

Merged
merged 8 commits into from
Nov 7, 2016

Conversation

betatim
Copy link
Member

@betatim betatim commented Oct 26, 2016

Fixes #769

This makes khmer.Read accessible from python land. If you do not set one of the attributes hasattr will return False.

  • Is it mergeable?
  • make test Did it pass the tests?
  • make clean diff-cover If it introduces new functionality in
    scripts/ is it tested?
  • make format diff_pylint_report cppcheck doc pydocstyle Is it well
    formatted?
  • Is it documented in the ChangeLog?
    http://en.wikipedia.org/wiki/Changelog#Format
  • Was a spellchecker run on the source code and documentation after
    changes were made?
  • Is the Copyright year up to date?

@@ -308,9 +352,66 @@ static PyGetSetDef khmer_Read_accessors [ ] = {
};


static
PyObject *
khmer_Read_getattr(khmer_Read_Object *self, PyObject *attr_name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try if raising the excepting in the getter works. Good idea!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You were right :)

@betatim betatim force-pushed the feature/access-Read-type branch 2 times, most recently from 9db6883 to 1822270 Compare October 27, 2016 08:46
@codecov-io
Copy link

codecov-io commented Oct 27, 2016

Current coverage is 95.80% (diff: 100%)

No coverage report found for master at 34711f6.

Powered by Codecov. Last update 34711f6...240d970

@betatim betatim force-pushed the feature/access-Read-type branch from 1822270 to fcecdf6 Compare October 27, 2016 09:05
@betatim
Copy link
Member Author

betatim commented Oct 27, 2016

Ready for review! @luizirber, @camillescott, @standage , or @ctb

@@ -1,3 +1,7 @@
2016-10-27 Tim Head <betatim@gmail.com>

* Make khmer's Read type accesible from the python API.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accessible - two ses :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coughcough fixed

const_cast<char *>("quality"), const_cast<char *>("annotations"), NULL
};

if (!PyArg_ParseTupleAndKeywords(args, kwds, "|zzzz", kwlist,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name and sequence shouldn't be optional, I think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Now we have khmer.Read(name, seq) vs screed.Record(dict(name=name, sequence=sequence)). Actually you can pass any kind of dict to Record.

Should we move Read to this "pass a dict as only arg" interface? I prefer the named parameters, but if you frequently turn dicts into Reads it will get tedious typing Read(*my_dict).

@betatim betatim force-pushed the feature/access-Read-type branch from 0d5c365 to dd795bc Compare October 31, 2016 08:14
@betatim
Copy link
Member Author

betatim commented Oct 31, 2016

@luizirber do you have an opinion on the following:

We have khmer.Read(name, seq) vs screed.Record(dict(name=name, sequence=sequence)). Does that difference in interface bother you?

Should we move Read to this "pass a dict as only arg" interface? I prefer the named parameters, but if you frequently turn dicts into Reads it will get tedious typing Read(*my_dict).

@ctb
Copy link
Member

ctb commented Oct 31, 2016

On Mon, Oct 31, 2016 at 01:16:58AM -0700, Tim Head wrote:

@luizirber do you have an opinion on the following:

We have khmer.Read(name, seq) vs screed.Record(dict(name=name, sequence=sequence)). Does that difference in interface bother you?

screed.Record should be changed to support that IMO.

@betatim
Copy link
Member Author

betatim commented Oct 31, 2016

Merge once travis is happy?

@ctb
Copy link
Member

ctb commented Oct 31, 2016

Agreed.

@betatim betatim force-pushed the feature/access-Read-type branch from c58a450 to aaa8675 Compare October 31, 2016 14:08
@ctb
Copy link
Member

ctb commented Oct 31, 2016

Build failed. Update from latest master, fix build, => merge?

@betatim
Copy link
Member Author

betatim commented Nov 2, 2016

This is the error message: https://travis-ci.org/dib-lab/khmer/jobs/171994487#L1841-L1870

@betatim
Copy link
Member Author

betatim commented Nov 2, 2016

This failing test is super weird. make clean && make -> test fails, edit test case to use -x 10e7, rerun tests -> passes, undo edit, test still passes. make clean && make and it fails again.

@ctb
Copy link
Member

ctb commented Nov 2, 2016 via email

@betatim
Copy link
Member Author

betatim commented Nov 2, 2016

travis is happy right now...so merge?!

@ctb
Copy link
Member

ctb commented Nov 2, 2016

I would prefer that the uncertainty be addressed explicitly so that we don't face this in every test going forward ;).

@betatim
Copy link
Member Author

betatim commented Nov 2, 2016

Running the test in a loop 40 times also surfaced this failure mode

>           assert line == '1,96,96,0.98', line
E           AssertionError: 1,96,96,0.96
E           assert '1,96,96,0.96' == '1,96,96,0.98'
E             - 1,96,96,0.96
E             ?            ^
E             + 1,96,96,0.98
E             ?            ^

@ctb
Copy link
Member

ctb commented Nov 2, 2016 via email

@betatim
Copy link
Member Author

betatim commented Nov 2, 2016

I would make a new PR to fix this. At least I have no good idea where to start looking for the race condition so. Empirically this test doesn't seem to happen that often: "a few times in 100 runs"


There are indeed 98 kmers in the file:

import  tests.khmer_tst_utils as utils
def kmer(seq, k=17):
  for i in range(0, len(seq)-k+1):
    yield seq[i:i+k]

kmers = []
for rec in screed.open(utils.copy_test_data('test-abund-read-2.fa')):
  kmers += list(kmer(rec.sequence))

in case we need this snippet again.

@ctb
Copy link
Member

ctb commented Nov 2, 2016

On Wed, Nov 02, 2016 at 08:24:26AM -0700, Tim Head wrote:

I would make a new PR to fix this. At least I have no good idea where to start looking for the race condition so. Empirically this test doesn't seem to happen that often: "a few times in 100 runs"

It's clearly in the 'add' function in Hashtable; that's the only place
the relevant things are incremented.

@betatim betatim force-pushed the feature/access-Read-type branch from 94586a0 to ec1c7f9 Compare November 3, 2016 16:12
@betatim betatim force-pushed the feature/access-Read-type branch from ec1c7f9 to 240d970 Compare November 4, 2016 14:57
@betatim
Copy link
Member Author

betatim commented Nov 7, 2016

merge?

(edit: no, just scrolled up far enough to realise there is homework left)

@ctb
Copy link
Member

ctb commented Nov 7, 2016

I'm fine with merging...

@ctb
Copy link
Member

ctb commented Nov 7, 2016

LGTM - if the thread issue (re)surfaces on CI, let's fix it then.

@ctb ctb merged commit 637e04b into dib-lab:master Nov 7, 2016
@betatim betatim deleted the feature/access-Read-type branch November 7, 2016 17:51
@betatim betatim mentioned this pull request Nov 18, 2016
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants