Add explicit test for sqlite3.Row.keys()

[serhiy-storchaka]

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Proposal:

Seems, there are no tests for sqlite3.Row.keys().

Linked PRs

• gh-108558: Improve sqlite3 row factory tests #108578
• [3.12] gh-108558: Improve sqlite3 row factory tests (GH-108578) #108615
• [3.11] gh-108558: Improve sqlite3 row factory tests (GH-108578) #108616
• gh-108558: Add a couple more sqlite Row.keys() tests #108628

[EddInSverige]

Hey @erlend-aasland / @serhiy-storchaka - I'm a test engineer and would love to contribute to Python. Been using it for 9+ years. Any chance of taking a look at this issue?

[erlend-aasland]

Great, have a go at it! :) I'll get a ping when you create the PR.

[EddInSverige]

@erlend-aasland I added a single test just to check the whole build/test workflow etc - happy to add more tomorrow. Does the PR itself look okay?

Edit: I guess master is not what we merge into lol, what's the working branch to merge into? Pulled master for this work

[erlend-aasland]

Edit: I guess master is not what we merge into lol, what's the working branch to merge into? Pulled master for this work

The development branch is called main (currently 3.13 development). Apart from that, we've got release branches (3.12, 3.11, etc.). You're free to choose your own branching scheme when developing. I used to name bug/feature branches using the issue number, but nowadays I group them using a simple naming scheme instead: sqlite/* for sqlite3 stuff, clinic/* for Argument Clinic stuff, docs/* for random documentation stuff, and for everything else, I just make up a name there and then :)

Note: all PRs are squashed into a single merge commit in main, so you don't have to worry about the PR/branch history; it is ok if it is messy! See also the devguide.