BUG: Changing way of applying numpy functions on Series
State: closed

- [x] closes #33492 
- [x] tests added and passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] numpy functions on Series are called like other functions

Labels:
name: Performance
description: Memory or execution speed performance

Comments:
Building documentation returns
```
/home/runner/miniconda3/envs/pandas-dev/lib/python3.8/site-packages/IPython/sphinxext/ipython_directive.py:1023: UserWarning: Code input with no code at /home/runner/work/pandas/pandas/doc/source/user_guide/computation.rst, line 622
```
which looks like issue [#26788](https://github.com/pandas-dev/pandas/issues/26788)
Is this going to kill performance for something like the following?

```python
s = pd.Series(list(range(100_000))
s.apply(np.sin)
```

> Is this going to kill performance for something like the following?
> 
> ```python
> s = pd.Series(list(range(100_000))
> s.apply(np.sin)
> ```
I think so, but I feel like it's more appropriate use of the `apply` function. I think that using numpy functions in the old way should be possible but not like that.
I felt like numpy functions could be called differently e.g. np.sin(series). 
I could add `if` that checks if series dtype is numpy array.
However, I wouldn't expect that numpy array would be used as dtype, I would usually expect inferred object dtype. 
If we're going to change this then we'll need to deprecate the current behavior first. I haven't looked closely at the original issue, but at a glance it looks like it's dealing with nested data, which isn't especially well-supported in pandas. It's not clear to me that the gain from changing the implementation here is worth the effect to existing users.
Maybe better solution would be adding new parameter e.g if parameter force_mapping is set to True, function will be applied on each element separately.
Hello @mproszewska! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2020-05-10 21:18:01 UTC
I don't like just adding the `force_mapping` keyword. It's not clear from the name why you would want it.

*If* we want to do this, I think the solution is to actually deprecate the current behavior of ufuncs in `apply` and instruct people to use `.pipe(ufunc)` rather than `.apply(ufunc)`. But I'm not sure right now if it's worth the churn.
I agree with @TomAugspurger here, would be ok with showing a `PerformanceWarning`, but unlikely to be able to change / deprecate this behavior and cannot kill performance like this.
What do you mean by showing ``PerformanceWarning``? Where should be this warning included?
Should I provide better parameter name and description? or are you completely against idea behind that PR?
> What do you mean by showing `PerformanceWarning`? Where should be this warning included?
> Should I provide better parameter name and description? or are you completely against idea behind that PR?

we are -1 on adding any options to this function. you cannot simply *change* the way something like this works w/o showing the perf benefit (or drag in this case). I suspect this is likely going to be bad.

So the only way this could possibly go forward is to detect cases where this is likey to be used (e.g. using a ufunc on an object dtype), then dispatch that way. You might need to then show a `PerformanceWarning` in that case.
@jreback do you have a preference for `PerformanceWarning` vs. deprecating the current behavior. IMO, deprecating the current behavior is the best option: We *don't* slow down people's code immediately. Gives them time to update their code from `.apply(np.sin)` to `.pipe(np.sin)`.

The downside is that we can't fix the bug immediately. But IMO not slowing down this code without warning is more important than fixing the bug that (I think) only shows up for nested data.
I don’t think we should change this at all including deprecation
closing this as I don't see positions changing here. If you want to raise an issue and get consensus on a change okie dokie.