create monkeypatching function for adding get_item dunder

[ghost]

i have made things!

related issues

closes #507

refs #504, #515

wasn't too sure about the best way to implement this, so i figured i'd make a draft and ask your thoughts

[ghost]

if this is good, i'll add in the rest of the stuiff from #504 and #515

[sobolevn]

Awesome! Thank you!

The most interesting question is: how should we distribute this code?
By that I mean:

1. We can ship it with django-stubs package, but this way we would have to add django-stubs to direct dependencies (not dev-dependencies). And this will also add our dependencies as transitive ones:

   django-stubs/setup.py

   Lines 23 to 27 in aab8acf

   	dependencies = [
   	"mypy>=0.790",
   	"typing-extensions",
   	"django",
   	]

   I guess many people might not want mypy to be their direct dependency 🤔

2. We can create a new package a keep it in sync with django-stubs. It won't have any dependencies at runtime, but this will complicate our tooling and setup. I am not sure if Python has a concept of monorepos.

I would love to hear a feedback on this 👍

[ghost]

oh look, my favorite part of programming, real world complications!

i think a monorepo is best. if someone makes a class generic, they'd have to submit pull requests to two different repositories, and that just seems way too much for everyone involved. i think a directory structure like this might be best:

.
├── dev-requirements.txt
├── django-source
├── django-stubs
├── django_stubs_ext
│   ├── django_stubs_ext
│   │   └── [code goes here]
│   ├── setup.py
│   └── etc., etc.
├── setup.cfg
├── setup.py
└── etc., etc.

and then when releases happen, just push both to pypi

[sobolevn]

One more thing to consider: #262

At some point in time we plan to support different versions of django, well, differently.
So, this "patcher" thing should be dependent to stubs in different versions.

The good thing is that we are free to patch more classes to be Generic that we actually need.

[ghost]

i don't think multiple versions would be too difficult with this. make the __need_generic list contain tuples with a version restriction:

__need_generic: List[Tuple[str, Type[Any]]] = [
    ('3', FormMixin),
    ('2', SomeClass),
    ('', VersionIndependentClass),
]

filter(lambda x: str(django.VERSION[0]) == x[0] or x[0] == '', __need_generic)

although i'm sure a more sophisticated solution would also work

[ghost]

first time writing an actual package, let me know if it looks alright?

i basically copied everything from the root package and deleted what wasn't necessary, then added django_stubs_ext as a requirement to the root package

[sobolevn]

Thanks a lot!

[ghost]

don't merge just yet, i still need to add the rest of the generic patches :p

[ghost]

alright, i think i'm all set on my end. i can't think of anything else i would want to add or update. does this look good to everyone else?

[ghost]

writing a release script for it

[sobolevn]

Thanks a lot! Let's merge it! 👍

[ghost]

ayyyy fantastic! thanks for the help through all of this :)

[NyanKiyoshi]

Couldn't this rather be put as an extra dependency? For example, like so:

setup(
    ...,
    # or another name/way of doing
    extras_require={"full": ["django-stubs-ext"]},
)

Then users could run pip install django-stubs[full] (or the other way around, have full by default and minimal for people that want the minimal, i.e. no monkey patching)

This would prevent adding additional files and dependencies that are not required.

[sobolevn]

It is a direct dependency, but you can just ignore it completely. It does not get easier that that.

[ghost]

i'm not sure the savings of a relatively small package are worth the possibility of library consumers accidentally missing the [full] part of the install step and wondering what's wrong

i do have a bug report in the mypy repo about this, but it's seen no activity in almost half a year, so i'm not sure we should hold our breath haha