Renaming the project to be boto3-stubs for MyPy compatibility.

[cowboygneox]

Following MyPy's requested format documented in PEP 561, I renamed the main module per the mandated naming scheme. When used with MyPy, this actually works quite well. However, I currently do have to ignore one directive that I can take a swing at implementing next:

import boto3 # type: ignore

Everything else works well. Example that works in MyPy:

from boto3 import sts
sts_client: boto3.sts.Client = boto3.client(service_name='sts')

I don't expect this kind of rename to be accepted as-is, but if I receive some notes on how to make this kind of change, please let me know and I will make the changes so this can get into the mainline.

[cowboygneox]

I really appreciate this project and I look forward to consideration on this pull request.

[afarbos]

Related to #6
That would a really nice enhancement!

[alliefitter]

Wow, thanks for bringing this to my attention. I wasn't aware of this PEP. It pretty much changes the game. I'm thinking that we could just check in a new custom build with the package name as boto3-stubs and then upload it, as well. Just so we don't break anyone with who's using boto3_type_annotations or boto3_type_annotations_with_docs. The config would look something like:

boto3_type_annotations/configs/boto3-stubs.yaml

services: all
with_docs: false
with_clients: true
with_service_resources: true
with_paginators: true
with_waiters: true
package_name: boto3-stubs
module_name: boto3-stubs
version: 0.3.1
readme: "../README.md"
license: "../LICENSE"

Then this repo would have boto3_type_annotations, boto3_type_annotations_with_docs, and boto3-stubs side by side, all three being separate packages on PyPI.

It does looks like the Python foundation wants me to contact AWS first to see if they want to add it to boto3 somehow.

Third parties seeking to distribute stub files are encouraged to contact the maintainer of the package about distribution alongside the package. If the maintainer does not wish to maintain or package stub files or type information inline, then a third party stub-only package can be created.

I'll go ahead and open an issue on boto3's github, and see what they have to say. But I can't imagine that they'd want to add this in.

I'm gonna try to work on this tonight. I'll tag ya'll in the commit so we can discuss. I say "try" because there's a hurricane heading straight for me right now and my power goes out when it drizzles. I should be good tonight, but might be without electricity this weekend.

[alliefitter]

Made the issue on boto3.

[alliefitter]

@cowboygneox just pulled down your fork and ran your example. Sorry for the language, but this is fucking slick, man. I like this workflow a lot better than the current one. Looks like I'll have to change the build scripts to include all of boto3's functions and sub packages. PyCharm's showing an error saying boto3.client doesn't exist

import boto3
from boto3 import sts

sts_client: sts.Client = boto3.client(service_name='sts')

[cowboygneox]

@alliefitter I appreciate the compliment. This is why we open source our work so that we can all benefit from a combined effort.

As for the PyCharm showing an error that boto3.client doesn't exist, I don't have the same problem. I have had issues in the past with PyCharm's interpreter setup, so I would start there.

If you'd like, I could make a scratch project that has this working so you can open it and see if it's environmental.

[d33tah]

@cowboygneox Thanks for his PR! I tried it out though and failed to produce a working SQS example. Consider this:

import boto3  # type: ignore
from boto3 import sqs
sqs_client: int = boto3.client(service_name='sqs')

mypy --strict test.py doesn't complain about wrong typing and running the script directly tells me that boto3.sqs is not defined. Is SQS supported?