Poor docstring formatting in vscode

[chriddyp]

Here's what it looks like for getting the docstring within @callback. Lots of white space and odd newline breaks. Could be nicer!

[woefulpines]

Hello, I'm a little new to open source development. I wanted to try this issue to learn a thing or two. Whats the process to be assigned it?

[alexcjohnson]

Welcome @woefulpines! We don't normally bother with assignments in the Plotly open-source repos, you can just get started. Feel free to open a PR as soon as you have some progress to commit and mention this issue, so we know you're working on it and nobody duplicates your efforts.

[woefulpines]

I was looking through the repository. I saw that some of the python generation had proper doc string formatting, I was a little confused as the doc string in the image provided doesn't match the template in the component generation in dash/development/ python component code gen file. I'll continue looking but any other perspective would be appreciated. Also, I was not able to recreate the issue and was wondering how I could get the same result.

[T4rk1n]

@woefulpines I think the components docstring are ok, it's in the callback docstring they are indented too much:

dash/dash/_callback.py

Lines 84 to 134 in 508cce6

	:Keyword Arguments:
	:param background:
	Mark the callback as a long callback to execute in a manager for
	callbacks that take a long time without locking up the Dash app
	or timing out.
	:param manager:
	A long callback manager instance. Currently, an instance of one of
	`DiskcacheManager` or `CeleryManager`.
	Defaults to the `background_callback_manager` instance provided to the
	`dash.Dash constructor`.
	- A diskcache manager (`DiskcacheManager`) that runs callback
	logic in a separate process and stores the results to disk using the
	diskcache library. This is the easiest backend to use for local
	development.
	- A Celery manager (`CeleryManager`) that runs callback logic
	in a celery worker and returns results to the Dash app through a Celery
	broker like RabbitMQ or Redis.
	:param running:
	A list of 3-element tuples. The first element of each tuple should be
	an `Output` dependency object referencing a property of a component in
	the app layout. The second element is the value that the property
	should be set to while the callback is running, and the third element
	is the value the property should be set to when the callback completes.
	:param cancel:
	A list of `Input` dependency objects that reference a property of a
	component in the app's layout. When the value of this property changes
	while a callback is running, the callback is canceled.
	Note that the value of the property is not significant, any change in
	value will result in the cancellation of the running job (if any).
	:param progress:
	An `Output` dependency grouping that references properties of
	components in the app's layout. When provided, the decorated function
	will be called with an extra argument as the first argument to the
	function. This argument, is a function handle that the decorated
	function should call in order to provide updates to the app on its
	current progress. This function accepts a single argument, which
	correspond to the grouping of properties specified in the provided
	`Output` dependency grouping
	:param progress_default:
	A grouping of values that should be assigned to the components
	specified by the `progress` argument when the callback is not in
	progress. If `progress_default` is not provided, all the dependency
	properties specified in `progress` will be set to `None` when the
	callback is not running.
	:param cache_args_to_ignore:
	Arguments to ignore when caching is enabled. If callback is configured
	with keyword arguments (Input/State provided in a dict),
	this should be a list of argument names as strings. Otherwise,
	this should be a list of argument indices as integers.
	:param interval:
	Time to wait between the long callback update requests.

[woefulpines]

I'm sorry for the slow speed on this, I think I have a solution, but I was confused when it comes to opening a pull request. Would I need to apply for certain permissions to create a branch?

[ned2]

@woefulpines what you wanna do is create a fork of the Dash repo in your own GitHub account. Then clone that and create a branch for your fix. Once you've made the commits your need in that branch, push the commits/branch to your fork on GitHub. You can then create a pull request in the Dash repo, requesting the branch from your fork to be merged into the Dash repo.

This is a very common way to contribute to open source projects, so you should be able to find guides on how to do all those steps via Google etc

[sofiemor]

Hello! Is this available to work on?