[weasyprint] Add stubs for WeasyPrint 69.0

[TuringTux]

This adds a really small set of annotations for WeasyPrint 68.0.

I use WeasyPrint in one of my projects, use only a few methods, but would like to have my type checker working for these.

Is it okay if a submit this to typeshed, even though it will be only partially annotated?

[srittau]

Is it okay if a submit this to typeshed, even though it will be only partially annotated?

Yes, that's perfectly fine.

[TuringTux]

Thanks for the quick reply! Then I will see to it that at least my use case is completely mapped (and the checks run green, I suppose), and would then change this PR to ready.

[TuringTux]

Well, I haven't forgotten about this, and funnily enough, today the organisation behind WeasyPrint sort of doubled down on the fact they don't like type hints: https://www.courtbouillon.org/blog/00064-types/

Meaning this PR could become very relevant if I ever get the time to implement something, which I still hope I do soon-ish.

[liZe]

Hi!

WeasyPrint has a pretty stable, official public API. All the other functions are not supposed to be used by WeasyPrint users, and regularly break between versions.

I don’t know what the best solution is in this case, but I think that adding type hints only for this public API is probably easier and better.

[TuringTux]

That would also be sufficient for me. The current state of this PR is auto-generated, by the tool provided in the Typeshed repo. Does that mean I could remove a lot of the current files, and only include those corresponding to the Python files containing the public API?

[liZe]

That would also be sufficient for me. The current state of this PR is auto-generated, by the tool provided in the Typeshed repo. Does that mean I could remove a lot of the current files, and only include those corresponding to the Python files containing the public API?

I think so.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[srittau]

A hint to maybe help this get over the finish line: I've just opened #16011 to add some guidance about missing dependencies. For your convenience, I've copied it here:

---

When a third-party stub package depends on another package, there are several
strategies available, depending on whether the other package is typed.

1. If the other package is typed and includes a py.typed marker, add that
   package to the dependencies key in `METADATA.toml. This might fail the
   stub uploader checks, in which case you can ask the maintainers for help.

2. Otherwise, if a type package is available, add that package to the
   dependencies key. If the type package originates from typeshed, the
   stub uploader checks should succeed.

3. In case the dependency in untyped and no stubs are available, you may stub
   the dependency in your type stubs. For example:

   from typing import Any
   # from fruzzle import Frobnicator  # won't work
   
   _Frobnicator: TypeAlias = Any  # actually fruzzle.Frobnicator

   In more complex or advanced cases you may instead opt to add a stubs
   is a separate helper package:

   # stubs/my-stubs/my_stubs/_fruzzle.pyi
   
   # Utility stubs for the untyped "fruzzle" package.
   
   from typing import Any, Protocol
   
   Frobnicator: TypeAlias = Any
   
   class Flubberer(Protocol):
       def flubb_it(self, x: int, /) -> str: ...