Mailing List Archive

On Tue, Nov 30, 2021 at 02:30:18PM +0000, Paul Moore wrote:

> And to be clear, it's often very non-obvious how to annotate something
> - in https://github.com/pfmoore/editables I basically gave up because
> I couldn't work out how to write a maintainable annotation for an
> argument that is "a Path, or something that can be passed to the Path
> constructor to create a Path" (it's essentially impossible without
> copy/pasting the argument annotation for the Path constructor).

I thought that type inference was supposed to solve that sort of
problem? If the typechecker can see that an argument is passed to the
Path constructor, it should be able to infer that it must be the same
types as accepted by Path.

Aside: I'm a little disappointed in the way the typing ecosystem has
developed. What I understood was that we'd get type inference like ML or
Haskell use, so we wouldn't need to annotate *everything*, only the bits
needed to resolve ambiguity. But what we seem to have got is typing like
C, Pascal and Java, except gradual. Am I being unreasonable to be
disappointed? I'm not a heavy mypy user, I just dabble with it
occasionally, so maybe I've missed something.



> Anyway, we're *way* off topic now, and I doubt there's much that the
> SC or python-dev can do to change the community view on typing,
> anyway.

Heh. We could update PEP 8 to ban type annotations, then watch as the
people who over-zealously apply PEP 8 to everything AND over-zealously
insist on adding type annotations to everything have their heads
explode.


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y6GOWIZV5JCOG5TP4ZZ4SVLXL4BGDJTI/
Code of Conduct: http://python.org/psf/codeofconduct/

This is great Patrick, thanks.

My use case is similar to Patrick's, except it builds on dataclasses
directly:

It's part of a larger system, but I've just pulled it out into its own
poorly documented and poorly tested package:

https://github.com/PythonCHB/flexi

(I think it's generally useful, so may one day make a proper package out of
it)

Anyway, the principle is this:

The goal is to have a flexible data model that enforces the structure, but
not necessarily the validity of values, or even types. This is useful
because we need to store / edit / import complex hierarchy of data, and we
very much don't want to have all of it to have to be valid in order to even
store it. An example is a dataset we recently imported (from
spreadsheets--arrgghh), where in a thousand records, they had put "too
viscous to measure" instead of a value for interfacial tension. That, of
course, would be helpful to a person reading the spreadsheet, but would
have been a pain if we had enforced that that field had to be a float > 0.
Instead, it imported fine, and then our validation code flagged the issue
to be fixed later. And all the rest of the data could be used in the
meantime.

