It's a matter of (documented) convention (consult also this comment): Due to the periodicity of sampled spectra, the FFT values at ±n/2 are always equal, if n is even. This can easily be shown by looking at the corresponding complex exponential:

In [1]: import sympy as sy

In [2]: n = sy.symbols('n', integer=True)

In [3]: [sy.simplify(sy.exp(sy.I*2*sy.pi*k/n)) for k in (n/2, -n/2)]
Out[3]: [-1, -1]

This convention probably goes back to Matlab: Adapted from an example from Matlab's fft page (using Octave Online):

> L = 6; Fs = 6
Fs = 6
> Fs/L*(-L/2:L/2-1)
ans =

  -3  -2  -1   0   1   2

Note that this ambiguity can bite you, when utilizing the FFT for resampling signals. Consult the example section of SciPy's resample for a short discussion.

Thank you for the link, seems that this issue was spotted long time ago but it was not fixed.

Yes, you can think of the frequency at fs/2 either as +fs/2 or -fs/2, it doesn't matter because the transformed signal is periodic with period fs. The problem is that fftfreq (alone or together with fftshift, which has the same issue) are used to plot one side of the spectrum, since the other side is symmetric for real signals. See the example in https://docs.scipy.org/doc/scipy/tutorial/fft.html, which is a typical use of fftfreq.

In this common use, the point fs/2 is lost because fftfreq makes it negative, and of course the easiest next step is to plot only the segment with non-negative frequencies.

In this respect, it is not a matter of convention. Of course one can easily plot the spectrum including the missing point, either with further frequency wrapping or re-calculating the frequencies points of interest (which is pretty easy), but then what is the whole purpose of fftfreq (and fftshift)? It is usable to plot the whole spectrum, but not usable for one-sided spectrum.

[Out of topic: in most cases the signal is real, but when it is complex, I personally prefer to plot the spectrum from 0 to fs and see the (non-)symmetry around fs/2. So fftfreq is useless for me also in this case.]

@seberg
No, please don't close. It is not a matter of convention, it is about the usability of this function. I added more explanations.

If you are interested only in the non-negative frequencies, just use rfftreq (and rfft)—it returns +n/2 instead of -n/2 for even n:

In [1]: import numpy as np

In [2]: n = 6
   ...: x = np.ones(n)  # n-sample input signal

In [3]: X = np.fft.fft(x)  # two-sided FFT
   ...: f_onesided = np.fft.rfftfreq(n, 1/n)
   ...: X_onesided = X[:len(f_onesided)]  # only non-negative frequency bins

In [4]: f_onesided
Out[4]: array([0., 1., 2., 3.])

The problem is that if you want to change the behavior of fftfreq, you'd potentially break the source code of tens of thousands of programs (as this Github search shows). If you have the need for special requirements, you can easily reimplement your own function, since it is only ten lines long.

Thanks, rfftfreq is good for the purpose. fftfreq is fine as it is for two-sided spectrum.

I create the frequencies myself anyway (it is 1-2 lines of code), but I was surprised by the example in https://docs.scipy.org/doc/scipy/tutorial/fft.html. It should use rfftfreq and the correct limits.