Thanks @mattijn, I've only skimmed through but this is looking better! 🎉

One thing that stands out to me on a first look:

No changes to the code in altair were required.

Apologies for not being clearer, I'm absolutely fine with further changes being made in both altair and tools.

test_pandas_date_parse

I think that at least (#3854 (comment)) will require some changes outside of the test suite - since that issue seems very related to (vega/vega-datasets#702).

My guess is that because that PR introduced a disconnect between the Resource.name and Resource.path, like below, the way I was previously handling these fields probably needs to be updated in some way:

{"name": "7zip.png", "path": "7zip.png"}
{"name": "annual-precip.json", "path": "annual-precip.json"}
{"name": "flights-200k.arrow", "path": "flights-200k.arrow"}
{"name": "flights-20k.json", "path": "flights-20k.json"}

{"name": "icon_7zip", "path": "7zip.png"}
{"name": "annual_precip", "path": "annual-precip.json"}
{"name": "flights_200k_arrow", "path": "flights-200k.arrow"}
{"name": "flights_20k", "path": "flights-20k.json"}

For reference:

• (909e7d0) was the commit that introduced using schema data type information for pandas, in response to @joelostblom's early experience (feat(RFC): Adds altair.datasets #3631 (comment))
• (a776e2f) was the last major change to SchemaCache
• Also here's the docstring for SchemaCache

  altair/altair/datasets/_cache.py

  Lines 206 to 220 in 78a57f2

  	class SchemaCache(CompressedCache["_Dataset", "_FlSchema"]):
  	"""
  	`json`_, `gzip`_ -based, lazy schema lookup.
  	- Primarily benefits ``pandas``, which needs some help identifying **temporal** columns.
  	- Utilizes `data package`_ schema types.
  	- All methods return falsy containers instead of exceptions
  	.. _json:
  	https://docs.python.org/3/library/json.html
  	.. _gzip:
  	https://docs.python.org/3/library/gzip.html
  	.. _data package:
  	https://github.com/vega/vega-datasets/pull/631
  	"""

Does that help demonstrate why this is a regression?

• I added functionality to solve an issue that came up in the PR
• I added a test to make sure the data types were at least all temporal data types
• But now they aren't, and the issue is only showing up in pandas - which is where the problem was in the first place 😔

(42236c2)

@mattijn did you generate this?

Yes, but now ruff and or mypy aren't yet happy. Or you don't think we should make pylance happy too?

Yes, but now ruff and or mypy aren't yet happy. Or you don't think we should make pylance happy too?

No I mean did you write this yourself?

Not a type expert, let me leave this to you, but the stubs are now derived from the DataPackage and not the other type files.

Thanks for reviewing @dangotbanned! I've included one raise using the AltairDatasetsError in case for the PyArrow backend when the date type column is in non-ISO date format, related pyarrow issue: apache/arrow#41488.

This is specifically for the 'stocks' dataset example (date contains values like this:"Jan 1 2000"):

from altair.datasets import data

data.stocks(engine="pyarrow")

AltairDatasetsError: PyArrow cannot parse date format in dataset 'stocks'. This is a known limitation of PyArrow's CSV reader for non-ISO date formats.