I wouldn't have said:

"translating padded sequence alignments still fatally crashes."

Rather, translating padded sequence alignments still raises an exception.

Moreover, I strongly disagree with you that this is a "core biological problem". Gap padded sequences are a human construct in the context of comparing sequences, and to me there is no simple biological rational to have the behaviour you want:

an alignment gap inside a codon block behaves mathematically like an unknown nucleotide (N).

I remain of the view that if that is the appropriate behaviour for your use case, do that substitution explicitly (Zen of Python: 'Explicit is better than implicit.' and 'In the face of ambiguity, refuse the temptation to guess.', etc). I don't think your special case is special enough (again, Zen of Python).

Also, your change would break existing behaviour - previously expected exceptions wouldn't be raised, and your - to N approach used instead. And for that alone, I would veto merging this as is.

Comprehensive test results: partial-gap codon behavior across Biopython versions

This comment documents the evolution of gap handling in translate(), demonstrates
the exact behavior change introduced by this PR, and provides the real-world context
that motivated it.

1. Timeline: How translate() accumulated gap support

† The original issue #558 (2015) by @ColinAnthony explicitly requested both parts:

"Additionally, allowing incomplete codons to be translated to 'X' would increase
the usefulness of the function ie: {"--N":"X","-N-":"X","N--":"X"} where N = [A/G/C/T]"

PR #661 implemented only the --- → - part. The partial-gap codons were left
unimplemented — this PR completes that work, ten years later.

Key observation: Since Biopython 1.72+, Seq.translate() already defaults to gap="-".
This means the Seq method already claims to handle gap characters — but it only
handles the full-gap codon ---. All 720 partial-gap codons (from the full
16-letter IUPAC+gap alphabet) raise TranslationError, despite the user explicitly
(or implicitly, via the default) declaring - as a gap character.

2. The inconsistency: Seq.translate() defaults gap="-" but crashes on partial gaps

>>> from Bio.Seq import Seq
>>> Seq("TCA---TCG").translate()          # works: S-S (full-gap handled)
Seq('S-S')
>>> Seq("TC-").translate()                # CRASHES — gap="-" is the default!
Traceback ...
Bio.Data.CodonTable.TranslationError: Codon 'TC-' is invalid

