Python and dependency bounds illustration

[markcampanelli]

At this point this PR is for illustration only. Things to add/update would be:

• Adding Python 3.13 to the test matrix.
• A dependency management policy in the documentation. (See Python 3.13 preparation #2201 (comment))
• Look into any changes/simplifications in CI that might be possible by calling out the Python upper limits in the optional dependencies.
• timetimezones.rst would be revised to use the standard library's timezone package instead of pytz, which is still used by pandas. Moved to Replace pytz with standard library's zoneinfo #2343

• Closes #xxxx (Inspired by Python 3.13 preparation #2201)
• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

[echedey-ls]

Could you put the changes relative to zoneinfo into another PR?
I have the gut feeling one of the proposals will be more controversial than the other, and it's easier to follow a conversation on a proposal than on many at the same time.

[markcampanelli]

Could you put the changes relative to zoneinfo into another PR? I have the gut feeling one of the proposals will be more controversial than the other, and it's easier to follow a conversation on a proposal than on many at the same time.

@echedey-ls Thanks for your patience and feedback as I learn how to best present my ideas to others in digestible chunks. I will split these two ideas up even though they originally came to me together :).

Question: Should I label/communicate my “demonstration/experimental” PRs with something other than [DRAFT]?

[echedey-ls]

Question: Should I label/communicate my “demonstration/experimental” PRs with something other than [DRAFT]?

You can set them as drafts, there is a button on top right of the PR page, in the reviewers box, that says "Convert to draft". When you first open them, in the Open PR button there is dropdown to select Open as draft. Said that, it's not that important. Here in pvlib there is no convention, neither for the titles. I like to use the brackets so I can browse my PRs easier. Feel free to find what works best for you and be comfortable with your development procedures.

@echedey-ls Thanks for your patience

Thanks to you for proactively raising awareness of the user's needs.

[markcampanelli]

@echedey-ls Please forgive the bigger diff than perhaps necessary in the pyproject.toml. I'm a stickler for alphabetizing dependencies, imports, etc.