### `dask.dataframe.read_csv(urlpath, blocksize='default', lineterminator=None, compression='infer', sample=256000, sample_rows=10, enforce=False, assume_missing=False, storage_options=None, include_path_column=False, **kwargs)`

Read CSV files into a Dask.DataFrame

This parallelizes the :func:`pandas.read_csv` function in the following ways:

- It supports loading many files at once using globstrings:

    >>> df = dd.read_csv('myfiles.*.csv')  # doctest: +SKIP

- In some cases it can break up large files:

    >>> df = dd.read_csv('largefile.csv', blocksize=25e6)  # 25MB chunks  # doctest: +SKIP

- It can read CSV files from external resources (e.g. S3, HDFS) by
  providing a URL:

    >>> df = dd.read_csv('s3://bucket/myfiles.*.csv')  # doctest: +SKIP
    >>> df = dd.read_csv('hdfs:///myfiles.*.csv')  # doctest: +SKIP
    >>> df = dd.read_csv('hdfs://namenode.example.com/myfiles.*.csv')  # doctest: +SKIP

Internally ``dd.read_csv`` uses :func:`pandas.read_csv` and supports many of the
same keyword arguments with the same performance guarantees. See the docstring
for :func:`pandas.read_csv` for more information on available keyword arguments.

Parameters
----------
urlpath : string or list
    Absolute or relative filepath(s). Prefix with a protocol like ``s3://``
    to read from alternative filesystems. To read from multiple files you
    can pass a globstring or a list of paths, with the caveat that they
    must all have the same protocol.
blocksize : str, int or None, optional
    Number of bytes by which to cut up larger files. Default value is computed
    based on available physical memory and the number of cores, up to a maximum
    of 64MB. Can be a number like ``64000000`` or a string like ``"64MB"``. If
    ``None``, a single block is used for each file.
sample : int, optional
    Number of bytes to use when determining dtypes
assume_missing : bool, optional
    If True, all integer columns that aren't specified in ``dtype`` are assumed
    to contain missing values, and are converted to floats. Default is False.
storage_options : dict, optional
    Extra options that make sense for a particular storage connection, e.g.
    host, port, username, password, etc.
include_path_column : bool or str, optional
    Whether or not to include the path to each particular file. If True a new
    column is added to the dataframe called ``path``. If str, sets new column
    name. Default is False.
**kwargs
    Extra keyword arguments to forward to :func:`pandas.read_csv`.

Notes
-----
Dask dataframe tries to infer the ``dtype`` of each column by reading a sample
from the start of the file (or of the first file if it's a glob). Usually this
works fine, but if the ``dtype`` is different later in the file (or in other
files) this can cause issues. For example, if all the rows in the sample had
integer dtypes, but later on there was a ``NaN``, then this would error at
compute time. To fix this, you have a few options:

- Provide explicit dtypes for the offending columns using the ``dtype``
  keyword. This is the recommended solution.

- Use the ``assume_missing`` keyword to assume that all columns inferred as
  integers contain missing values, and convert them to floats.

- Increase the size of the sample using the ``sample`` keyword.

It should also be noted that this function may fail if a CSV file
includes quoted strings that contain the line terminator. To get around this
you can specify ``blocksize=None`` to not split files into multiple partitions,
at the cost of reduced parallelism.

---
### `dask.array.from_array(x, chunks='auto', name=None, lock=False, asarray=None, fancy=True, getitem=None, meta=None, inline_array=False)`

Create dask array from something that looks like an array.

Input must have a ``.shape``, ``.ndim``, ``.dtype`` and support numpy-style slicing.

Parameters
----------
x : array_like
chunks : int, tuple
    How to chunk the array. Must be one of the following forms:

    - A blocksize like 1000.
    - A blockshape like (1000, 1000).
    - Explicit sizes of all blocks along all dimensions like
      ((1000, 1000, 500), (400, 400)).
    - A size in bytes, like "100 MiB" which will choose a uniform
      block-like shape
    - The word "auto" which acts like the above, but uses a configuration
      value ``array.chunk-size`` for the chunk size

    -1 or None as a blocksize indicate the size of the corresponding
    dimension.
name : str or bool, optional
    The key name to use for the array. Defaults to a hash of ``x``.

    Hashing is useful if the same value of ``x`` is used to create multiple
    arrays, as Dask can then recognise that they're the same and
    avoid duplicate computations. However, it can also be slow, and if the
    array is not contiguous it is copied for hashing. If the array uses
    stride tricks (such as :func:`numpy.broadcast_to` or
    :func:`skimage.util.view_as_windows`) to have a larger logical
    than physical size, this copy can cause excessive memory usage.

    If you don't need the deduplication provided by hashing, use
    ``name=False`` to generate a random name instead of hashing, which
    avoids the pitfalls described above. Using ``name=True`` is
    equivalent to the default.

    By default, hashing uses python's standard sha1. This behaviour can be
    changed by installing cityhash, xxhash or murmurhash. If installed,
    a large-factor speedup can be obtained in the tokenisation step.

    .. note::

       Because this ``name`` is used as the key in task graphs, you should
       ensure that it uniquely identifies the data contained within. If
       you'd like to provide a descriptive name that is still unique, combine
       the descriptive name with :func:`dask.base.tokenize` of the
       ``array_like``. See :ref:`graphs` for more.

lock : bool or Lock, optional
    If ``x`` doesn't support concurrent reads then provide a lock here, or
    pass in True to have dask.array create one for you.
asarray : bool, optional
    If True then call np.asarray on chunks to convert them to numpy arrays.
    If False then chunks are passed through unchanged.
    If None (default) then we use True if the ``__array_function__`` method
    is undefined.

    .. note::

        Dask does not preserve the memory layout of the original array when
        the array is created using Fortran rather than C ordering.

fancy : bool, optional
    If ``x`` doesn't support fancy indexing (e.g. indexing with lists or
    arrays) then set to False. Default is True.
