some suggestions from a first-time user

[nschloe]

So I've been using bibtexparser this week for the first time, and I'd like to share the benefit of this with you. In the eyes of a first-timer, here are some suggestions for improvement:

• The name. It's not only a parser, after all!

• The dict entries in splitting up the names. "von" is German, how about "prelast"? "jr" should perhaps be "lineage".

• Some things could be more user-friendly. For example, parsing a library is done via a separate function parse_file/parse_string. I saw a rather more elegant method in cryptography some years ago, namely

  Library.from_string(...)
  Library.from_file(...)

  This is implemented as a @classmethod, returning a class instance. Perhaps that also something for btp.

• Likewise, a library should have a .to_string()/.to_file() method.

• .to_string() for Entries

• I often want to get() a value from an entry field. Now, since field keys can occur multiple times, get() is not unique, but how about a get_first() method that returns the value?

• I'd also like to easily construct entries, e.g.,

  Entry.from_dict(
   "article",
   "weiss2024",
   {
       "title": "bibtexparser",
       "year": "2024",
       # ...
   }
  )

• The middleware pattern is very interesting and certainly allows a great deal of flexibility for developers. For the majority of the users, a keyword-based approach would be more usable though. To combine the two, there could perhaps be a wrapper function that translates arguments, e.g., "abbreviate_months=True" to the corresponding middleware in the background.

• setup.py is out, pyproject.toml is in!

[MiWeiss]

Thanks a lot for your suggestions! Much appreciated.

The name. It's not only a parser, after all!

Correct, but it is primarily used for parsing. Also, it has existed for a long time, and changing the name would have all kinds of unexpected consequences in downstream dependencies.

The dict entries in splitting up the names. "von" is German, how about "prelast"? "jr" should perhaps be "lineage".

This is standard bibtex terminology. The majority of sources (all in English) use the same.

Some things could be more user-friendly. For example, parsing a library is done via a separate function parse_file/parse_string. I saw a rather more elegant method in cryptography some years ago, namely [...]

While some of your propositions have their benefits, and some (e.g. to_string) might even eventually be implemented, the current style has been chosen to be somewhat closer to bibtexparser v1 and thus facilitate migration. Note that bibtexparser is used in more than 3000 repositories ;-)

I often want to get() a value from an entry field. Now, since field keys can occur multiple times, get() is not unique, but how about a get_first() method that returns the value?

Bibtexparser v2 stores these as duplicate field key objects, thus they can still be retrieved. Again, the vast majority of usecases does assume unique field keys and uses bibtexparser in a dict-style fashion.

Out of curiosity, where are you using duplicate field keys?

I'd also like to easily construct entries, e.g., [...]

Nice suggestion. bibtexparser is primarily a parser, thus this has no priority at the moment. But feel free to open a dedicated issue to discuss the details and then contribute a PR.

setup.py is out, pyproject.toml is in!

Fancy opening a PR?