I think complex object should have methods __float__ (returns real part) and __int__ (returns int(real)).
Also I think we need floor and ceil methods om cmath module.
I think, these functions are useful.

They already have a .real attribute to extract the real part, which you can call int on. I suspect the lack of support for float/int coercion is intentional; coercing float to int loses precision, but it's still a fundamentally similar value. Implicitly dropping the imaginary component of a complex number isn't just losing precision, it's fundamentally altering the value (in a way that isn't necessarily obvious).

Similarly, there is no meaningful concept of floor/ceil for complex ( https://math.stackexchange.com/q/2095674/332927 ), so implementing it would involve the same data loss as float/int coercion.

complex numbers are complex, and silently ignoring that just makes it easier to write incorrect code. People can do whatever they want with .real explicitly, but we shouldn't be helping them make mistakes.

Agreed with Josh and closing the issue as rejected.  I'm adding our math experts just in case they disagree or want to provide further clarity.

Agreed with the closure.

I think math.floor should raise TypeError if complex argument passed,
but we need cmath.floor(and ceil).
As I know floor complex number is just floor real part and floor imag.
Example:
z=1.1+2.5j
floor(z) #2+3j
I think it's correct.
But I don't know about complex to float and to int.
Maybe you are right

Oh, __floor__ can return anything.
So I suggest:
1. Methods __floor__ and __ceil__ for complex object.
2. Don't change __float__ and __int__ methods.
3. So I think it isn't nessesary to add methods floor and ceil to complex module.
Example:
from math import *
z=1.1+1.1j
floor(z) #1+1j, same as z.__floor__()
ceil(z) #2+2j, samse as z.__ceil__()

> So I suggest:
> 1. Methods __floor__ and __ceil__ for complex object.

What's the use-case for these? It's not a particularly natural operation, and I've never had a need for a complex "floor" operation, either as a mathematician or as a developer. Do you have an example of real-world code that would benefit?

For those rare cases where this is needed, it isn't that hard to spell out `complex(floor(z.real), floor(z.imag))`, or to write a custom `complex_floor` function.

Also, what type should `math.floor` return when applied to a complex number? `math.floor` of a `float` object returns an `int`, so the analogous operation on a complex number should return a Gaussian integer. But we don't have a Gaussian integer type in standard Python, and it wouldn't be appropriate to add one.

>For those rare cases where this is needed, it isn't that hard to spell out `complex(floor(z.real)
But in Python we have math.tau. However it's just 2*pi.
>`math.floor` of a `float` object returns an `int`
Maybe the best solution is to add functions floor and ceil to cmath module and edit floor and ceil function (in case passing complex argument these function could raise TypeError)

> Maybe the best solution is to add functions floor and ceil to cmath module

You say "solution", but what problem would this be a solution to? So far, I don't think there's a demonstrated need to have this functionality. What is it useful for?

So IMO, the best solution is to make no change: there isn't an actual problem to be solved here. :-)

Again: what's the use-case?

I think at bank.
I find post (Russian) about complex numbers:
https://cyberleninka.ru/article/v/primenenie-kompleksnyh-chisel-v-finansovyh-operatsiyah
And rounding was used.
Sorry, I don't know about English version of this article.

I have no use for this either, and agree with rejecting it - in nearly 30 years, nobody has asked for this before, and it's still the case that we don't have an actual programming use case (some theoretical use in an abstract mathematical model isn't a programming use case).  Seems far more likely that someone applying floor() or ceil() to a complex number is confused.

math.tau was essentially useless too, but Guido wanted to add it mostly as a light-hearted inside joke:

https://bugs.python.org/issue12345

Against that, I see that the popular mpmath Python package does support it (for floor and ceil).  Perhaps you could get mpmath's author to chime in here with a "good" argument for adding it to the core language?

http://mpmath.org/doc/current/general.html#floor

"""
The floor function is defined for complex numbers and acts on the real and imaginary parts separately:

>>> floor(3.25+4.75j)
mpc(real='3.0', imag='4.0')
"""

I can think of two reasons to extend floor() and ceil() to complex numbers, and they lead to different extensions.

The first is as a way to map complex numbers to nearby Gaussian integers by defining floor(z) = floor(z.real) + floor(z.imag)*1j, etc. Definition in mpmath borrowed from Mathematica. Conceivably handy for data quantization, or discrete plane geometry... but I honestly never used it myself and can't remember ever seeing it used.

The second is to extend piecewise analytic functions on R to piecewise holomorphic functions on C so that the real analytic segments extend to complex analytic neighborhoods, most easily achieved by defining floor(z) = floor(z.real). This one I've actually had use for (think complex step differentiation, contour integration), but it's a bit esoteric.

My opinion? If a Python user calls floor() and ceil() with a complex input, it's probably because of a bug in their code, and TypeError is appropriate. It's a one-line lambda to define your own complex extension if you really need it.

On the other hand: if it exists, someone will eventually find a way to use it for code golf ;-)

Can I implement this methods?
@tim.peters

ping @tim.peters

@nagayev I applaud your enthusiasm here, but multiple core developers have already rejected your suggestions in this discussion. Given that, it would probably not be a great use of your time to pursue this.

Maybe you could take a look around the bug tracker for other possible issues you might be interested in pursuing instead?

If you did wanted to pursue this issue[*] in spite of the discussion above (who knows: maybe the core devs who responded on this issue are all misguided, or maybe we're all missing an obvious use case), your best bet would be to bring it up for wider discussion on the python-ideas mailing list.

[*] There are really two issues in this discussion, not one: there's one about `__float__` and `__int__` for complex numbers, and one for extending `floor` and `ceil` to complex numbers, but my understanding of the discussion is that both those have been rejected at this point.