meta : Array-like, optional
    The metadata for the resulting dask array.  This is the kind of array
    that will result from slicing the input array.
    Defaults to the input array.
inline_array : bool, default False
    How to include the array in the task graph. By default
    (``inline_array=False``) the array is included in a task by itself,
    and each chunk refers to that task by its key.

    .. code-block:: python

       >>> x = h5py.File("data.h5")["/x"]  # doctest: +SKIP
       >>> a = da.from_array(x, chunks=500)  # doctest: +SKIP
       >>> dict(a.dask)  # doctest: +SKIP
       {
          'array-original-<name>': <HDF5 dataset ...>,
          ('array-<name>', 0): (getitem, "array-original-<name>", ...),
          ('array-<name>', 1): (getitem, "array-original-<name>", ...)
       }

    With ``inline_array=True``, Dask will instead inline the array directly
    in the values of the task graph.

    .. code-block:: python

       >>> a = da.from_array(x, chunks=500, inline_array=True)  # doctest: +SKIP
       >>> dict(a.dask)  # doctest: +SKIP
       {
          ('array-<name>', 0): (getitem, <HDF5 dataset ...>, ...),
          ('array-<name>', 1): (getitem, <HDF5 dataset ...>, ...)
       }

    Note that there's no key in the task graph with just the array `x`
    anymore. Instead it's placed directly in the values.

    The right choice for ``inline_array`` depends on several factors,
    including the size of ``x``, how expensive it is to create, which
    scheduler you're using, and the pattern of downstream computations.
    As a heuristic, ``inline_array=True`` may be the right choice when
    the array ``x`` is cheap to serialize and deserialize (since it's
    included in the graph many times) and if you're experiencing ordering
    issues (see :ref:`order` for more).

    This has no effect when ``x`` is a NumPy array.

Examples
--------

>>> x = h5py.File('...')['/data/path']  # doctest: +SKIP
>>> a = da.from_array(x, chunks=(1000, 1000))  # doctest: +SKIP

If your underlying datastore does not support concurrent reads then include
the ``lock=True`` keyword argument or ``lock=mylock`` if you want multiple
arrays to coordinate around the same lock.

>>> a = da.from_array(x, chunks=(1000, 1000), lock=True)  # doctest: +SKIP

If your underlying datastore has a ``.chunks`` attribute (as h5py and zarr
datasets do) then a multiple of that chunk shape will be used if you
do not provide a chunk shape.

>>> a = da.from_array(x, chunks='auto')  # doctest: +SKIP
>>> a = da.from_array(x, chunks='100 MiB')  # doctest: +SKIP
>>> a = da.from_array(x)  # doctest: +SKIP

If providing a name, ensure that it is unique

>>> import dask.base
>>> token = dask.base.tokenize(x)  # doctest: +SKIP
>>> a = da.from_array('myarray-' + token)  # doctest: +SKIP

