Update maximum_subarray.py

[pronoym99]

1. Rectify documentation to indicate the correct output: function doesn't return the subarray, but rather returns a sum.
2. Make the function more Pythonic and thereby avoid:
   • any unnecessary if statements.
   • usage of non - optimal in range(len()) constructs.
3. Make function annotation generic i.e. can accept any sequence nums.
4. Raise value error when the input sequence nums is empty.

Describe your change:

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

[pronoym99]

I would suggest you add a hacktoberfest label to this PR.

[cclauss]

maximum_subarray solves one problem and maximum_subarray_sum solves a different one. It sounds like a bad idea to me to destroy an existing algorithm in order to solve a different problem.

[pronoym99]

I think you are mistaken: maximum_subarray was incorrectly documented as returning an array as opposed to a sum. I have rectified the same. It was still solving the maximum_subarray_sum problem only. I haven't made any changes in the actual logic as a result. If you would like to have a completely different file with a different name for the same, I shall do so.

[pronoym99]

1. Followed conventions as given in pep-0257
2. Initialised the current_maximum and ans to negative infinity and returned an answer cast to an integer. This makes the code constant in memory and avoids using an additional module i.e. itertools for such a simple implementation.

[Cjkjvfnby]

Personally, I don't like using inf. It adds a bit of noise with float/int types. Maybe get back to the simple range?

    for i in range(1, len(nums)):
        num = nums[i]

(not a blocker for merge)

[pronoym99]

Personally, I don't like using inf. It adds a bit of noise with float/int types. Maybe get back to the simple range?

    for i in range(1, len(nums)):
        num = nums[i]

(not a blocker for merge)

True that even I don't like the additional noise and what I did seems like patchwork. So have done the requested change. Do note that this change would lead to a constant access cost for every nums[i].

[Cjkjvfnby]

Thank you.

Looks like we could remove int() now and after it's good for merge.

[pronoym99]

Now we are good to go for the merge. Don't forget to add the hacktoberfest label to this PR :^)

[pronoym99]

Can anyone of you @Cjkjvfnby, @CaedenPH or @cclauss finally merge this PR into the main branch ?