API review: an alternative namo for `dnaio.open`? about dnaio HOT 2 CLOSED

In the projects that I use dnaio.open I think that works very well. Just like gzip.open, lzma.open etc. If fits very well with the style of python.

In practice, I always write SequenceRecord objects that I read or modified. I do not really see a use for constructing FASTQ files on the fly. I mean, in that case "@" + name + "\n" + sequence + "\n+\n" + qualities + "\n" and using a regular open function works much better anyway.

EDIT: Come to think of it, I only use dnaio.open for reading. I use regular xopen for writing and then use the fastq_bytes method.

from dnaio.

Ok, writing the tutorial (#72) just now, I think I’m coming to the conclusion that adding the dnaio. prefix in the rare cases it’s needed is acceptable. I believe what got me thinking about this was that I added type annotations to some functions in Cutadapt, and in those cases leaving out the dnaio. prefix would be a bit nicer.

But let’s close this for now. Adding an alias for open also increases complexity, which would be another reason against it.

from dnaio.