Our next release comes with a lot more options for sequence I/O, including validation that can tell you if the format is incorrect
(This requirement will be removed too)
mhenders@mhenders-750-247c ~/dna-seqs $ seqc open_fa.seq
assertion failed on line 48 (/home/mhenders/.seq/stdlib/bio/fasta.seq)
Now back to the FASTQ question. Yes, maybe FASTQ isn't the right tool, but I'm having trouble understanding why r.read is a seq and its representation is the same as the literal, but they are not equal.
This is probably something we should handle (although, AFAIK,
\r is very uncommon to have in FASTA/FASTQ files)
The new parsers raise a validation error
ptn = s'GTCGGGTAG'
dna = s'TAATACACCATTCAGGGAAATACGGATTCCCACCGTCTCTCGGTAGCCTAAC'
def diff(s1:seq, s2:seq):
return len([1 for i in range(len(s1)) if s1[i] != s2[i]])
def forWhere(dna:seq, ptn:seq, d:int):
for i, k in enumerate(dna.split(len(ptn), 1)):
if diff(ptn, k) <= d:
yield i
def allWhere(dna:seq, ptn:seq, d:int) -> list[int]:
return list(forWhere(dna, ptn, d))
def allWhere2(dna:seq, ptn:seq, d:int) -> list[int]:
return [i for i, k in enumerate(dna.split(len(ptn), 1)) if diff(ptn, k) <= d]
print allWhere2(dna, ptn, 6) # ok
print allWhere(dna, ptn, 6) # zsh: bus error
seq/test/stdlib/itertools_test.seq calls it with
combinations('ABCD', 2)
When I do that, it gives me
error: cannot find method '__str__' for type 'generator[list[str]]' with specified argument types ()
When I pass it a generator, it gives me
error: expected function input type 'generator[generator[seq]]', but got 'function[generator[seq]]'
Will keep looking into it, but it definitely looks like a bug
For
combinations, it returns a generator, so e.g. list(combinations('ABCD', 2)) --> [[A, B], [A, C], [A, D], [B, C], [B, D], [C, D]]
e.g. that test does
assert list(itertools.combinations('ABCD', 2)) == [['A','B'], ['A','C'], ['A','D'], ['B','C'], ['B','D'], ['C','D']]
This one works
error: cannot find method 'str' for type 'generator[list[str]]' with specified argument types ()
Ah,
list() of that does not error.
lambda x is so cumbersome IMO :D
But we'll probably add it just for Python compatibility
- Anonymous function is supposed to be quick to type, "lambda" defeats the purpose.
- Colon as parameter (LHS) and result (RHS) separator does not visually work when both are on the same line. This gets worse if we add typing to it, resulting in multiple colons, with the last one to have complete meaning entirely. Eg.
f(a, b, lambda c: int, d: int : c + d). Most (modern?) languages uses arrows, for good reason. - "lambda" and ":" instead of (optional) parens as parameters (LHS) delimiters makes it hard to read code. Eg.
f(a, b, lambda c, d: c + d)takes so much more mental processing to read vs.f(a, b, (c, d) => c + d). - Multi-line functions not possible. Here, we can either introduce block delimiters, or to keep it pythonic, we can parse multi-line anonymous functions as:
result = f(a, b, (c, d) => x = c ** 2 y = c + d x + y # `return` should be optional, keeping consistency with single-line variant )
https://wiki.python.org/moin/AlternateLambdaSyntax
It's interesting to dig through some of the past discussions.
It's interesting to dig through some of the past discussions.