feat: add DefaultIndexKind.NULL to use as index_col in read_gbq*, creating an indexless DataFrame/Series

[TrevorBergeron]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

[tswast]

Let's be more specfic about the operation. As a user I would appreciate knowing why can't do this. Seems a bit obvious that we can't get a pandas index because there isn't an index, but let's spell it out.

[TrevorBergeron]

rewrote message

[tswast]

This reads odd to me: len(index_cols) == 0 implies not index_col. Could you rephrase what you're trying to check here? I assume you're trying to exclude the DefaultIndexKind enum from this check. Let's be explicit about that.

[TrevorBergeron]

yeah, basically, trying to fall back to sequential index if don't have null index, user provided index columns, or metadata-derived index columns. Rewrote the condition though with the code structure, its still a bit weird.

[tswast]

What are your overall thoughts on testing? How can we be confident that empty/null index works? As we add operations that should support null/empty index, we add tests here and in the usual location?

[TrevorBergeron]

Hmm, I think it will be tricky, as null index tests will require manually configured expectations for many tests, as we cannot always compare against pandas (which doesn't have null index). So yeah, I think we will be stuck with a parallel test suite, which will be a bit burdensome to maintain. Being pandas-equivalent has been a huge boon for testing thus far.

[tswast]

Since these are only bool per type checking, we don't have to worry about any false-y values to mess up "not"

Suggested change

	and (sort is False)
	and (block_identity_join is False)
	and not sort
	and not block_identity_join

[tswast]

Question: Doesn't block_identity_join imply indexless join is allowed? What's this checking for?

Edit: found it

python-bigquery-dataframes/bigframes/core/blocks.py

Line 2292 in ca284cc

allow_row_identity_join=(not block_identity_join),

Apparently block_identity_join is the opposite of what I thought it is. Please add a docstring to this function explaining what these args mean.

[TrevorBergeron]

added docstring

[tswast]

Thanks!

[tswast]

Test failure FAILED tests/system/large/test_remote_function.py::test_remote_function_via_session_vpc_invalid appears to be unrelated.