Repository navigation
Trailing backslashes break name round trips #567
Description
Describe the bug
Trailing backslashes break the intended inverse relationship between
NameParts.merge_last_name_first and parse_single_name_into_parts.
Two related cases are involved:
- Parsing a name whose final token ends in a backslash appends that backslash
twice because the end-of-input branch does not stop further handling of the
same character. merge_last_name_firstescapes the final section even though no comma follows
it, changing a terminal backslash unnecessarily.
The existing inverse-property test skips strict and non-strict examples with
odd trailing backslashes, concealing the round-trip failure.
Reproducing
Version: current main (08e370a)
Code:
from bibtexparser.middlewares.names import NameParts
from bibtexparser.middlewares.names import parse_single_name_into_parts
parts = NameParts(
first=["Christina", "A.", "L.\\"],
von=[],
last=["Thiele"],
jr=[],
)
merged = parts.merge_last_name_first
assert parse_single_name_into_parts(merged) == partsThe assertion fails on current main.
Expected behavior
Last-name-first serialization and reparsing should preserve the NameParts
value in both strict and non-strict modes, including terminal backslashes. Only
sections followed by a comma need delimiter-protecting escaping.
Workaround
Avoid terminal backslashes in name parts or normalize affected names manually.
Remaining Questions (Optional)
- I would be willing to contribute a PR to fix this issue.
- This issue is a blocker, I'd be grateful for an early fix.
Activity
claell commentedon Jul 16, 2026
Draft PR #573 contains the focused parser/serializer fix and enables the previously skipped strict and non-strict inverse-property cases.
MiWeiss commentedon Sep 2, 2026
Hi @claell — I'm posting this same note on all of your July 16 issues and PRs (#567–#597), so apologies for the form-letter feel.
I'm closing this. The batch — 13 issues, 18 PRs, ~3,000 lines, opened within a two-hour window with spec-style language and forward-references to PR numbers that didn't exist yet — reads as AI-generated rather than something you hit and verified by hand. Reviewing it properly would cost me more time than just fixing the parser myself.
If this is a real bug you've actually hit: reopen it with a concrete repro and a small, human-verified fix, and I'll review it. Any nontrivial design or API choice should be discussed in the issue first, before code is written. Otherwise, please disclose and verify AI-assisted contributions before submitting them in future.
claell commentedon Sep 3, 2026
@MiWeiss I am answering only once, to avoid duplication of things and discussion for now, starting with this first issue.
But mainly:
I opened issues for this project in the past and have had real, unsolved bugs and quirks that will hit me in real life. Thus, I started this analysis run and implemented fixes to ensure that the parser actually works robustly and will not silently behave unexpected. Having the parser not work robustly (it does not, as of now, actually it is pretty brittle on quite some ends) is kind of a blocker for me. The issues all concern problems with parsing, general robustness and round-trip stability.
I tried my best to make sure that there are proper tests, issues are really there and the fixes help to improve the quality of this tool.
From you as maintainer of the tool, who seems to also use AI for their workflow, I hope you can use that to analyze my raised issues, and understand whether they are actually a problem, or not. I can also try to rephrase things to make them easier to understand. In the end, all I want to do is improving this tool and have a robust, reliable package to use. This is already done in my own fork, but upstreaming things is always better. This is why I went through this hassle and am happy to put even more effort into this, going forward.
Please let me know how to best continue! We can also have a call and discuss the things.
MiWeiss commentedon Sep 10, 2026
Hi @claell
Thanks a lot for your comment and for your contributions, both past and now — genuinely appreciated.
You are of course right; I am a user of coding agents myself — they're great for fixing problems and staying productive. What I'm questioning is the benefit of someone else running an agent and opening the PR, versus me just running it myself:
When I run agents myself, I can steer them directly, ask questions, catch issues as they come up. Doing it that way is just faster — the agent already has the full context of the conversation, so there's no round trip of writing everything up for someone else, waiting on a PR, then reviewing it after the fact. A PR generated elsewhere — especially one that says up front it hasn't been reviewed — means I'm now reviewing a huge change cold, which takes days even with agent help. I do this in my free time, so that's a real cost.
This project is also popular enough that security matters — it's easy to miss something in a large, unfamiliar PR, so I tend to be extra cautious there.
Fair point that the contributing guidelines don't say this — I'll add it. I have to admit though that this situation is quite new to me (to all of us, I guess), so my position here may change as I gain more experience.
That said, I'm genuinely looking forward to more contributions from you. Bug reports are especially valuable — actual issues you've hit in real usage, with a reproduction example and an explanation of the impact. And I'm happy to take PRs too, it just makes sense to discuss scope and approach first before the code gets written if the change is nontrivial.
claell commentedon Sep 14, 2026
@MiWeiss thanks again for your thorough reply.
In general, you are right, I guess. You can of course also run these things by yourself (given you have the subscription to the model, and the time to do that).
For the argument that feedback is time consuming and one might just skip that loop: isn't this also holding up for human written PRs? Why invest the time to give feedback to them? Okay, maybe to help them improve, get involved, ... (but that might also apply to humans contributing AI-written code, no?)
Otherwise, sure, feel free to just iterate on the drafts, I am also fine with that (this is also what sometimes happened before AI, that a maintainer just took the PR, reworked it themselves, and committed).
If you were able to quickly write the whole change yourself with AI, then why is reviewing things cold taking days? Or would it also take you days to write the change in the first place?
Security: Sure. I mean, AI seems to have already contributed a lot to security of projects, and this project might not offer so many attack angles, but I get that keeping things more confined, less code, generally can help with security.
I am fine with the contribution guidelines. We'll see how things develop. At least, this project seems to be AI-friendly in general, and does not just outright deny any of such contributions. I also like the Linux kernel approach.
For contribution: My invitation for a call still stands. I'll see whether I can find the time to revise the issue descriptions a bit (with AI support, as I am time-constrained). Basically, the issues and PRs I created all were addressing problems I experienced, or saw (or features I'd like to see). For example, being able to edit a .bib file while only altering the part I actually alter (not rewriting completely unrelated parts). And some mode where I can check compatibility for my own weird .bib files before using the tool on them.