[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)
I know this isn't really the place for this conversation, but: > which is what `os.PathLike` represents, hence why `str` isn't covered by > it); > wait, what? It seems so clear to me that "PathLike" (as a type specifier) would mean: anything that can be passed into os.fspath to give me a path. (or, of course to the stdlib functions that take paths) Isn't the entire purpose of os.fspath that you can write code like: def fun(some_kind_of_path): some_kind_of_path = os.fspath(some_kind_of_path) (or just pass it to a function you takes PathLIke) and go on your merry way -- e.g. duck typing, baby! Is there really no way to annotate that simply now? -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-le...@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/AYFULIM3SJ7DZK7SHGK436KGHX2M3WP5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
Hi Larry! The steering council brought this thread (that I missed) up to my attention. On Thu, Nov 4, 2021 at 8:17 AM Larry Hastings wrote: > > I guess this is part of the migration from bpo to GitHub issues? It is: this is one of the repos that I'm using for testing. In particular I'm using it for quick tests on specific issues, and it saw some more activity during the sprints. The issues-test-bpo repo is updated less frequently and it's supposed to look closer to the final version. > Maybe the initial work could be done in a private repo, to cut down on the > spurious email notifications to literally everybody subscribed to cpython? > Which is a lot of people. > The work is being done in private repos, but in order to showcase my progress to the fellow core devs and triagers, I added these two GitHub teams to the repos so that they could access them. People that don't belong to these two teams are unable to access the repository and shouldn't have received any notification. Unfortunately, with each import I have to destroy and recreate the repo, and add the teams again. I didn't realize this was sending out notification to all core devs and triagers (and apparently not everyone is receiving them, probably due to how they configured their notification settings on GitHub) -- if I knew I would have been more considerate :) In the coming weeks, you will still receive a few more notifications from issues-test-bpo as I reach major milestones and update the repo, but you shouldn't see any more notification from issues-test-2 or the other test repos. If you would like to change your notification settings, see https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications If there are any other issues feel free to ping me directly, and sorry for the noise! --Ezio > > /arry > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/Y4EN2IKGWIC3BNI6OCOCUPZYEAEKS7IU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Wed, 1 Dec 2021 at 12:12, Sebastian Rittau 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-le...@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/
[Python-Dev] Re: The current state of typing PEPs
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-le...@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/
[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)
On Tue, Nov 30, 2021 at 1:34 PM Paul Moore wrote: > On Tue, 30 Nov 2021 at 19:07, Brett Cannon wrote: > > > > On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano > wrote: > >> > >> On Tue, Nov 30, 2021 at 02:30:18PM +, 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). > > > > You're after > https://docs.python.org/3/library/os.html?highlight=pathlike#os.PathLike: > `str | PathLike[str]` (if you're only accepting string paths). > > Well, it's not really. What I'm after, as I stated, is "anything that > can be passed to the Path constructor". Yes, str | PathLike[str] is > probably close enough (although why is it OK for me to prohibit bytes > paths?) It's your code; do what you want. If you want to accept bytes, then you can accept bytes. I personally just don't care about the bytes edge case, so I leave it out. Plus I don't think pathlib supports bytes paths to begin with, so if you are after just the pathlib.Path case then you don't want bytes unless you're going to handle the decoding. But if you want bytes then you're after https://github.com/python/typeshed/blob/8542b3518a36313af57b13227996168e592fe868/stdlib/_typeshed/__init__.pyi#L84 which is what `open()` takes (plus ints): `str | bytes | os.PathLike[str] | os.PathLike[bytes]`. > but that's what I mean about copying the Path constructor's > annotations. If Path changes, I have to change my code. > Yep. You are writing down your expectations of what is acceptable to pass in and you're choosing to be very flexible, and so you have to write down more. I don't think anyone is claiming that typing your code takes no effort. But practically speaking the constructor to pathlib.Path isn't going to change. > > This is a very common idiom: > > def f(p: ???): > p = Path(p) > ... > > Why isn't it correspondingly straightforward to annotate? > If we added an object to pathlib that represented the type annotation for the constructor of pathlib then it wouldn't be. It's probably not an unreasonable idea since this idiom is common enough, I just don't know if anyone has bothered to suggest it for the module. > > If PathLike[str] included str, then it would be a lot easier. It's not > at all obvious to me why it doesn't (well, that's not entirely true - > it's because PathLike is an ABC, not a protocol, and it's not intended > to define "the type of objects that the Path constructor takes"). It > would still not be documented anywhere, though. > You're essentially wrapping the constructor to `pathlib.Path` as broadly as possible, which means you want types as broad as possible while still being accurate. You could also tell users, "give me pathlib.Path objects" and your troubles go away or "an object that implements the `__fspath__` protocol" (which is what `os.PathLike` represents, hence why `str` isn't covered by it); it all depends on what sort of assumptions you want to be able to make about what you're given. But because you're wanting to accept multiple types to support both the "old" way of string paths and the "new" way of `__fspath__` you then need to put the work in to accept those types. Personally, I treat string paths vs pathlib object paths like encoding and decoding strings; get it converted immediately at the boundary of your code and then just assume pathlib everywhere else. Pathlib was added in Python 3.4 and is well-known enough at this point that I don't worry about people not being aware of it, so I let users do the glue from any string paths they get to my APIs. But to be clear, path representations != pathlib.Path type parameters != `__fspath__` protocol; there's subtlety here regardless of the types. > > >> 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. > > > > I would change that "should" to "may". Python's dynamism makes > inferencing really hard. > > That's fair. That's why I think it should be straightforward for the > user to explicitly say "this argument should accept the same types as > pathlib.Path does". If inference can't do it automatically, and the > user can't (easily) let the checker know that it's OK to do it, then > we're left with no easy way to express a very common pattern. > But how would you specify that? And what if the thing you're wrapping isn't typed itself? And what if the object you're wrapping takes multiple arguments? You could talk to the typing-sig and see if they have
[Python-Dev] Re: PEP 674: Disallow using macros as l-value
On Tue, Nov 30, 2021 at 7:52 PM Victor Stinner wrote: > For this specific PEP changes, I consider that the number of impacted > projects is low enough to skip a deprecation process: only 4 projects > are known to be impacted. One year ago (Python 3.10), 16 were > impacted, and 12 have already been updated in the meanwhile. I ran a code search in PyPI top 5000 projects: my tool downloaded 4760 tarball and ZIP archives. On 4760 projects, only 16 of them (0.3%) are affected by the PEP 674: 99.7% (4744) are not affected ;-) IMO it's manageable to help these 16 projects to be updated for Python 3.11 (if the PEP is accepted) before the final version (scheduled for 2022-10-03). I expected that projects would only be affected by Py_TYPE() and Py_SIZE() changes. But I also found exactly 2 projects affected by the PyDescr_TYPE() and PyDescr_NAME() changes: code generated by SWIG in M2Crypto and mecab-python3 projects. I will investigate how to update SWIG for that. More details in the issue: https://bugs.python.org/issue45476#msg407410 Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/YSBCFCJIQWWGDR5WQPDDNUEI4UWKTJ6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau 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-le...@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/
[Python-Dev] Re: The current state of typing PEPs
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PUV2ODPSN27JN6SXLVUSY3O54G7H2ONB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: multiple inheritance and `__str__`
01.12.21 09:56, Ethan Furman пише: > Some searching turned up issue 36793: "Do not define unneeded __str__ > equal to __repr__" . > > As can be seen, `__str__` is needed for inheritance to work properly. > Thoughts on reverting that patch? As the author of issue36793 I do not think so. If you replace int with list you will get the same result. If you make Blah an int subclass you will get the same result. If you want to get different results set Huh.__str__ explicitly to object.__str__ or int.__repr__. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/U3VVGYXXQ4RED64SLCX63BJITCCVLJFL/ Code of Conduct: http://python.org/psf/codeofconduct/