Anyway, that was a digression (but explains why we don't use Pydantic).
Functionally, we need the "nodes" in the data model to be able to convert
themselves to/from JSON compatible Python, and validate themselves, etc.
This is done by using the actual type object, as stored in
dataclasses.Field.type

This has worked nicely for us, and dataclasses saved us a lot of
boilerplate code.

if we do

from future import Annotations

then the system breaks, as we have a string instead of the actual type that
is needed.

Solutions:

I *think* PEP 649 would work fine for us, as the annotation would get
evaluated when it was added to the field object.

But inspect.get_annotations isn't really helpful for this use, as the
Field.type attributes aren't annotations anymore. So we would have to
eval() the strings ourselves, and I think it would be unclear what
namespaces to use for that.

If dataclasses were to use

inspect.get_annotations(cls, eval_str=rue)

in order to extract the types to put into the Field objects, then I think
all would be good for us. And as I understand it, dataclasses itself
doesn't do anything with that attribute anyway.

If that's not decided to be a good thing for dataclasses, then I think we'd
have to re-implement a lot ourselves, though it could probably be hacked
in - I haven't tried that yet.

BTW, I don't think we've heard from the attrs (and especially cattrs) folks
in this thread. A search of the repo issues indicates that there has been
some discussion of PEP 563's impact, but it's not totally clear to me if
it's been resolved.

-CHB


--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On 11/26/21 1:13 AM, Paul Moore wrote:
> On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote:
>>
>> My memory is also hazy, but I'm quite sure that *in my mind* annotations were
>> intended as a compromise between conflicting proposals for *typing*. We didn't
>> have agreement on the syntax or semantics, but we did know we wanted to do
>> something with types eventually.
>
> More hazy memories here, but I think the original proposal left open
> the possibility of annotations not being types at all - for example,
> being docstrings for the arguments, or option names for a "function
> call to CLI" tool, etc. I think that some libraries took this approach
> (in particular the "CLI builder" idea).

I have one such tool. Fortunately for me, I strongly dislike having the annotations inside the function header as it
quickly gets difficult for me to read, so I was already using decorator syntax for the annotations. When PEP 484 was
accepted I just changed where the annotations were being stored from __annotations__ to my own dunder.

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VC6NSJ4MXJOTNBKO7OOBSV7JHQ5JBPLO/
Code of Conduct: http://python.org/psf/codeofconduct/

Am 30.11.21 um 13:39 schrieb Oscar Benjamin:
> Others have mentioned the pressure on libraries to adopt typing and
> I've certainly noticed this with SymPy. I think type hints could be
> good for SymPy for internal use but it seems that a lot of users want
> it for external reasons that I don't always understand but that also
> seems to come partly from editors as well.

Please note that users of you library usually won't care that the
library uses type hints. It's more important that there are type hints
for the API, which can also be supplied using a stub file.

> Some people apparently want to add type hints that look completely
> useless to me like
> def f() -> Union[MyClass, Any]
> As I understand it this does not give any meaningful information to a
> type checker but it apparently makes vscode work better:
> https://github.com/sympy/sympy/pull/22180#discussion_r718917577

We have several resources that can help with questions like these:

* https://github.com/python/typing/discussions is a forum for
questions about typing.
* The forum also has a separate section where users can ask for
reviews of type annotations, for example in stub files.
* https://gitter.im/python/typing is a chat for typing-related questions.

We are also working on a documentation hub at
https://typing.readthedocs.io/, but there is not much to see at the moment.

> There are other open "issues" like this for SymPy where the
> presumption is that not having type hints is now to be considered a
> deficiency of the library regardless of whether the hints have any
> benefit for internal use. I don't object to adding the hints but it's
> a huge amount of work that someone would have to do and I don't want
> to add useless/inaccurate hints temporarily (as some have suggested to
> do).

Please note that users of you library usually won't care that the
library uses type hints. It's more important that there are type hints
for the API, which can also be supplied using a stub file. This is
usually quite a bit easier than typing an existing code base.
Alternatively, just adding type annotations to the public API, but not
using type checking yourself, can be useful for your users.

 - Sebastian

On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau <srittau@rittau.biz> wrote:

> Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file.

I tried that route, but I was informed that if I do that, mypy will
not check my stubs against the source code. Which means that there's
no easy way of testing that the stubs are correct - is that accurate?

Paul

PS I appreciate the links you posted to various typing forums, but IMO
the most critical missing resource is a central set of typing
documentation that includes examples, FAQs and best practices as well
as reference materials. Typically when I hit an issue with types, I
want to research my own solution, not ask a question, which requires
me to bother other people, as well as interrupting my flow while I
wait for a response. I'd much rather see work being done on
documenting what we currently have in typing, rather than yet more
changes which while no doubt useful, is effectively just churn that
makes maintaining a codebase that has to support multiple Python
versions harder.

PPS Sorry if this sounds negative. TBH, I'd quite happily not use
typing if I didn't want to and stay quiet. A lot of the frustration I
see being expressed here (including my own) seems to come from the
fact that it's so difficult to actually take that sort of "I can
ignore it if I don't use it" attitude, whether that's because of
community pressure, tool requirements, or whatever.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LAR7R5MCAC74N7H7NQXJUGXG7LCOA4CB/
Code of Conduct: http://python.org/psf/codeofconduct/

On 2021-11-30 09:01, Steven D'Aprano wrote:
>
> Heh. We could update PEP 8 to ban type annotations, then watch as the
> people who over-zealously apply PEP 8 to everything AND over-zealously
> insist on adding type annotations to everything have their heads
> explode.
>

Captain Kirk would be proud:

https://memory-alpha.fandom.com/wiki/Induced_self-destruction

-Mike


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/D464YHCBENUCEF6E7E77EKVLPG2JY5WT/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 1 Dec 2021 at 12:12, Sebastian Rittau <srittau@rittau.biz> wrote:
>
> Am 30.11.21 um 13:39 schrieb Oscar Benjamin:
>
>> Others have mentioned the pressure on libraries to adopt typing and
>> I've certainly noticed this with SymPy. I think type hints could be
>> good for SymPy for internal use but it seems that a lot of users want
>> it for external reasons that I don't always understand but that also
>> seems to come partly from editors as well.
>
> Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file.

The distinction between internal code and API is not always that clear
in SymPy but in any case it is still very hard to type many of SymPy's
public API functions. You are right that there is a distinction here
because when I imagine that type hints could be useful for SymPy I
think of adding hints in places that users definitely don't care
about. Adding hints for public API is more immediately useful for
users but also much harder because many public APIs are quite
liberal/flexible in what they accept and return.

>> Some people apparently want to add type hints that look completely
>> useless to me like
>> def f() -> Union[MyClass, Any]
>> As I understand it this does not give any meaningful information to a
>> type checker but it apparently makes vscode work better:
>> https://github.com/sympy/sympy/pull/22180#discussion_r718917577
>
> We have several resources that can help with questions like these:
>
> https://github.com/python/typing/discussions is a forum for questions about typing.
> The forum also has a separate section where users can ask for reviews of type annotations, for example in stub files.
> https://gitter.im/python/typing is a chat for typing-related questions.
> We are also working on a documentation hub at https://typing.readthedocs.io/, but there is not much to see at the moment.

I'm not sure what your point is here. Are you suggesting that I use
these forums or that I redirect other people there?

>> There are other open "issues" like this for SymPy where the
>> presumption is that not having type hints is now to be considered a
>> deficiency of the library regardless of whether the hints have any
>> benefit for internal use. I don't object to adding the hints but it's
>> a huge amount of work that someone would have to do and I don't want
>> to add useless/inaccurate hints temporarily (as some have suggested to
>> do).
>
> Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file. This is usually quite a bit easier than typing an existing code base. Alternatively, just adding type annotations to the public API, but not using type checking yourself, can be useful for your users.

My previous statement still stands: it's a huge amount of work and I
do not want to add bogus hints as a stopgap. If the hints are to be
added then someone needs to do that hard work to make sure that they
are accurate.

--
Oscar
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UWG2SVMAHLPOPR25DESC4GCD6TKSQPFB/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano <steve@pearwood.info> wrote:

> On Tue, Nov 30, 2021 at 02:30:18PM +0000, Paul Moore wrote:
> [...]
> Aside: I'm a little disappointed in the way the typing ecosystem has
> developed. What I understood was that we'd get type inference like ML or
> Haskell use, so we wouldn't need to annotate *everything*, only the bits
> needed to resolve ambiguity. But what we seem to have got is typing like
> C, Pascal and Java, except gradual. Am I being unreasonable to be
> disappointed? I'm not a heavy mypy user, I just dabble with it
> occasionally, so maybe I've missed something.
>
> You might be more comfortable with pytype, which I understand is much more
inferential than pypy.

>
> > Anyway, we're *way* off topic now, and I doubt there's much that the
> > SC or python-dev can do to change the community view on typing,
> > anyway.
>
> Heh. We could update PEP 8 to ban type annotations, then watch as the
> people who over-zealously apply PEP 8 to everything AND over-zealously
> insist on adding type annotations to everything have their heads
> explode.
>
> Cruel, but funny.

Am 01.12.21 um 13:36 schrieb Paul Moore:
> On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau <srittau@rittau.biz> wrote:
>
>> Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file.
> I tried that route, but I was informed that if I do that, mypy will
> not check my stubs against the source code. Which means that there's
> no easy way of testing that the stubs are correct - is that accurate?

mypy includes a "stubtest" tool that compares a stub to introspected
runtime data. We use it in typeshed as part of the CI process and it's a
very powerful tool to help keeping stubs up-to-date and correct.


> PS I appreciate the links you posted to various typing forums, but IMO
> the most critical missing resource is a central set of typing
> documentation that includes examples, FAQs and best practices as well
> as reference materials.

Completely agree. This is what typing.readthedocs.io is supposed to
become, but time constraints mean that it's very incomplete at the moment.

> PPS Sorry if this sounds negative. TBH, I'd quite happily not use
> typing if I didn't want to and stay quiet. A lot of the frustration I
> see being expressed here (including my own) seems to come from the
> fact that it's so difficult to actually take that sort of "I can
> ignore it if I don't use it" attitude, whether that's because of
> community pressure, tool requirements, or whatever.

I completely understand this pressure, especially for library authors.
Providing high quality stubs and the best user experience is not easy.
But I believe that referring people to typeshed can help. While we of
course prefer high quality stubs or type annotations shipped with the
package in question, typeshed can provide a fairly low barrier of entry
for projects that don't have the resources to maintain type annotations
themselves. It can also be used as an "incubator", where stubs are
created and improved iteratively, until they are deemed ready for
inclusion in an upstream package.

 - Sebastian

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3Z7MCNNQUH3S5IWXA5MXVAUKPYYWKFZO/
Code of Conduct: http://python.org/psf/codeofconduct/

>for library authors.

> Providing high quality stubs and the best user experience is not easy.
> But I believe that referring people to typeshed can help.


This is actually very helpful. It provides an answer for open source
projects for which do users want typing.

One can say to the users that want type stubs for the library that they are
encouraged to contribute those stubs to type shed themselves and once they
have been tested and vetted they can be included in the project.

it’s not unlike any other feature request. The developer of an open source
project is under no obligation to provide any feature asked for, but a
well-managed project will encourage useful contributions from users.

-CHB
--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

I assume you accidentally pressed Send prematurely.
Still, maybe you have inadvertently listed everything that is agreed
about typing PEPs. ????
Rob Cliffe

On 02/12/2021 23:20, Christopher Barker wrote:
>
> >for library authors.
>
> Providing high quality stubs and the best user experience is not
> easy.
> But I believe that referring people to typeshed can help.
>
>
> This is actually very helpful. It provides an answer for open source
> projects for which do users want typing.
>
> One can say to the users that want type stubs for the library that
> they are encouraged to contribute those stubs to type shed themselves
> and once they have been tested and vetted they can be included in the
> project.
>
> it’s not unlike any other feature request. The developer of an open
> source project is under no obligation to provide any feature asked
> for, but a well-managed project will encourage useful contributions
> from users.
>
> -CHB
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
> _______________________________________________
> Python-Dev mailing list --python-dev@python.org
> To unsubscribe send an email topython-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived athttps://mail.python.org/archives/list/python-dev@python.org/message/ASO2PUTECTOB25HC7DURFOGOHOUQOCD5/
> Code of Conduct:http://python.org/psf/codeofconduct/

@Paul

> ... missing resource is a central set of typing documentation that
includes examples, FAQs and best practices as well as reference materials

Like Sebastian, I agree, and this is something we're making progress on.

> ... easy way of testing that the stubs are correct

mypy ships with a tool called stubtest. It's what typeshed uses to validate
itself against CPython. I recently wrote up documentation for it, see here:
https://mypy.readthedocs.io/en/latest/stubtest.html

> A lot of the frustration I see being expressed here (including my own)
seems to come from the fact that it's so difficult to actually take that
sort of "I can ignore it if I don't use it"

Thanks for not staying quiet and helping us make typing better. In
particular, I think one takeaway from this thread is that a lot of our
documentation is focussed on "how to get started with typing my code", and
not much addressed at library authors with limited time to deal with typing
questions (like "what is a PEP 561" and "if my type hints are incomplete
does that cause problems for my users")

On Thu, 2 Dec 2021 at 15:34, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> I assume you accidentally pressed Send prematurely.
> Still, maybe you have inadvertently listed everything that is agreed about
> typing PEPs. ????
> Rob Cliffe
>
> On 02/12/2021 23:20, Christopher Barker wrote:
>
>
> >for library authors.
>
>> Providing high quality stubs and the best user experience is not easy.
>> But I believe that referring people to typeshed can help.
>
>
> This is actually very helpful. It provides an answer for open source
> projects for which do users want typing.
>
> One can say to the users that want type stubs for the library that they
> are encouraged to contribute those stubs to type shed themselves and once
> they have been tested and vetted they can be included in the project.
>
> it’s not unlike any other feature request. The developer of an open source
> project is under no obligation to provide any feature asked for, but a
> well-managed project will encourage useful contributions from users.
>
> -CHB
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ASO2PUTECTOB25HC7DURFOGOHOUQOCD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7AF22G3S23S67FAHH7BI4XUNHWOU4YXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

resent -- damn iPhone!

On Thu, Dec 2, 2021 at 3:20 PM Christopher Barker <pythonchb@gmail.com>
wrote:

> >for library authors.
> >
> > Providing high quality stubs and the best user experience is not easy.
> > But I believe that referring people to typeshed can help.
>
>
> This is actually very helpful. It provides an answer for open source
> projects for which do users want typing.
>
> One can say to the users that want type stubs for the library that they
> are encouraged to contribute those stubs to type shed themselves and once
> they have been tested and vetted they can be included in the project.
>
> it’s not unlike any other feature request. The developer of an open source
> project is under no obligation to provide any feature asked for, but a
> well-managed project will encourage useful contributions from users.
>
> -CHB



> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
>


--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On Thu, Dec 2, 2021 at 3:35 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> I assume you accidentally pressed Send prematurely.
>

Actually, it was my phone making the text white -- what the heck?

why is it so hard to send plain text email?

resent now.

-CHB



> Still, maybe you have inadvertently listed everything that is agreed about
> typing PEPs. ????
> Rob Cliffe
>
> On 02/12/2021 23:20, Christopher Barker wrote:
>
>
> >for library authors.
>
>> Providing high quality stubs and the best user experience is not easy.
>> But I believe that referring people to typeshed can help.
>
>
> This is actually very helpful. It provides an answer for open source
> projects for which do users want typing.
>
> One can say to the users that want type stubs for the library that they
> are encouraged to contribute those stubs to type shed themselves and once
> they have been tested and vetted they can be included in the project.
>
> it’s not unlike any other feature request. The developer of an open source
> project is under no obligation to provide any feature asked for, but a
> well-managed project will encourage useful contributions from users.
>
> -CHB
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ASO2PUTECTOB25HC7DURFOGOHOUQOCD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7AF22G3S23S67FAHH7BI4XUNHWOU4YXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

So maybe this is my time to chime in. I have used annotations for runtime
behavior. My primary use case is an injection library that I wrote. It allows
something along the lines of:

class IMyService(IService):
pass

@inject
def call_something(arg1: str, arg2: int, svc: IMyService = None):
assert svc is not None
# do stuff...

At runtime the `inject()` decorator will scan the function signature and
insert an instance of `IMyService` based on a registry lookup. (We use
zope.component utilities, but that's an implementation detail.) When testing,
one can simply pass a mock version of the service.

Using the mypy-zope plugin, the above also passes all mypy type checking.

It is a simple pattern in terms of annotation but a very effective pattern
that mimics other injection systems in Java and TypeScript (Angular). We have
used it for a few years now and like it a lot.

Regards,
Stephan

On Monday, November 29, 2021 6:00:04 PM EST Barry Warsaw wrote:
> On Nov 26, 2021, at 01:13, Paul Moore <p.f.moore@gmail.com> wrote:
> > I'd therefore interpret Barry's plea as being for *anyone* with a use
> > for annotations to provide their feedback (at least, anyone who
> > accepts that annotations are types), with particular emphasis on
> > people who want to use the types declared in annotations to affect
> > runtime behaviour, as that's the most under-represented group at the
> > moment (and it's not clear whether it's under-represented because
> > there aren't many such uses, or because the users aren't being heard
> > from).
>
> Spot on.
>
> -Barry


--
Stephan Richter
Entrepreneur & Geek


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XRJJ4ZMOQJXOTRFT3FQ25QXHXOKBVXKP/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Dec 2, 2021 at 6:57 PM Stephan Richter <stephan.richter@gmail.com>
wrote:

> So maybe this is my time to chime in. I have used annotations for runtime
> behavior. My primary use case is an injection library that I wrote.


Does it work with __future__ annotations?

-CHB





> It allows
> something along the lines of:
>
> class IMyService(IService):
> pass
>
> @inject
> def call_something(arg1: str, arg2: int, svc: IMyService = None):
> assert svc is not None
> # do stuff...
>
> At runtime the `inject()` decorator will scan the function signature and
> insert an instance of `IMyService` based on a registry lookup. (We use
> zope.component utilities, but that's an implementation detail.) When
> testing,
> one can simply pass a mock version of the service.
>
> Using the mypy-zope plugin, the above also passes all mypy type checking.
>
> It is a simple pattern in terms of annotation but a very effective pattern
> that mimics other injection systems in Java and TypeScript (Angular). We
> have
> used it for a few years now and like it a lot.
>
> Regards,
> Stephan
>
> On Monday, November 29, 2021 6:00:04 PM EST Barry Warsaw wrote:
> > On Nov 26, 2021, at 01:13, Paul Moore <p.f.moore@gmail.com> wrote:
> > > I'd therefore interpret Barry's plea as being for *anyone* with a use
> > > for annotations to provide their feedback (at least, anyone who
> > > accepts that annotations are types), with particular emphasis on
> > > people who want to use the types declared in annotations to affect
> > > runtime behaviour, as that's the most under-represented group at the
> > > moment (and it's not clear whether it's under-represented because
> > > there aren't many such uses, or because the users aren't being heard
> > > from).
> >
> > Spot on.
> >
> > -Barry
>
>
> --
> Stephan Richter
> Entrepreneur & Geek
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XRJJ4ZMOQJXOTRFT3FQ25QXHXOKBVXKP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On Fri, 3 Dec 2021 at 00:10, Shantanu Jain <hauntsaninja@gmail.com> wrote:
>
> @Paul
>
> > ... missing resource is a central set of typing documentation that includes examples, FAQs and best practices as well as reference materials
>
> Like Sebastian, I agree, and this is something we're making progress on.

That's great to know - it's easy for me to say "we need more docs" but
I know it's hard to produce them. I'm glad it's on the radar :-)

> > ... easy way of testing that the stubs are correct
>
> mypy ships with a tool called stubtest. It's what typeshed uses to validate itself against CPython. I recently wrote up documentation for it, see here: https://mypy.readthedocs.io/en/latest/stubtest.html

Thanks, I wasn't aware of that. Although TBH I like the suggestion of
using typeshed as a kind of staging point for interested users to
develop annotations, which can then be moved back into the library
once they've been proven stable.

I'm still surprised that mypy doesn't check stub files though. If I
write stubs for my external API, and then later decide I want to add
types to my internal functions, to do static checking on my library,
am I therefore required to move the annotations out of the stub file
into the main code? What if I want to avoid the runtime overhead of
importing the typing module? Or I want to keep the source code clear,
by not making function definitions into multi-line monsters because of
type declarations?

> > A lot of the frustration I see being expressed here (including my own) seems to come from the fact that it's so difficult to actually take that sort of "I can ignore it if I don't use it"
>
> Thanks for not staying quiet and helping us make typing better. In particular, I think one takeaway from this thread is that a lot of our documentation is focussed on "how to get started with typing my code", and not much addressed at library authors with limited time to deal with typing questions (like "what is a PEP 561" and "if my type hints are incomplete does that cause problems for my users")

That's a good point that I hadn't spotted - thanks for picking up on it!
Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CRBIOVH4K5VFIIPB2D6EJCIVWJXGITEU/
Code of Conduct: http://python.org/psf/codeofconduct/