NumPy ndarrays are eagerly sliced and then embedded in the graph.

>>> import dask.array
>>> a = dask.array.from_array(np.array([[1, 2], [3, 4]]), chunks=(1,1))
>>> a.dask[a.name, 0, 0][0]
array([1])

Chunks with exactly-specified, different sizes can be created.

>>> import numpy as np
>>> import dask.array as da
>>> rng = np.random.default_rng()
>>> x = rng.random((100, 6))
>>> a = da.from_array(x, chunks=((67, 33), (6,)))

---
### `dask.delayed`

No docstring available.

---
### `dask.base.compute(*args, traverse=True, optimize_graph=True, scheduler=None, get=None, **kwargs)`

Compute several dask collections at once.

Parameters
----------
args : object
    Any number of objects. If it is a dask object, it's computed and the
    result is returned. By default, python builtin collections are also
    traversed to look for dask objects (for more information see the
    ``traverse`` keyword). Non-dask arguments are passed through unchanged.
traverse : bool, optional
    By default dask traverses builtin python collections looking for dask
    objects passed to ``compute``. For large collections this can be
    expensive. If none of the arguments contain any dask objects, set
    ``traverse=False`` to avoid doing this traversal.
scheduler : string, optional
    Which scheduler to use like "threads", "synchronous" or "processes".
    If not provided, the default is to check the global settings first,
    and then fall back to the collection defaults.
optimize_graph : bool, optional
    If True [default], the optimizations for each collection are applied
    before computation. Otherwise the graph is run as is. This can be
    useful for debugging.
get : ``None``
    Should be left to ``None`` The get= keyword has been removed.
kwargs
    Extra keywords to forward to the scheduler function.

Examples
--------
>>> import dask
>>> import dask.array as da
>>> a = da.arange(10, chunks=2).sum()
>>> b = da.arange(10, chunks=2).mean()
>>> dask.compute(a, b)
(45, 4.5)

By default, dask objects inside python collections will also be computed:

>>> dask.compute({'a': a, 'b': b, 'c': 1})
({'a': 45, 'b': 4.5, 'c': 1},)

---
### `dask.base.persist(*args, traverse=True, optimize_graph=True, scheduler=None, **kwargs)`

Persist multiple Dask collections into memory

This turns lazy Dask collections into Dask collections with the same
metadata, but now with their results fully computed or actively computing
in the background.

For example a lazy dask.array built up from many lazy calls will now be a
dask.array of the same shape, dtype, chunks, etc., but now with all of
those previously lazy tasks either computed in memory as many small :class:`numpy.array`
(in the single-machine case) or asynchronously running in the
background on a cluster (in the distributed case).

This function operates differently if a ``dask.distributed.Client`` exists
and is connected to a distributed scheduler.  In this case this function
will return as soon as the task graph has been submitted to the cluster,
but before the computations have completed.  Computations will continue
asynchronously in the background.  When using this function with the single
machine scheduler it blocks until the computations have finished.

When using Dask on a single machine you should ensure that the dataset fits
entirely within memory.

Examples
--------
>>> df = dd.read_csv('/path/to/*.csv')  # doctest: +SKIP
>>> df = df[df.name == 'Alice']  # doctest: +SKIP
>>> df['in-debt'] = df.balance < 0  # doctest: +SKIP
>>> df = df.persist()  # triggers computation  # doctest: +SKIP

>>> df.value().min()  # future computations are now fast  # doctest: +SKIP
-10
>>> df.value().max()  # doctest: +SKIP
100

>>> from dask import persist  # use persist function on multiple collections
>>> a, b = persist(a, b)  # doctest: +SKIP

Parameters
----------
*args: Dask collections
scheduler : string, optional
    Which scheduler to use like "threads", "synchronous" or "processes".
    If not provided, the default is to check the global settings first,
    and then fall back to the collection defaults.
traverse : bool, optional
    By default dask traverses builtin python collections looking for dask
    objects passed to ``persist``. For large collections this can be
    expensive. If none of the arguments contain any dask objects, set
    ``traverse=False`` to avoid doing this traversal.
optimize_graph : bool, optional
    If True [default], the graph is optimized before computation.
    Otherwise the graph is run as is. This can be useful for debugging.
**kwargs
    Extra keywords to forward to the scheduler function.

Returns
-------
New dask collections backed by in-memory data

---
Error fetching doc for dask.distributed.Client: module 'dask' has no attribute 'distributed'
