[Python-Dev] Re: Tool to search in the source code of PyPI top 5000 projects
On Fri, 2021-12-03 at 00:44 +0100, Victor Stinner wrote: > I wrote two scripts based on the work of INADA-san's work to (1) > download the source code of the PyPI top 5000 projects (2) search for > a regex in these projects (compressed source archives). > > You can use these tools if you work on an incompatible Python or C API > change to estimate how many projects are impacted. > Am I correct that this script downloads only the newest version for each package? It might be worth to add a disclaimer that since many Python packages pin their dependencies to old versions, you are quite likely to miss impact on projects that are using the deprecated API in old versions that are still used because of their reverse dependencies. -- Best regards, Michał Górny ___ 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/O3PIUNTJUWXX2AHSCSF3FCW36NKISIUF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Thu, Dec 2, 2021 at 6:57 PM Stephan Richter 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 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-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/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 ___ 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/VF274OZPBKJ4OGF2ZWGLIES2GQF35VEZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
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 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-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/XRJJ4ZMOQJXOTRFT3FQ25QXHXOKBVXKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
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-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/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 ___ 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/J3MG3ULSGWM7JBJ6HADRMNJOD2MV5W7S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
resent -- damn iPhone! On Thu, Dec 2, 2021 at 3:20 PM 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 > -- 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/B2LV7W3XU2VW4YYHP3K34VTJ4N3WZAHA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)
On Thu, Dec 2, 2021 at 9:48 AM Eric Fahlgren wrote: > 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? >> > > Assuming you want the return value of 'fun' to be covariant with the path > input, I believe you would say this: > I just read the wikipedia page on "Covariant return type", and I either misunderstood what it means, or it's not relevant to my intended example. > def fun(some_kind_of_path: str) -> str: ... > def fun(some_kind_of_path: bytes) -> bytes: ... > def fun(some_kind_of_path: os.PathLike[AnyStr]) -> AnyStr: > some_kind_of_path = os.fspath(some_kind_of_path) > # transform it > return some_kind_of_path > Ahh I see, I wasn't intending, in my example, to return the path -- my intent was a function that would need to use the path, to, e.g. open a file. This Strikes me as a very common use case -- you want your users to be able to pass multiple different types in, as long as they can be used as a path. I have a LOT of code that does this -- for years it accepted only string paths, and now I'm updating it to take PathLike as well. My usual code is one of: def fun_that_opens_a_file(the_path): # if I'm working with an "old" library, or one that, e.g. wraps a C lib: the_path = os.fspath(the_path) # if I'm working with things I know will take a Path object: the_path = Path(the_path) > > I would love to be shown how to do this with just a one-line declaration > of 'fun', but I've given up trying to figure it out. > Darn. could you at least use a Union type: def fun_that_opens_a_file(the_path: Union[str, Path]): ... which isn't too bad. Personally, I think accepting bytes is the way of madness, but you could add that too. On Thu, Dec 2, 2021 at 12:32 PM Brett Cannon wrote: > > 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) > > That is not what the docs say: > https://docs.python.org/3/library/os.html#os.PathLike. And as the creator > of that ABC it's very much on purpose (see > https://www.python.org/dev/peps/pep-0519/ for details). > Sorry, I wasn't clear. By "PathLike" (as a type specifier)" I meant using it as, well, a type specifier, not as an ABC -- often we can use an ABC as a type specifier, but not always. But you've prompted me to go re-read the PEP and I see this: """ Provide specific type hinting support There was some consideration to providing a generic typing.PathLike class which would allow for e.g. typing.PathLike[str] to specify a type hint for a path object which returned a string representation. While potentially beneficial, the usefulness was deemed too small to bother adding the type hint class. This also removed any desire to have a class in the typing module which represented the union of all acceptable path-representing types as that can be represented with typing.Union[str, bytes, os.PathLike] easily enough and the hope is users will slowly gravitate to path objects only. """ I didn't pay any attention to that at the time, as I wasn't paying attention to typing. But personally, I think I do have that desire :-) But I can see that "the hope is users will slowly gravitate to path objects only". would lead to: > in my code I just take pathlib.Path or pathlib.PurePath and I'm done as I don't want to be dealing with encoded file paths and instead with objects that represent file paths. For my part, I'm not interested in encoded paths (e.g. bytes) -- that is absolutely not the right boundary to deal with file system encoding. (that's mentioned in the PEP) But I also don't want my users (or me, with old code, scripts, etc) to have to suddenly go in and wrap a call to Path() everywhere in order to continue to use my library. String paths are ubiquitous, and I think here to stay. I really like PEP 519 -- I think it not only provides a transition, but also a future in which Path objects and string paths can continue to play well together. While Union[PathLike, str] is a pretty light lift, this is one tiny example of what we "typing skeptics" are concerned about: a transition away from full on dynamic typing to a more static style. Maybe that won't come to pass -- we'll see. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
[Python-Dev] Re: The current state of typing PEPs
@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-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/7AF22G3S23S67FAHH7BI4XUNHWOU4YXT/ > 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/RMLBTCYXRWO2EW3XF57422VZHM3EPPJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Tool to search in the source code of PyPI top 5000 projects
Hi,
I wrote two scripts based on the work of INADA-san's work to (1)
download the source code of the PyPI top 5000 projects (2) search for
a regex in these projects (compressed source archives).
You can use these tools if you work on an incompatible Python or C API
change to estimate how many projects are impacted.
The HPy project created a Git repository for a similar need (latest
update in June 2021):
https://github.com/hpyproject/top4000-pypi-packages
There are also online services for code search:
* GitHub: https://github.com/search
* https://grep.app/ (I didn't try it yet)
* Debian: https://codesearch.debian.net/
(1) Dowload
Script:
https://github.com/vstinner/misc/blob/main/cpython/download_pypi_top.py
Usage: download_pypi_top.py PATH
It uses this JSON file:
https://hugovk.github.io/top-pypi-packages/top-pypi-packages-30-days.min.json
>From this service:
https://hugovk.github.io/top-pypi-packages/
At December 1, on 5000 projects, it only downloads 4760 tarball and
ZIP archives: I guess that 240 projects don't provide a source
archive. It takes around 5,2 GB of disk space.
(2) Code search
First, I used the fast and nice "ripgrep" tool with the command "rg
-zl REGEX path/*.{zip,gz,bz2,tgz}" (-z searchs in ZIP and tarball
archives). But it doesn't show the path inside the archive and it
searchs in files generated by Cython whereas I wanted to ignore these
files.
So I wrote a short Python script which decompress tarball and ZIP
archive in memory and looks for a regex:
https://github.com/vstinner/misc/blob/main/cpython/search_pypi_top.py
Usage: search_pypi_top.py "REGEX" output_filename
The code to parse command line option is hardcoded and pypi_dir =
"PYPI-2021-12-01-TOP-5000" are hardcoded :-D
It ignores files generated by Cython and .so binary files (Linux
dynamic libraries).
While "rg" is very fast, my script is very slow. But I don't care,
once the regex is written, I only need to search for the regex once, I
can wait 10-15 min ;-) I prefer to wait longer and have a more
accurate result. Also, there is room for enhancement, like running
multiple jobs in different processes or threads.
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/WQVEHLRIVISPFMWSSX5N4TQPIUN2XS22/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
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-le...@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/ ___ 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/7AF22G3S23S67FAHH7BI4XUNHWOU4YXT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
>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-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/ASO2PUTECTOB25HC7DURFOGOHOUQOCD5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)
On Wed, Dec 1, 2021 at 10:40 PM Christopher Barker wrote: > 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) > That is not what the docs say: https://docs.python.org/3/library/os.html#os.PathLike. And as the creator of that ABC it's very much on purpose (see https://www.python.org/dev/peps/pep-0519/ for details). > 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! > Depends on what "your merry way" is. As the docs say, os.fspath() is about getting the file system representation. That's not something to directly manipulate in a pathlib world unless you're using os.path to manipulate that string encoding (but which PEP 519 was specifically created to avoid such encoding headaches): https://docs.python.org/3/library/os.html#os.fspath . > > Is there really no way to annotate that simply now? > Once again, depends on what "simply" means to you. The examples I gave I don't find complicated, especially when we are talking about APIs that are trying to accept a broad set of types to convert into a single type. If you want to create a type variable that represents anything that is valid to `os.fspath()` or `pathlib.Path` to avoid typing out 2 or 4 types, then that can be considered for inclusion in the stdlib somewhere. But as I said previously, in my code I just take pathlib.Path or pathlib.PurePath and I'm done as I don't want to be dealing with encoded file paths and instead with objects that represent file paths. > > -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/PLJLXTGTLCCDAXSVXAXQO4XDGMMPVOIV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] bpo-41544: Add missing parameters to dummy.DummyProcess and dummy.Pool
Hi, could someone please review my pull request? https://github.com/python/cpython/pull/21869 It adds missing parameters to multiprocessing.dummy.DummyProcess in order to match the API of multiprocessing.Process. Best regards, Martin Schröder ___ 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/NVNRA57DDTBMO5FQR7D3ELB5436XZDLE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)
On Wed, Dec 1, 2021 at 10:50 PM Christopher Barker wrote: > 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? > Assuming you want the return value of 'fun' to be covariant with the path input, I believe you would say this: def fun(some_kind_of_path: str) -> str: ... def fun(some_kind_of_path: bytes) -> bytes: ... def fun(some_kind_of_path: os.PathLike[AnyStr]) -> AnyStr: some_kind_of_path = os.fspath(some_kind_of_path) # transform it return some_kind_of_path I would love to be shown how to do this with just a one-line declaration of 'fun', but I've given up trying to figure it out. ___ 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/PI6TR73ZQRDMKDNBUH3AQOK4IYUERB7F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Am 01.12.21 um 13:36 schrieb Paul Moore: 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? 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-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/3Z7MCNNQUH3S5IWXA5MXVAUKPYYWKFZO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano wrote: > On Tue, Nov 30, 2021 at 02:30:18PM +, 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. ___ 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/QX6MZXQRERQITQFPO7T5DLI4HHFXHX4B/ 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 Ezio, What is the status of migrating Python issues to GitHub? Is it done? If not, what are remaining issues? Victor ___ 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/IC2NXONBZUOQDMWZQM3SAGLX5S23EMTO/ Code of Conduct: http://python.org/psf/codeofconduct/
