Will this work and I’d so how risky is it to future problems?

Yes it will work, and how risky it is depends on how good your implementation is. This is perfectly acceptable if done correctly. I have successfully integrated PHP and C, when PHP was simply too slow to do certain niche tasks in real time (IIRC, PHP is 7 times slower than its C counterpart).

The best implementation is to ignore the fact they are PHP/Python specifically, and just treat them as two separate languages.

Now, you need to pick some ‘standard’ way of interacting. HTTP is probably the easiest: everyone has a web server setup already so it’s just a matter of putting the script online.

From here, you need to get away from the fact they are PHP/Python still and design your API without knowing that. For example, imagine you had a calculator:

<?php
print '<answer>' . ($_GET['one'] + $_GET['two']) . '</answer>';
?>

Then your API would be http://location/script.php?one=5&two=7. This is perfectly acceptable: the user of the API expects an answer within an <answer> tag (my example is a lazy mans XML, purely as a demonstration, but I think you should look into outputting JSON). This, is not:

<?php
print eval($_GET['expr']);
?>

Since your API would be http://location/script.php?expr=5+7. Even though it would result in the same answer (and, ignoring any major security flaws), the caller needs to know the implementation details of PHP (eval is a PHP function which will just evaluate its input as real PHP code). If they did 2^3, is that 2 xor 3 or 2 * 2 * 2 (2 to the power 3). This is a bad design: your inputs should be independent of the language your API is implemented in. On top of this, how do we distinguish between an error message and an answer? No magic “if the response is not a number”, please.

Python side – you just need to make sure HTTP requests fail gracefully. If you can’t connect to your script, perhaps try again, and if that fails, give up with a nice error message asking them to try again later. Don’t just display them a Python stack trace.

You should also document your API as well as possible – this will save you a lot of time down the line. Say what each of the inputs should be, what ranges they should fall in, and give some good examples of how to use it.

API side – you should also try to fail quickly if something is wrong. If a variable is missing, incomplete, or invalid, print a message and exit as the first thing you do. Do not just run with the values, and then let them get back a PHP error message (remember, they should not know or care what language your API is implemented in), but should get a nice friendly You didn't give me a 'two' variable. What do you want me to add 'one' to?.

Jay’s answer is correct that you can do this thing.

The normal way to describe this is that you’ll be developing the python algorithm (function) into a “service” (standalone application) that your PHP app will “consume” (make calls to). This is a fine idea if the algorithm is complex enough that you want to think of it as its own program; sequestering your code into separate parts at various levels (separate objects, separate libraries, separate servers) is often a good idea, provided you have clean (defined) separation of concerns.

If you do go this route, HTTP(S) is a good option. The other easy synchronous option would be to use system calls, either to the python script directly or to a daemon wrapping the script. This may have performance advantages, and may be the fastest solution to write, but HTTPS is going to have big flexibility and security advantages.

If an asynchronous option will work I might suggest that. Your php app will leave a record of work to be done in some shared location (like the database), and your python app will be constantly polling* for work that needs to be done. Meanwhile, your php app will be checking for, and using the results of, finished work.
Asynchronous solutions like this are a little tricky to get right, but can be really nice once you have them.

(*If you’re on a big cloud provider like AWS or Azure you may have better options than a poll.)

All that said, be mindful of the objections of your developers!
The decision to break one app into multiple apps shouldn’t be taken lightly. There are a lot of reasons to split a system into simpler independent parts, but the fact that a contractor happened to write their piece in the “wrong” language isn’t one of them.