[Python-Dev] Re: Keeping Python a Duck Typed Language.
On Thu, Apr 22, 2021, at 1:01 PM, Brett Cannon wrote: > > > On Thu, Apr 22, 2021 at 4:11 AM Paul Moore wrote: >> On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote: >> > >> > On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote: >> > > >> > > Someone will likely correct me if this is inaccurate, but my >> > > understanding is that that's exactly what you get if you just don't >> > > give a type hint. The point of type hints is to give more information >> > > to the type checker when it's unable to simply infer from usage and >> > > context. >> > >> > Hmm, I sort of wondered about that as I wrote it. But in which case, >> > what's the problem here? My understanding was that people were >> > concerned that static typing was somehow in conflict with duck typing, >> > but if the static checkers enforce the inferred duck type on untyped >> > arguments, then that doesn't seem to be the case. Having said that, I >> > thought that untyped arguments were treated as if they had a type of >> > "Any", which means "don't type check". >> >> Looks like it doesn't: >> >> > cat .\test.py >> def example(f) -> None: >> f.close() >> >> import sys >> example(12) >> example(sys.stdin) >> PS 12:00 00:00.009 C:\Work\Scratch\typing >> > mypy .\test.py >> Success: no issues found in 1 source file >> >> What I was after was something that gave an error on the first call, >> but not on the second. Compare this: >> In PyCharm, the above code will result in it highlighting the number `12` with the following warning: "Type 'int' doesn't have expected attribute 'close'" Similarly, for: def f(x: int): ... def g(x: str): ... def main(t: DuckTyped) -> None: if t[0] == 'version': f(t[1]) elif t[0] == 'name': g(t[1]) If you replace `f(t[1])` or `g(t[1])` with just `t.` and activate auto-completion, it'll show `__getitem__` as an option (but it won't show any additional int/str methods). If instead you add an `elif isinstance(t, str):`, under that condition it'll auto-complete `t.` with all string properties/methods.___ 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/EGBSQALPGCTLAPM6FLIQLDV2YD2OLVAB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] async generator bug fixed in 3.8+ and backported to 3.6 but not to 3.7
Hi,
The fix for https://bugs.python.org/issue33786 ("@asynccontextmanager
doesn't work well with async generators") was merged in 3.8 and then
backported to 3.6. However, it was overlooked to be backported for 3.7 (
https://github.com/python/cpython/pull/7506).
I'm aware that 3.7 is in security fix mode only so I'm not sure there's
more to be done, however, given that this is fixed for 3.6, 3.7 is in a
weird position still having the bug.
So I just wanted to bring this up in case the fix can still be backported
to 3.7.
Matt
___
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/LW73WSFPK7XHKHEZDRQMWOHK2BDUJWYK/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Python environment registration in the Windows Registry
On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters wrote: > ...just when I thought I have solved the registry headaches I have been > dealing with... > > I am not saying this proposal will make the registry situation worse, but > it may break my solution to the headaches Python's registry use causes with > some non-standard module installers (and even the standard distutils exe > installers, but that is being mitigated). In the wild exist modules with > their own EXE or MSI installers that check the registry for 'the system > python'. No matter how hard you hit them, they will only install to *that > one python*. If I remember correctly, you can use `wheel convert filename.exe` on those installers which create a wheel that you can install. I think that's what I used to do with pywin32 before pypiwin32 came along. I just tested it and it still works on the pywin32 exe. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
On Wed, Sep 30, 2015 at 3:57 PM, Carl Kleffner wrote: > Concerning the claims that mingw is difficult: > > The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, > that is in development. It is designed for simple use and for much better > compatibility to the standard MSVC python builds. It should work out of the > box, as long as the \Scripts folder is in the PATH. > Indeed, I tested it with 2.7.9 x86/x64, and wheres before I had to apply at least http://bugs.python.org/issue4709, and http://bugs.python.org/issue16472 and then generate the .a files to get it to work, this worked out of the box! (except of course still needing to change distutils.cfg). I do wonder though, which may be slightly off topic here, whether putting the mingw binary stub files (?) in python/Scripts, rather than directly having python/shared/mingwpy/bin be on the path, is the best approach? I suppose it's no worse than having the other stuff in python/scripts on the path (although with e.g. pip you could do the python -m pip trick). Are there guidelines about this (using python/scripts) for Windows? I didn't see anything mentioned when python -m pip install ... vs. pip install is discussed. Although I hope a 7z version of that mingw will be separately available for those that want to share a copy between versions of python, since the files in share/mingwpy is presumably the same between python versions for a specific bitness? Matt ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
