Here is a temporary solution that you're probably already aware of: (essentially a re-write of _get_default_session())

def my_func(arg1, arg2, session=None):     
    if not session:        
        if boto3.DEFAULT_SESSION is not None:      
            session = boto3.DEFAULT_SESSION      
        else:      
            session = boto3.setup_default_session()     

I'm new to the project and had to do some digging, but it appears that DEFAULT_SESSION is initialized in the setup_default_session() function. If it is not initialized, the first if statement should fail, leading you to the setup_default_session() function without worry of overwriting some already existing custom value.

This is a temporary fix I know, and I'm there with you, _get_default_session() should be public.

Hopefully this helps, please let me know if there's anything I missed!

I just use boto3._get_default_session() directly; "private" in Python is a naming convention, not an enforced boundary, and it's very unlikely that this particular function itself would get removed or changed in a breaking way, so I am comfortable relying on it. Making it public (and documented) would indicate to users that there is a standard way to retrieve the cached default session (I'd argue it makes more sense to have a public get_default_session() and setup_default_session() and a private _DEFAULT_SESSION, but that's not a feasible change to make).

I'm primarily a C programmer, so I didn't even think twice about the mention of private/public! I believe this is a primary reason as to why I love to attempt to assist others on Stack Overflow and GitHub, I end up learning a lot myself! It seems as though private and public is, like you say, for documentation, much like ':' in parameters and '->' in function declarations. I'm curious why the Boto package doesn't use these operators for further documentation? Perhaps the extensive use of pointers makes it unnecessary? Thank you Ben, and my earlier comment has been modified to show the changes I should've noticed myself.

Type hints were introduced in Python 3.5 (see PEP 484). boto3 currently still supports Python 2.7, and the code would have a syntax error in 2.7 if there were type hints. While support for Python 3.4 and 3.5 is ending, and Python 2.7 is officially at its end of life, I have not seen that boto3 intends to remove support for it yet.

You can add type annotations in your own code using the 3rd party boto3_type_annotations library.

Is this still being considered?

I'd still love to see it!

I would still love to see this! It's a minor change, but means a lot stylistically in production settings. The change in the linked pull request would not break existing code due to aliasing.

If the feature is not being considered at all, it would be great to hear a rationale or something.