[issue41523] functools.cached_property does not satisfy the property check
Bernát Gábor added the comment: I think they're implemented differently and have slightly different semantics, but they're equal from a user point of view most of the time 🤔 -- nosy: +Bernát Gábor ___ Python tracker <https://bugs.python.org/issue41523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30979] the winapi fails to run shortcuts (because considers a shortcut not a valid Win32App)
New submission from Bernát Gábor: Although python27.exe.lnk is callable from any command line tool, with any of its arguments the subprocess module thinks it's not a valid Win32 application. Proof, let there be python27.exe.lnk be a shortcut to python.exe: C:\Python27 λ ls python* python.exe* python27.exe.lnk* pythonw.exe* λ python.exe -c "import sys; print(sys.version)" 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] C:\Python27 λ python.exe -c "import subprocess; print(subprocess.call(['./python.exe', '-c', '\"import sys; print(sys.version)\"']))" 0 C:\Python27 λ python27.exe -c "import subprocess; print(subprocess.call(['./python27.exe.lnk', '-c', '\"import sys; print(sys.version)\"']))" Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\subprocess.py", line 168, in call return Popen(*popenargs, **kwargs).wait() File "C:\Python27\lib\subprocess.py", line 390, in __init__ errread, errwrite) File "C:\Python27\lib\subprocess.py", line 640, in _execute_child startupinfo) WindowsError: [Error 193] %1 is not a valid Win32 application -- components: Windows messages: 298752 nosy: Bernát Gábor, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: the winapi fails to run shortcuts (because considers a shortcut not a valid Win32App) type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
New submission from Bernát Gábor: Hello, typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv which means that Sphinx fails to find these. Thanks, -- components: Library (Lib) messages: 299048 nosy: Bernát Gábor priority: normal severity: normal status: open title: typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Bernát Gábor added the comment: I agree we should not advertise the type. However, whatever its type is should be in sync in what we put inside objects.inv. That's sort of a encoded binary black box for the user; the Sphinx tool included. It maps standard library elements to URLs. This ticket is about fix objects.inv to have the Tuple in the correct bucket. -- ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Bernát Gábor added the comment: I would need to know who and how maintains the https://docs.python.org/3.6/objects.inv file. Do you have any idea? -- ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Bernát Gábor added the comment: how can we find it out? -- ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Bernát Gábor added the comment: so here's the problem in detail: Intersphinx (http://www.sphinx-doc.org/en/stable/ext/intersphinx.html) is a built in Sphinx plugin that allows to link to documentation of other projects in your own documentation. For example when specifying the argument of a function which can be either int or string you might specify the argument to be Union[int, str]. In this case Sphinx will generate the type of the argument as this object, where e.g. the Union word will be a link to https://docs.python.org/3/library/typing.html#typing.Union and so on. In order to know for which object/function/type what is the correct URL an intersphinx object (which is basically a mapping) needs to be generated. This maps each element to an URL. This intersphinx mapping storage object (available at https://docs.python.org/3/objects.inv and similarly under other version pattern for the according version) is generated from the Python documentation. Now there's one indirection as far as this objects.inv goes; it does not actually stores mappings of element to URL, but what instead does it stores a mapping of type to element to url. Where type is here defined as either data/class etc. In order to resolve from an element to an URL both keys need to be correct (the type and the key too). For Python 3.6+ the typing.Tuple mapping now fails because according to the documentation the Tuple is under the section data, but once intersphinx looks at the Tuple during documentation generation it deduces it actually is of type class, and tries to locate it there. In order for intersphinx to resolve the correct web page URL, the runtime information of an element need to coincide with it's documentation type. Hence, what this PR tries to fix, migrating the documentation type/section of data to class (as in the meantime under Python 3.6 the Tuple is now a class). For the end user the fact that this is a class is still hidden, but for the documentation generation tool to resolve the correct URL, the runtime information needs to coincide with the documentation one. We should probably add a unit test that makes sure all runtime "type" matches with documentation "type" in the future. Let's make that the scope of another PR; is now clear? -- ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Bernát Gábor added the comment: I suppose when the python.org documentation is generated the objects.inv file gets generated with it (I did not found exactly this piece of code here though). When Sphinx runs, it's intersphinx plugin goes out to python.org, downloads the objects.inv, decodes it, and then tries to map the docstring param/return values/references to URLs. Actually intersphinx does not make the deduction of the type. It uses what the users entered in the docstring. In this case the user needs to know for each element to which bucket has been assigned to (e.g. class/data/function/method/exception/macro); and for compatibility reason that needs to stay stable, otherwise with a Python upgrade the user would need to update the code of its docstrings. That being said for the sake of automation, in my case there actually another sphinx plugin (https://github.com/agronholm/sphinx-autodoc-typehints/blob/master/sphinx_autodoc_typehints.py) which actually generates, on the fly, the type information. So I suppose as a fix for my problem the sphinx_autodoc_typehint could be altered to still give back data, even though this now is a class. I'm not sure though how confident I am on "lying" to users about the data/class; but I suppose it's a necessary evil at this point. So should we keep everything as it is? When I first identified why Tuple does not have the URL mapped to it, I thought the problem to be the fact that it goes to the wrong bucket (by just inspecting its type): data; but now I see that may not be such a bad thing after all. -- ___ Python tracker <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
