keras-tcn: setup.py says 3.5.7, the newest tag says 3.3.0

The version in the packaging file has never been tagged

The repository declares version 3.5.7 in its setup file. The newest release tag is 3.3.0, cut in February 2021 with a subject line about fixing the receptive field, and the two before it cover weight normalization support and matching the original paper's architecture. So the release history stopped more than two years before the source tree reached the version it advertises, which means the number in the package metadata describes a build nobody can obtain from a release page. The same split shows up in the compatibility line, which claims testing against eleven TensorFlow releases from 2.9 to 2.19, several of which did not exist when the last tag was cut. The last commit to the default branch is dated 2026-06-16.

The worked examples drop a factor of two from the formula

The page defines the receptive field as the furthest step back in time a filter can reach, plus one, and gives a formula with a factor of two, explaining that it exists because a residual block contains two convolution layers. Then a note says the figures below behave differently: the examples use a single convolution per layer, so the factor of two drops out. Two worked examples follow on that reduced formula. Anyone who copies the arithmetic from an example will undercount the true field by half, and the class defaults make that easy to do since the dilation list has six entries. The related failure mode is quieter still: input longer than the receptive field is not rejected, and the values beyond it are replaced with zeros.

setup.py changes the TensorFlow dependency and rewrites gRPC variables

The packaging file branches on the platform at import time. The TensorFlow requirement starts as the plain distribution, and if the platform reports Darwin with an arm processor it becomes the macOS-specific distribution instead. That branch also sets two gRPC build environment variables in the process, one for OpenSSL and one for zlib, with a comment linking an issue filed against gRPC. Three things follow. The macOS check keys off the processor string, so an Intel Mac takes the other branch. The branch mutates global environment variables as a side effect of running the file rather than of installing anything. And the README separately instructs macOS users to install a Metal plugin for GPU support, which is a fourth TensorFlow-adjacent package to coordinate.

Two dependency lists, and neither one is complete

The package declares two runtime requirements: NumPy and TensorFlow. The development requirements file declares four: NumPy, a second Keras-related library, Matplotlib, and a graph-description package. TensorFlow is absent from the file you would use to work on the project, and the second Keras library is absent from what gets installed with the package. On top of that the distribution metadata declares no minimum Python version and no version classifiers at all, so a resolver has no floor to enforce, while the only compatibility statement anywhere is a hand-maintained line of prose on the page. The distribution also describes itself as a single package directory with the licence declared as a file to include rather than as a licence identifier, which means tools that read licence metadata from the index will find nothing there.

The parameter guide is one person's notes, not a specification

There is a section on choosing parameters, and its framing is honest: notes from the author's own experience. Some of it is useful and specific, such as matching dilations to the period of a periodic signal, keeping the number of stacks small unless the sequences run to hundreds of thousands of steps, and preferring layer normalization when the network is large enough. Other parts are opinions stated as suggestions, including that more filters are better until overfitting, that activation should be left alone, that dropout is rarely used or set very low, and that the initializer is worth changing only if training gets stuck. The class signature shows where the defaults sit.

TCN(
    nb_filters=64,
    kernel_size=3,
    nb_stacks=1,
    dilations=(1, 2, 4, 8, 16, 32),
    padding='causal',
    use_skip_connections=True,
    dropout_rate=0.0,
    return_sequences=False,
    activation='relu',
    kernel_initializer='he_normal',
    use_batch_norm=False,
    use_layer_norm=False,
    go_backwards=False,
    return_state=False,
    **kwargs
)

R support is a link to a discussion, not a package

The repository description says it supports Python and R. The R support is a pointer to a discussion thread on the issue tracker, labelled as a fully working example, and nothing in the repository is R code: the package builds one Python package directory, and the tree holds a source directory, a tasks directory of example scripts, a miscellaneous directory, and the packaging files. The tasks directory is where the interesting behaviour lives, including a script for sequences of differing lengths, which the page points to when explaining that the timestep dimension may be left unset. That feature is the one genuinely non-obvious thing in the layer and it is documented by example rather than by argument.

Causal padding is the author's only setting, for a stated reason

The padding argument takes causal or same, and the notes section is unambiguous: the author has only ever used causal, because causal padding is what prevents information leaking backwards in time. That is the right default for a forecasting layer and it also means anyone reaching for the other value is on their own. Two smaller behaviours are worth knowing. A flag processes the input sequence backwards and returns it reversed, which is occasionally what you want for a bidirectional pass. Another flag returns the final state in addition to the output. Both are off by default, and the arguments dictionary is documented as the escape hatch for everything else, including the note to give each layer a unique name when using several in one model. Input and output shapes are stated precisely: a three-dimensional tensor in, and either a three-dimensional tensor with the filter count on the last axis or a two-dimensional tensor with the filter count, depending on whether the full sequence is requested. The one flexible dimension is the timestep count, which may be left unset for batches of differing lengths, and the input and output shapes section says so explicitly.

Editorial conclusion

The layer itself is small, well explained for what it is, and still the clearest Keras implementation of the architecture, so the algorithm is worth reading even if you do not install it. The packaging is where to be careful. The version in the working tree has never been tagged, so a version comparison against anything you have installed will mislead you. The distribution declares no Python floor and no version classifiers while the page advertises compatibility with eleven TensorFlow releases. The receptive field formula on the page carries a factor of two that its own worked examples drop, and input beyond the receptive field is zero-filled at the far end rather than rejected, so size the field deliberately. And on Apple silicon, the package installs a different TensorFlow distribution and rewrites two gRPC build variables as a side effect of running its setup file.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. philipperemy/keras-tcn on GitHub
4. README
5. Releases