Introduce Markdown.default_extras

[evnchn]

Motivation

In #5548, it was requested to set by-default the markdown extras, citing the influx of LLMs which forgets to add newline for a markdown list as the need driver.

Implementation

It is not possible to offer the ui.markdown.extras API since extras already exists per-instance. I did the next best thing: ui.markdown.default_extras.

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
• Pytests in tests/test_markdown.py
• Documentation is not necessary: the docstring shows up automatically.

[evnchn]

Well but to what end? Do all elements will have many default_* ClassVars lying around?

We may need a more systematic solution, otherwise we are pushing out a non-scalable API out to a single element which we have hard time withdrawing (not until 4.0)

[evnchn]

Oh I have an idea now

All elements will expose .defaults(...) which user can call with kwargs.

The @resolve_defaults decorator will be responsible to resolve the defaults both for those which are affected by DEFAULT_PROP but also for those which are not affected by it, overwrites the default values to follow the one set by the above .defaults(...) mean

This way we do not add N classvars for an element which takes N arguments.

[falkoschindler]

Hm, there's another pattern we could use:

Variable	Files
LOOPBACK	color_input.py, editor.py, time_input.py, input.py, number.py, date_input.py, codemirror.py, fullscreen.py
CONTENT_PROP	mermaid.py, interactive_image.py, content_element.py
TEXT_COLOR_PROP	color_elements.py, badge.py, avatar.py, chip.py
BACKGROUND_COLOR_PROP	color_elements.py
VALUE_PROP	progress.py, codemirror.py, dark_mode.py
FILTER_PROP	filter_element.py
SOURCE_IS_MEDIA_FILE	video.py, audio.py
PIL_CONVERT_FORMAT	image.py, interactive_image.py

Most of these variables are mostly for internal use (LOOPBACK and PROPs), but PIL_CONVERT_FORMAT is - like Markdown's DEFAULT_EXTRAS - something a user might want to change.

Should we keep uppercase class vars for internals and deprecate PIL_CONVERT_FORMAT in favor of a new .defaults(...) API? I just don't like kwargs too much because it won't support proper linting and typing.

Or maybe the assumption that "all elements will have many default_* ClassVars lying around" isn't right. Maybe it's way simpler to just add static class vars like ui.markdown.default_extras. They are a bit hard to distinguish from methods, props and instance vars, which is probably why I chose uppercase vars for above-mentioned internals.

Let's summarize our options so far:

1. ui.markdown.defaults(extras=...) (and ui.image.defaults(pil_convert_format=...)?)
2. ui.markdown.EXTRAS or ui.markdown.DEFAULT_EXTRAS
3. ui.markdown.default_extras (and move towards ui.image.pil_convert_format?)

[evnchn]

don't like kwargs too much

Just to be clear, me neither. But I am not sure if it is a legal move mypy-speaking but can elements define their own .defaults() with per-element-specific arguments, and then Element has a .defaults() (or possibly ._defaults()`) which takes kwargs and is basically a fancy writer to a classvar dict?

Maybe a good idea to try something out and see how mypy reacts because I am not too familiar with classes to know if this is a legal move or not.

[evnchn]

Be sure to check out #5643 as well.

[evnchn]

legal move

No it's not. VSCode complaints, so mypy must be very upset.