The user has already told Biopython that - is a gap character (it's the default!).
The full-gap codon --- is handled. But the partial-gap codon TC- crashes.
This is the inconsistency this PR resolves.

3. Complete enumeration: all 4096 IUPAC+gap codons

Biopython already handles the full 15-letter IUPAC nucleotide alphabet
(A,C,G,T,R,Y,S,W,K,M,B,D,H,V,N) for ambiguity resolution in translate().
Adding - (gap) gives a 16-letter alphabet → 16³ = 4096 total codons:

Of the 720 partial-gap codons, only the simplest subset — the 60 from {A,C,G,T,-}³ —
is shown below in detail. The other 660 are mixed IUPAC+dash combinations (e.g. RC-,
TW-, -YG); all resolve to X with the PR applied, and all crash without it.

Detail: the 60 ACGT-dash codons

Without this PR: ALL 60 raise TranslationError (even with gap="-")
With this PR: 8 resolve to a specific amino acid, 52 to X, 0 raise

Complete side-by-side for all 61 codons

One dash, position 3 (XX-) — 16 codons

One dash, position 2 (X-X) — 16 codons, all → X

One dash, position 1 (-XX) — 16 codons, all → X

Two dashes — 12 codons, all → X

Three dashes — 1 codon (pre-existing behavior, unchanged)

4. CodonAligner crashes on gapped nucleotide input

The Bio.Align.CodonAligner class calls .translate(codon_table) on nucleotide
sequence slices during codon-aware alignment (lines 4712–4714 and 4789–4791 in
Bio/Align/__init__.py). If the nucleotide input contains gap characters,
the internal translate() call crashes:

>>> from Bio.Align import CodonAligner
>>> from Bio.Seq import Seq
>>> from Bio.SeqRecord import SeqRecord
>>>
>>> aligner = CodonAligner()
>>> dna = SeqRecord(Seq('ATGTC-CGT'), id='dna')  # TC- = partial gap
>>> pro = SeqRecord(Seq('MSR'), id='pro')
>>>
>>> aligner.score(pro, dna)
# TranslationError: Codon 'TC-' is invalid
>>>
>>> aligner.align(pro, dna)
# TranslationError: Codon 'TC-' is invalid

Tested and confirmed on Biopython 1.87 (installed from PyPI). This is a
long-lasting implementation deficiency left unresolved for years. The
CodonAligner is designed to align nucleotide sequences to their protein
translations — a workflow where gapped alignments are the normal, expected input.

5. This PR does NOT replace dashes with N

To be clear about the design philosophy: this PR does not modify the input sequence
or replace any characters. The dash character is used as a lookup key to resolve
to the IUPAC ambiguity equivalent at translation time, entirely within _translate_str().
The original codon (including dashes) is preserved in error messages.

The approach was chosen because:

• It requires no new function arguments (the existing gap= already declares - as a gap)
• It leverages Biopython's existing IUPAC ambiguity resolution tables
• It's semantically correct: a gap in an alignment column means "unknown nucleotide" — exactly IUPAC N
• It avoids the larger change of adding a respect_alignment=True argument (which was rejected in PR Add more ways to translate nucleotide sequence with dashes #4992)

6. Why the suggested workarounds don't work

7. The out-of-phase test case

This test (included in the PR) proves why global substitution strategies fail:

>>> Seq("AA---A").translate(gap="-")   # With this PR
Seq('XX')
# Codon frame: AA- | --A → AAN → X, NNA → X
# Global .replace("---", "???") would see "AA???A" → wrong codon boundaries

8. Real-world impact: mutation_scatter_plot pipeline

The mutation_scatter_plot
pipeline processes 64 GB GISAID SARS-CoV-2 spike protein alignments (17 million records).

Because translate() crashes on partial-gap codons, the pipeline was forced to implement
a per-codon workaround (alt_translate()) that:

1. Splits 3822-character spike sequences into individual triplets
2. Substitutes - → N for partial-gap codons (same semantics as this PR)
3. Calls translate() on each 3-character codon separately
4. Caches results via @functools.lru_cache to avoid ~18× overhead

This is functionally identical to what this PR implements inside _translate_str().

9. Performance benchmarks (included in test suite)

The PR includes a TestTranslationPerformance class that benchmarks native
translate() against the per-codon workaround. Results on a 3822-nt
spike-protein-length sequence (100 iterations):

The lru_cache variant is faster than native because it avoids re-parsing
repeat codons, but this requires the workaround code to exist at all.
Without the cache, the overhead is ~18× per sequence.

10. Other software tools handle this correctly

Biopython is an outlier in crashing on gapped alignment translation.
The following widely-used tools all handle partial-gap codons gracefully:

SnapGene: ATGTC-CGT → Met Ser Arg

When a sequence with dashes is pasted, SnapGene explicitly asks whether to
"Remove dashes" or "Convert dashes to 'N' characters":

After choosing "Convert to N", the sequence shows ATGTCNCGT (9 bp):

Translation yields Met Ser Arg — SnapGene resolves TCN → Serine,
the same result as this PR:

ApE: ATGTC-CGT → M X R

ApE (written in Tcl) auto-converts - to N on paste
(source: ApE.tcl line 2007):

regsub -all {[^ABCDGHKMNRSTUVWYabcdghkmnrstuvwy*]} $newdna N newdna

Then in proc translate (line 14531), any codon with a non-ACGT character
becomes xxx → X:

if {[regexp -nocase {[^acgt]} $codon]} { lappend i_list "xxx" }

Result: ATGTCNCGT → M X R. This PR does even better: because Biopython
has the full codon translation tables, it can determine that the nucleotide at
the wobble position simply does not matter — all four TC[ACGT] codons encode
Serine — and resolve TC- → S instead of the conservative X.

Summary

11. What this PR changes (code-level)

11 lines added to _translate_str() in Bio/Seq.py:

elif gap is not None and gap in codon:
    ambiguous_codon = codon.replace(gap, "N")
    try:
        amino_acids.append(forward_table[ambiguous_codon])
    except (KeyError, CodonTable.TranslationError):
        if valid_letters.issuperset(set(ambiguous_codon)):
            amino_acids.append(pos_stop)
        else:
            raise CodonTable.TranslationError(
                f"Codon '{codon}' is invalid"
            ) from None

• No new arguments added to any public function
• No existing behavior changed when gap=None (the _translate_str default)
• Logic only activates when gap is explicitly provided and the codon contains the gap character
• Uses Biopython's existing forward_table (IUPAC ambiguity tables) — no new lookup tables
• The diff is strictly additive: 376 insertions, 0 deletions

12. Addressing "Explicit is better than implicit"

This PR is explicit, not implicit:

• The user must explicitly provide gap="-" to activate gap handling (in _translate_str; the Seq method already defaults to this since 1.72+)
• The result comes from Biopython's own IUPAC ambiguity resolution — the same table that already handles TCN → S without controversy
• When the result is ambiguous, X is returned — not a guess

The current behavior is arguably the implicit one: silently defaulting gap="-"
in Seq.translate() but then crashing when that gap appears in a non-trivial position.

Snapgene behavior (translates to MSR s expected):

ApE behavior (translates to MXR, the suboptimal way):

@mmokrejs How do you envision distinguishing between dash due to a missing nucleotide in the sequence, and a dash representing an alignment gap?
With this PR, I believe the sequence
TC- --A GCA TCA --- GCA
would be translated as
SXAS-A
so the first set of dashes are interpreted as unknown nucleotides, whereas the second set of nucleotides are treated as an alignment gap.
If I understand correctly, SnapGene lets you either remove dashes or replace them with N nucleotides, which will result in either SXASXA or SASA, which are both different from the results you would get with this PR.

As a related question, how would you obtain these sequences in a (Bio)python session?

@mdehoon Thank you for the thoughtful question.

This PR produces SXAS-A.

There is no semantic distinction between "missing nucleotide" and "alignment gap" at the sequence level. A dash in an aligned nucleotide sequence always means: "there is no nucleotide here in this organism's gene at this alignment column." The only structural distinction is positional: does the gap span an entire codon frame (---) or only part of it (TC-, --A)?

Your example TC- --A GCA TCA --- GCA → SXAS-A is correct, and I believe this is the most meaningful result:

• TC- → S: the wobble position is unknown, but all four TC[ACGT] encode Serine — resolved via IUPAC
• --A → X: two unknown positions, genuinely ambiguous → X
• GCA → A: standard codon
• TCA → S: standard codon
• --- → -: full-gap codon, pre-existing behavior since PR Bio.Seq: implementing translation of gapped sequences #661 (2016), unchanged by this PR
• GCA → A: standard codon

The worst thing Biopython can do is raise an exception and return nothing. It is always better to return a result — and thanks to the existing IUPAC ambiguity tables, Biopython can actually do it correctly, not just conservatively. When the result is unambiguous (like TC- → S), it resolves it precisely. When it's genuinely ambiguous, it returns X. Either way, the user gets a usable answer instead of a crash.

Regarding SnapGene: You're right that SnapGene asks the user to choose between removing dashes or converting them all to N. If converting to N, --- becomes NNN → X (shown as ? in SnapGene's UI — see screenshot below). So SnapGene would give S?AS?A, which loses the information that --- was a complete codon gap. This PR preserves that distinction, which is arguably more informative.

How you obtain these sequences in Biopython: AlignIO.read("aligned.fasta", "fasta") or any GISAID/NCBI download of aligned sequences. The mutation_scatter_plot pipeline, which processes millions of SARS-CoV-2 spike protein alignments from GISAID, has already had to work around this limitation with a per-codon alt_translate() function. Nevertheless, I would prefer Biopython to finish implementing its own functionality to translate alignments with padding, as other tools already do.

It is the user's responsibility to provide a meaningful sequence. If Biopython is to support translation of aligned sequences at all (and it has, since gap="-" was added), then replacing - with N and using the existing IUPAC translation tables is the only consistent approach. The alternative would be to add a new argument to translate(), which @peterjc has already expressed preference against.

Below is a screenshot of the limited version of SnapGene (unpaid). It even states the full version supports alignments so maybe it would actually respect the --- too and return - instead. I assume so.

$ cat ~/tmp/TC---AGCATCA---GCA.fasta; fastaq translate ~/tmp/TC---AGCATCA---GCA.fasta -
>SXAS-A
TC---AGCATCA---GCA
>SXAS-A
XXASXA
$ fastaq version
3.17.0
$

There are probably more suboptimal implementation of the traslation logic.

$ transeq ~/tmp/TC---AGCATCA---GCA.fasta stdout
Translate nucleic acid sequences
>SXAS-A_1
SASA
$ transeq -version
EMBOSS:6.6.0.0
$

I would not compare what we aim for with partially complete tools around the world. It was always about the effort needed to polish the logic and do the coding.

The worst thing Biopython can do is raise an exception and return nothing. It is always better to return a result — and thanks to the existing IUPAC ambiguity tables, Biopython can actually do it correctly, not just conservatively. When the result is unambiguous (like TC- → S), it resolves it precisely. When it's genuinely ambiguous, it returns X. Either way, the user gets a usable answer instead of a crash.

I strongly disagree that an exception is the worst thing it would do, and have an even stronger disagreement with 'It is always better to return a result'.

Zen of Python, 'In the face of ambiguity, refuse the temptation to guess.'

However, you're building a strong case that many people wouldn't be surprised by the proposed change, and not everyone considers the meaning of a partial codon to be ambiguous the way that I do.

I see two problems with this PR:

(a) it can give incorrect results;

(b) it fixes the wrong function.

For (a), consider this alignment, with a single nucleotide insertion in the first sequence, a single nucleotide deletion in the second sequence, and both in the third sequence:

AAA CCC A TTT GGG AAA CCC TTT GGG
AAA CCC - TT- GGG AAA CCC TTT GGG
AAA CCC A TT- GGG AAA CCC TTT GGG
AAA CCC - TTT GGG AAA CCC TTT GGG
AAA CCC - TTT GGG AAA CCC TTT GGG

With this PR, this gets translated to

KPIWETLW
KPXXETLW
KPIXETLW
KPXWETLW
KPXWETLW

If the indels are due to sequencing errors, the correct translation is

KPFGKPFG
KPFGKPFG
KPFGKPFG
KPFGKPFG
KPFGKPFG

i.e. none of the sequences are translated correctly.
If the indels are due to true nucleotide insertions/deletions, then the correct translation is

KPIWETLW
KPLGNPL
KPIGKPFG
KPFGKPFG
KPFGKPFG

i.e. only the first sequence is translated correctly.

For (b): There is no way for the translate function, which sees only a single sequence, to know whether a dash should be treated as a deletion (as in the 10th column) or as an insertion in a different sequence (as in the 7th column). Therefore, this problem cannot be fixed by modifying the translate function.

Instead, fix the alignment before calling translate. Using the alignment, you can set up some rule to decide if a dash is due to an insertion or a deletion, by considering the number of dashes in each column. The appropriate rule is context-dependent, and there may not exist a rule that is appropriate in all cases.

The Alignment class in Bio.Align makes it easy to count characters in each column and to modify the alignment as needed. I would suggest to try that first.

Let me express my opinion on this topic:

1. I think, anyone who uses a translate method accepts/expects that the supplied nucleotide sequence is organized in codons. Even if someone just wants to check if this is indeed the case, e.g., if a given nucleotide sequence will translate into a meaningful protein sequence.
2. A gap is always a result of some sort of alignment. As far as I know, no sequencer will produce a gap, they report bases or ambiguities. Please correct me if I'm wrong.
3. Seeing a gap thus means that someone modified the sequence. If this modified sequence is passed to a translate method it's fair/natural to assume that this was done to preserve the codon structure of this sequence.

So while I agree with @mdehoon that the alignment should be done in a codon-aware way, I also agree with @mmokrejs that this is the natural way to do so. No one will supply a gapped sequence to a translate method with the expectation that single or double gap means "no base(s)". If I want this behaviour, I would simply omit the gap.

I'd like to see Biopython's translate() method to be able to directly translate gapped sequences without raising an exception, but I also think that this cannot be done without an additional (keyword) argument to avoid introducing a breaking change.

@ColinAnthony

This is one version of a true codon alignment for the sequences you show

AAA CCC  ATT T - -  GGG AAA CCC TTT GGG
AAA CCC  - TT  - - -  GGG AAA CCC TTT GGG
AAA CCC  ATT  - - -  GGG AAA CCC TTT GGG
AAA CCC  TTT  - - -  GGG AAA CCC TTT GGG
AAA CCC  TTT  - - -  GGG AAA CCC TTT GGG

How would you get this codon alignment? Is there some software package that generates these (given the nucleotide sequences)?

I now accept there is demand for the 'naive' translation of partial codons (--- to -, codons with one or two gaps translated by treating them as N). I still think this will often do something wrong, and these would be better translated in the full context (not a one size fits all that our translate method can do), which I think is also @mdehoon's concern.

That leaves the backward incompatible change issue I flagged (as did @MarkusPiotrowski). This new behaviour cannot suddenly become the default - the behaviour of the public API ought not to change.

The Seq object etc use this method:

class _SeqAbstractBaseClass(ABC):
    """Abstract base class for the Seq and MutableSeq classes (PRIVATE).
    # ...

    def translate(
        self, table="Standard", stop_symbol="*", to_stop=False, cds=False, gap="-"
    ):
        # ...

That has default gap="-" and so would trigger the new behavour - a breaking change.

The stand-alone function curiously has default gap=None which is inconsisent (oops), but means it shoudn't change with this PR (?):

def translate(
    sequence, table="Standard", stop_symbol="*", to_stop=False, cds=False, gap=None
):

@ColinAnthony

This is one version of a true codon alignment for the sequences you show

AAA CCC  ATT T - -  GGG AAA CCC TTT GGG
AAA CCC  - TT  - - -  GGG AAA CCC TTT GGG
AAA CCC  ATT  - - -  GGG AAA CCC TTT GGG
AAA CCC  TTT  - - -  GGG AAA CCC TTT GGG
AAA CCC  TTT  - - -  GGG AAA CCC TTT GGG

How would you get this codon alignment? Is there some software package that generates these (given the nucleotide sequences)?

Concatenate some similar FASTA sequences, use clustalw or mafft or other to add the gaps here and there (but they do not respect the codons automatically), then open alignment file in Seaview and pad it youself to respect codons and then go to Menu -> Props - View as proteins https://doua.prabi.fr/software/seaview .

Yes, there are I think already some codon-aware aligners, I still have to research what is the current status on this. The tools have to translate in all three reading frames and evaluate, in which the reading frame continues, so we are getting close to gene prediction. I think still is still in development.

So, typically users polish the roughly sketched multiple-sequence alignments on their own, manually.

The only thing important here is that, their translate functions does not break on any partial codon filled-up up to length three by dashes, nor on ---.

I now accept there is demand for the 'naive' translation of partial codons (--- to -, codons with one or two gaps translated by treating them as N). I still think this will often do something wrong, and these would be better translated in the full context (not a one size fits all that our translate method can do), which I think is also @mdehoon's concern.

It does the right thing. It translates in the only proper way what user provided, taking advantage of the translation tables and of the degenerate properties of the codons (biology).

That leaves the backward incompatible change issue I flagged (as did @MarkusPiotrowski). This new behaviour cannot suddenly become the default - the behaviour of the public API ought not to change.

Take as an example what other tools actually do. They either ask user to drop padding - or they just replace them as N during their own translate() step. Depending how/whether they implement IUPAC codes in the tables, they end up with X or some concrete amino acid.

I see two problems with this PR:

(a) it can give incorrect results;

(b) it fixes the wrong function.

For (a), consider this alignment, with a single nucleotide insertion in the first sequence, a single nucleotide deletion in the second sequence, and both in the third sequence:

AAA CCC A TTT GGG AAA CCC TTT GGG
AAA CCC - TT- GGG AAA CCC TTT GGG
AAA CCC A TT- GGG AAA CCC TTT GGG
AAA CCC - TTT GGG AAA CCC TTT GGG
AAA CCC - TTT GGG AAA CCC TTT GGG

But, this is some DNA alignment, but the 3rd "codon" is incomplete as it spans only 1character instead of three (as it should). This is basically not an alignment padded to codons, so you introduce a frameshift error for al seqeunces, even for those which did not suffer from it. And no tools recover from that. This is the difficult part of any gene prediction tools, so considered the reading frame must be adjusted from left to right due to sequencing errors like this.

If you add -- tot he third column, you end up with what @ColinAnthony did with good grasp of knowledge how the "overcalls" happen during NGS sequencing, so he actually padded not the 3rd "codon-like" column but the 4th.

With this PR, this gets translated to

KPIWETLW
KPXXETLW
KPIXETLW
KPXWETLW
KPXWETLW

If the indels are due to sequencing errors, the correct translation is

KPFGKPFG
KPFGKPFG
KPFGKPFG
KPFGKPFG
KPFGKPFG

i.e. none of the sequences are translated correctly. If the indels are due to true nucleotide insertions/deletions, then the correct translation is

KPIWETLW
KPLGNPL
KPIGKPFG
KPFGKPFG
KPFGKPFG

i.e. only the first sequence is translated correctly.

For (b): There is no way for the translate function, which sees only a single sequence, to know whether a dash should be treated as a deletion (as in the 10th column) or as an insertion in a different sequence (as in the 7th column). Therefore, this problem cannot be fixed by modifying the translate function.

We are not asking the function to do any correction. We asking it to translate whatever was provided. It is not about any guessing. It is properly following the biology.

Instead, fix the alignment before calling translate. Using the alignment, you can set up some rule to decide if a dash is due to an insertion or a deletion, by considering the number of dashes in each column. The appropriate rule is context-dependent, and there may not exist a rule that is appropriate in all cases.

Of course, if user can fix the alignemnt, then great, but that is not an issue here.

The Alignment class in Bio.Align makes it easy to count characters in each column and to modify the alignment as needed. I would suggest to try that first.

I actually used Bio.AlignIO in thepast but it read the whole blob into memory and anyway, did not fit my purpose. and I was not fixing the alignment. I just wanted to translate() sequences from the stream one by one. And that failed badly.

AI is faster than me doing the checks and does nice comparison tables, side by side.

I admit I forgot to check for orphaned nucleotides during the translation. I do it in my own code but in the PR I forgot. Here is a fix, but you will reject it because it breaks the current, broken behavior. Even the AI after reading this thread was reluctant to make it. But the discussion should be about a whole package doing the right thing, not about a partial fix.

So, typically users polish the roughly sketched multiple-sequence alignments on their own, manually.

If you are polishing the alignment manually, then you may as well fill in incomplete codons with N nucleotides while you are at it.

Suppose the unaligned sequences are

AAATTTCCCGGGAAACCCTTTGGG
AAATTTACCCGGGAAACCCTTTGGG
AAATTTCCGGGAAACCCTTTGGG
AAATTTCCCAAACCCTTTGGG

use e.g. clustalw to generate a multiple sequence alignment, which may look like

AAATTT-CCCGGGAAACCCTTTGGG
AAATTTACCCGGGAAACCCTTTGGG
AAATTT-CC-GGGAAACCCTTTGGG
AAATTT-CCC---AAACCCTTTGGG

Then polish these manually to get a codon alignment:

AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCCGGGAAACCCTTTGGG
AAATTTCC-GGGAAACCCTTTGGG
AAATTTCCC---AAACCCTTTGGG

Fill in the incomplete codon:

AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCNGGGAAACCCTTTGGG
AAATTTCCC---AAACCCTTTGGG

and use translate(seq, gap='-') to translate these:

KFPGKPFG
KFPGKPFG
KFPGKPFG
KFP-KPFG

which I believe is the translation you are looking for.

So, typically users polish the roughly sketched multiple-sequence alignments on their own, manually.

If you are polishing the alignment manually, then you may as well fill in incomplete codons with N nucleotides while you are at it.

Suppose the unaligned sequences are

AAATTTCCCGGGAAACCCTTTGGG
AAATTTACCCGGGAAACCCTTTGGG
AAATTTCCGGGAAACCCTTTGGG
AAATTTCCCAAACCCTTTGGG

use e.g. clustalw to generate a multiple sequence alignment, which may look like

AAATTT-CCCGGGAAACCCTTTGGG
AAATTTACCCGGGAAACCCTTTGGG
AAATTT-CC-GGGAAACCCTTTGGG
AAATTT-CCC---AAACCCTTTGGG

Then polish these manually to get a codon alignment:

AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCCGGGAAACCCTTTGGG
AAATTTCC-GGGAAACCCTTTGGG
AAATTTCCC---AAACCCTTTGGG

Fill in the incomplete codon:

AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCCGGGAAACCCTTTGGG
AAATTTCCNGGGAAACCCTTTGGG
AAATTTCCC---AAACCCTTTGGG

and use translate(seq, gap='-') to translate these:

KFPGKPFG
KFPGKPFG
KFPGKPFG
KFP-KPFG

which I believe is the translation you are looking for.

The problem is, that users do not edit the sequence unless there is some extreme, technical reason justifying that. What users and tools do is add - for gaps, because it leaves the trace that sequence has been determined. Tools can also remove gap-only columns. Adding gap-only columns to fill-in the incomplete codon-width do not exist, but I might be wrong. Nobody is going to replace - with N in their alignment, @mdehoon . Translate functions are the workhorse to do the right thing, out of the box. The analytical results must carefully discriminate what has been achieved in the "lab" and and are common adjustments (the padding -).

Although, even the above sketch seems doable, in practice, the sizes of the alignments are much larger. I have one with 17 millions of rows and 3870 chars wide.

Seriously, we should not stitch here proposals how molecular and evolutionary biology should adjust their habits after 40 years and instruct "them" to throw away their use of paddings in the alignment and step back for replacement with N. Although you left the --- unchanged to NNN there are no fucntions to do that in existing tools.

I posted a good number of existing tools doing the right thing, depepending on the attitude of their author to invest more programming time into that tool. What is the state of the art is clear and with this PR biopython could finally do it.

@mmokrejs
Again: the alignment is your problem, not the translate function. If the alignment can be fixed, then no changes are needed to translate.

All you need is a function that removes columns with too many gaps (this can be done easily using alignment.frequencies['-']), and a function that fills in incomplete codons (which does not exist yet in Biopython, but is fairly easy to write).

We could even combine the two into a single function; something along these lines:

>>> from Bio import Align
>>> alignment = Align.read("test.fa", "fasta")
>>> print(alignment)
seq1              0 AAATTT-CCCGGGAAACCCTTTGGG 24
seq2              0 AAATTTACCCGGGAAACCCTTTGGG 25
seq3              0 AAATTT-CC-GGGAAACCCTTTGGG 23
seq4              0 AAATTT-CCC---AAACCCTTTGGG 21

>>> alignment = alignment.codonize()
>>> print(alignment)
seq1              0 AAATTTCCCGGGAAACCCTTTGGG 24
seq2              0 AAATTTCCCGGGAAACCCTTTGGG 24
seq3              0 AAATTTCCNGGGAAACCCTTTGGG 24
seq4              0 AAATTTCCC---AAACCCTTTGGG 21

and then you can call translate on the individual sequences, though a better solution would be to add atranslate method to the Alignment class so you get the amino acid alignment:

>>> alignment = alignment.translate()
>>> print(alignment)
seq1              0 KFPGKPFG 8
seq2              0 KFPGKPFG 8
seq3              0 KFPGKPFG 8
seq4              0 KFP-KPFG 7

>>> alignment[3]
"KFP-KPFG"

@mmokrejs Again: the alignment is your problem, not the translate function. If the alignment can be fixed, then no changes are needed to translate.

All you need is a function that removes columns with too many gaps (this can be done easily using alignment.frequencies['-']), and a function that fills in incomplete codons (which does not exist yet in Biopython, but is fairly easy to write).

We could even combine the two into a single function; something along these lines:

>>> from Bio import Align
>>> alignment = Align.read("test.fa", "fasta")
>>> print(alignment)
seq1              0 AAATTT-CCCGGGAAACCCTTTGGG 24
seq2              0 AAATTTACCCGGGAAACCCTTTGGG 25
seq3              0 AAATTT-CC-GGGAAACCCTTTGGG 23
seq4              0 AAATTT-CCC---AAACCCTTTGGG 21

>>> alignment = alignment.codonize()
>>> print(alignment)
seq1              0 AAATTTCCCGGGAAACCCTTTGGG 24
seq2              0 AAATTTCCCGGGAAACCCTTTGGG 24
seq3              0 AAATTTCCNGGGAAACCCTTTGGG 24
seq4              0 AAATTTCCC---AAACCCTTTGGG 21

and then you can call translate on the individual sequences, though a better solution would be to add atranslate method to the Alignment class so you get the amino acid alignment:

>>> alignment = alignment.translate()
>>> print(alignment)
seq1              0 KFPGKPFG 8
seq2              0 KFPGKPFG 8
seq3              0 KFPGKPFG 8
seq4              0 KFP-KPFG 7

>>> alignment[3]
"KFP-KPFG"

Thank you @mdehoon for the nice example. although I am fond of your efforts to provide a function for that, removing a single column would be very helpful for proteins and non-protein-coding DNA region or protein themselves. But for protein-coding DNA region column triples would need tobe discarded. I will be happy to cooperate with you on development of that. For my own purpose, at them moment I needs a streaming-based approach, with a deep breath I would take 2-pass read of the huge input. Once to fill-in the alignment table, than to do the pruning. I already have developed my own speedups in the way the data is represented but this PR is about a generic function, deeply inspired by my own venture into analysis of the SARS-CoV-2 datasets, including data from GISAID. Parsing 64 GB large fasta file, which does not comply to FASTA format and even contains mix-encoded characters, was a long-standing nightmare. This PR was heavily motivated by my/our efforts to speedup the analyses, and it works well.