## Short answer

[It was a bug](http://grokbase.com/t/python/python-bugs-list/0814p01pv1/issue1656-make-math-floor-ceil-float-return-ints-per-pep-3141).

With Python 3, the `ceil` and `floor`  return integers (as said by delnan's comment). 
See here for details: http://www.afpy.org/doc/python/2.7/whatsnew/2.6.html

## It "should" be an integer

I do not think returning a floating point here is a sensible thing to do.
The fact that integer 8 is also a real number does mean that we should return a floating point value after doing `floor(8.2)`, exactly because we would not return a complex value with a zero imaginary part (8 is a complex number too). 

This has to do with the mathematical definitions of the operations, not the possible machine representations of values: *floor* and *ceiling* mathematical functions [are defined](https://en.wikipedia.org/wiki/Floor_and_ceiling_functions) to return integers, whereas multiplication is a [ring](https://en.wikipedia.org/wiki/Ring_(mathematics)) where we expect the product of *x* and *y* from set *A* to belong to set *A* too. 
I would not expect `8.2 * 10` to return the integer `82` and similarly I do not expect `floor(8.2)` to return `8.0`. 

By the way, I disagree with some parts of [Robert Harvey's answer](http://programmers.stackexchange.com/a/294113/33157).

- It [makes perfect sense](http://programmers.stackexchange.com/questions/225682/is-it-a-bad-idea-to-return-different-data-types-from-a-single-function-in-a-dyna) to return a value of a different type depending on an input parameter, especially with, but not limited to, mathematical operations. 

- I don't think the return type should be based on a *presupposed* common usage of the value and I don't see how convenient it would be. And if it was relevant, I'd probably expect to be given an integer: I generally do *not* combine the result of `floor` with a floating point.

## Why?

Proably, Python was historically not designed to explicitely conform to the mathematical properties of some operations.   Guido Von Rossum has acknowledged some early design mistakes and explained the rationale behind the types used in Python, notably why he preferred `C` types instead of reusing the ones in [ABC](http://homepages.cwi.nl/~steven/abc/). Note that in `C`, the `ceil` function [takes and returns](http://www.techonthenet.com/c_language/standard_library_functions/math_h/ceil.php) a `double`. See for examples:

- [*Early Language Design and Development*](http://python-history.blogspot.fr/2009/02/early-language-design-and-development.html)

- [*The Problem with Integer Division*](http://python-history.blogspot.fr/2009/03/problem-with-integer-division.html).
    The division operator used to perform truncation, which was generally unexpected and error-prone: see [*Changing the Division Operator*](https://www.python.org/dev/peps/pep-0238/).

The language is supposed to evolve, though, and people tried to incorporate numeric type systems from other languages. For example, [*Reworking Python's Numeric Model*](https://www.python.org/dev/peps/pep-0228/) and 
  [*A Type Hierarchy for Numbers*](https://www.python.org/dev/peps/pep-3141/).