This is a bug, and it's due to an unanticipated behaviour when Maxima returns unevaluated:

```
maxima.eval('load ("bffac")')
s = maxima.eval("bfhzeta (%s,%s,%s)"%(s,x,N))
#Handle the case where there is a 'b' in the string
#'1.2000b0' means 1.2000 and
#'1.2000b1' means 12.000
i = s.rfind('b')
if i == -1:
return sage_eval(s)
else:
if s[i+1:] == '0':
return sage_eval(s[:i])
else:
return sage_eval(s[:i])*10**sage_eval(s[i+1:])
return s ## returns an odd string
```

Unfortunately, Maxima doesn't evaluate these terms:

```
sage: maxima.eval('bfhzeta (%s,%s,%s)' % (-3,1,32))
'bfhzeta(-3,1,32)'
```

The `rfind`

then picks up the initial "b" at 0, so `sage_eval(s[:i])`

is `sage_eval('')`

, which throws the SyntaxError.

This could be hacked around to return unevaluated, but the right solution would be to implement `hurwitz_zeta`

along the lines of some of the new special function implementations. This would give a symbolic front and improved backend evaluation. As a workaround in the short term, mpmath can handle this:

```
sage: import mpmath
sage: mpmath.mp.dps = 50
sage: mpmath.hurwitz(-3, 1)
mpf('0.0083333333333333333333333333333333333333333333333333319')
```