No, but you can use upside-down floor division:¹

def ceildiv(a, b):
    return -(a // -b)

This works because Python's division operator does floor division (unlike in C, where integer division truncates the fractional part).

Here's a demonstration:

>>> from __future__ import division     # for Python 2.x compatibility
>>> import math
>>> def ceildiv(a, b):
...     return -(a // -b)
...
>>> b = 3
>>> for a in range(-7, 8):
...     q1 = math.ceil(a / b)   # a/b is float division
...     q2 = ceildiv(a, b)
...     print("%2d/%d %2d %2d" % (a, b, q1, q2))
...
-7/3 -2 -2
-6/3 -2 -2
-5/3 -1 -1
-4/3 -1 -1
-3/3 -1 -1
-2/3  0  0
-1/3  0  0
 0/3  0  0
 1/3  1  1
 2/3  1  1
 3/3  1  1
 4/3  2  2
 5/3  2  2
 6/3  2  2
 7/3  3  3

Why this instead of math.ceil?

math.ceil(a / b) can quietly produce incorrect results, because it introduces floating-point error. For example:

>>> from __future__ import division     # Python 2.x compat
>>> import math
>>> def ceildiv(a, b):
...     return -(a // -b)
...
>>> x = 2**64
>>> y = 2**48
>>> ceildiv(x, y)
65536
>>> ceildiv(x + 1, y)
65537                       # Correct
>>> math.ceil(x / y)
65536
>>> math.ceil((x + 1) / y)
65536                       # Incorrect!

In general, it's considered good practice to avoid floating-point arithmetic altogether unless you specifically need it. Floating-point math has several tricky edge cases, which tends to introduce bugs if you're not paying close attention. It can also be computationally expensive on small/low-power devices that do not have a hardware FPU.

¹In a previous version of this answer, ceildiv was implemented as return -(-a // b) but it was changed to return -(a // -b) after commenters reported that the latter performs slightly better in benchmarks. That makes sense, because the dividend (a) is typically larger than the divisor (b). Since Python uses arbitrary-precision arithmetic to perform these calculations, computing the unary negation -a would almost always involve equal-or-more work than computing -b.

In Python 3.x, 5 / 2 will return 2.5 and 5 // 2 will return 2. The former is floating point division, and the latter is floor division, sometimes also called integer division.

In Python 2.2 or later in the 2.x line, there is no difference for integers unless you perform a from __future__ import division, which causes Python 2.x to adopt the 3.x behavior.

Regardless of the future import, 5.0 // 2 will return 2.0 since that's the floor division result of the operation.

You can find a detailed description at PEP 238: Changing the Division Operator.

They have different behaviours.

a//b rounds down, so 5//-2 == -3.

int(a/b) rounds towards zero, so int(5/-2) == -2

Edit to add: I just realized something important! a/b always produces a float. If a is too large for the quotient to be represented by a float (i.e, the result is greater than about 10^308), then a/b will fail with an OverflowError. This does not happen with a//b. Observe:

>>> int(10**1000/3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: integer division result too large for a float
>>> 10**1000//3
333333333333333333333333333333333333333333333333333...

Additionally, the floating point number resulting from the division will have rounding errors. Beyond about 2^53, 64-bit floating point numbers cannot accurately represent all integers, so you will get incorrect results:

>>> int(10**22/3)
3333333333333333508096
>>> 10**22//3
3333333333333333333333

You can expand the operator to be more than a single character. For example you could do /int~ and /float~ to disambiguate which division operation to use. It's pretty verbose but if you can find a shorter term to signify which operation you can use that.

This can then be expanded to other operations to for example ensure that overflow behavior is specified for integer addition +sat32~.