[issue47239] Python Launcher for Windows (`py -0`) no longer shows star ("*") for default version
Dutcho added the comment: BTW I just found 'py -0p' also no longer shows the 'venv' path ``` (venv) C:\>py -0p -V:3.11 *C:\Program Files\Python311\python.exe -V:3.10 C:\Program Files\Python310\python.exe -V:3.9 C:\Program Files\Python39\python.exe -V:3.8 C:\Program Files\Python38\python.exe (venv) C:\>pip -V pip 22.0.4 from C:\...\venv\Lib\site-packages\pip (python 3.11) ``` Or should I make a separate bug entry for this? -- ___ Python tracker <https://bugs.python.org/issue47239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47239] Python Launcher for Windows (`py -0`) no longer shows star ("*") for default version
Dutcho added the comment: That was the case in older versions (up to a6) -- ___ Python tracker <https://bugs.python.org/issue47239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47239] Python Launcher for Windows (`py -0`) no longer shows star ("*") for default version
New submission from Dutcho : If doing `py -list` in 3.11.0a7, a star "*" shows on 3.11, even though the default (set by environment variable PY_PYTHON) is 3.10, which `py -V` confirms ``` C:\>py --list -V:3.11 *Python 3.11 (64-bit) -V:3.10 Python 3.10 (64-bit) -V:3.9 Python 3.9 (64-bit) -V:3.8 Python 3.8 (64-bit) C:\>py -V Python 3.10.4 ``` -- title: Python Launcher for Windowscd \ -> Python Launcher for Windows (`py -0`) no longer shows star ("*") for default version ___ Python tracker <https://bugs.python.org/issue47239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47239] Python Launcher for Windowscd \
Change by Dutcho : -- components: Windows nosy: Dutcho, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python Launcher for Windowscd \ versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47192] sys._getframe audit event has frame as argument in 3.8-3.10
New submission from Dutcho : Documentation (https://docs.python.org/3/library/audit_events.html and https://docs.python.org/3/library/sys.html#sys._getframe) states that `sys._getframe()` "raises [...] an auditing event with no arguments". However, Python 3.8-3.10 provide the frame as argument to the hook function. Python 3.11 behaves consistently with documentation. But I couldn't find the change mentioned in the change log. Therefore, I'm uncertain whether that's intentional or not, so whether it'll remain in the release version. This is demonstrated by running snippet `audit.py` ``` import sys sys.addaudithook(print) print(sys.version) sys._getframe() ``` in various versions: ``` 3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] sys._getframe (>,) 3.9.11 (tags/v3.9.11:2de452f, Mar 16 2022, 14:33:45) [MSC v.1929 64 bit (AMD64)] sys._getframe (>,) 3.10.3 (tags/v3.10.3:a342a49, Mar 16 2022, 13:07:40) [MSC v.1929 64 bit (AMD64)] sys._getframe (>,) 3.11.0a6 (main, Mar 7 2022, 16:46:19) [MSC v.1929 64 bit (AMD64)] sys._getframe () ``` -- messages: 416506 nosy: Dutcho priority: normal severity: normal status: open title: sys._getframe audit event has frame as argument in 3.8-3.10 versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46969] `pip install wrapt` fails on ast.py in Python 3.11.0a6
Dutcho added the comment: yesterday's `wrapt *1.13.3*` still doesn't work, but today's `wrapt *1.14.0*` works as expected So this wasn't about Python 3.11 but about the wrapt version, which used the deprecated `formatargspec` from module `inspect` -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46969] `pip install wrapt` fails on ast.py in Python 3.11.0a6
New submission from Dutcho : ... or perhaps this is caused by *wrapt 1.13.3*? ''' (venv) >pip install wrapt Collecting wrapt Using cached wrapt-1.13.3.tar.gz (48 kB) Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [92 lines of output] Traceback (most recent call last): File "...\venv\Lib\site-packages\setuptools\config.py", line 35, in __getattr__ return next( ^ File "...\venv\Lib\site-packages\setuptools\config.py", line 36, in ast.literal_eval(statement.value) ^ File "C:\Program Files\Python311\Lib\ast.py", line 108, in literal_eval return _convert(node_or_string) File "C:\Program Files\Python311\Lib\ast.py", line 107, in _convert return _convert_signed_num(node) ^ File "C:\Program Files\Python311\Lib\ast.py", line 81, in _convert_signed_num return _convert_num(node) ^^ File "C:\Program Files\Python311\Lib\ast.py", line 72, in _convert_num _raise_malformed_node(node) ^^^ File "C:\Program Files\Python311\Lib\ast.py", line 69, in _raise_malformed_node raise ValueError(msg + f': {node!r}') ^ ValueError: malformed node or string on line 2: ''' -- messages: 414814 nosy: Dutcho priority: normal severity: normal status: open title: `pip install wrapt` fails on ast.py in Python 3.11.0a6 type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
New submission from Dutcho : https://docs.python.org/3.11/library/enum.html#module-contents contains: property() Allows Enum members to have attributes without conflicting with member names. In above, property() is links to: https://docs.python.org/3.11/library/functions.html#property instead of to the proper: https://docs.python.org/3.11/library/enum.html#enum.property -- assignee: docs@python components: Documentation messages: 412156 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: In documentation contents enum.property erroneously links to built-in property versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__
New submission from Dutcho : https://docs.python.org/3.11/library/enum.html#enum.StrEnum contains: Note __str__() is str.__str__() to better support the replacement of existing constants use-case. __format__() is likewise int.__format__() for that same reason. This should be (change indicated by triple star): Note __str__() is str.__str__() to better support the replacement of existing constants use-case. __format__() is likewise ***str***.__format__() for that same reason. Likely copied from IntEnum -- assignee: docs@python components: Documentation messages: 412067 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__ versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45740] StrEnum entry doesn't mention its introduction in 3.11
New submission from Dutcho : At https://docs.python.org/3.11/library/enum.html#enum.StrEnum no mention is made of 'New in version 3.11', whereas e.g. https://docs.python.org/3.11/library/enum.html#enum.EnumCheck does. Note https://docs.python.org/3.11/library/enum.html#module-contents DOES document: 'New in version 3.11: StrEnum, EnumCheck, FlagBoundary'. -- assignee: docs@python components: Documentation messages: 405863 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: StrEnum entry doesn't mention its introduction in 3.11 type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10
Dutcho added the comment: perhaps related to https://bugs.python.org/issue44559 ? -- ___ Python tracker <https://bugs.python.org/issue45493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10
Change by Dutcho : -- title: str() and repr() of enum different in Python 3.11 from from Python <= 3.10 -> str() and repr() of enum different in Python 3.11 from Python <= 3.10 ___ Python tracker <https://bugs.python.org/issue45493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45493] str() and repr() of enum different in Python 3.11 from from Python <= 3.10
New submission from Dutcho : See below example, which shows Python 3.11 repr(enum) == Python 3.10 str(enum). The enum module documentation lists various enhancements in 3.11, but not this. And the what's new? documentation of 3.11 doesn't mention enum at all. Either this is by intent, and then should be documented incl. breaking old code depending on representation, or is by accident, and then merits fixing (which is what alphas are for). > py -3.10 enum_test.py 3.10.0 (tags/v3.10.0:b494f59, Oct 4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] ABC.a ABC.b ABC.c ABC.a > py -3.11 enum_test.py 3.11.0a1 (tags/v3.11.0a1:7c12e48, Oct 5 2021, 15:38:19) [MSC v.1929 64 bit (AMD64)] a b c a ABC.a > more enum_test.py import enum import sys class ABC(enum.Enum): a = enum.auto() b = enum.auto() c = enum.auto() print(sys.version) print(*ABC, str(ABC.a), repr(ABC.a)) -- components: Library (Lib) messages: 404069 nosy: Dutcho priority: normal severity: normal status: open title: str() and repr() of enum different in Python 3.11 from from Python <= 3.10 type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45492] stdlib inspect documentation on code.co_names is incorrect
New submission from Dutcho : The standard library documentation on module inspect starts with an overview of types and attributes. This overview (in all Python versions) states: code.co_names: tuple of names of local variables code.co_varnames: tuple of names of arguments and local variables That suggests the argument names are set(code.co_varnames) - set(code.co_names), which is incorrect. I think the attribute description should be: code.co_names: tuple of names of used global and built-in variables >>> def f(x): a = 1; print(f, a) >>> assert f.__code__.co_varnames == ('x', 'a') # argument and local, in that >>> order >>> assert set(f.__code__.co_names) == set(('f', 'print')) # global and >>> built-in (don't care order), not local -- assignee: docs@python components: Documentation messages: 404068 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: stdlib inspect documentation on code.co_names is incorrect versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40464] functools.singledispatch doesn't verify annotation is on FIRST parameter
Dutcho added the comment: I'm afraid my "even return" was interpreted in https://github.com/python/cpython/pull/19871 as "only return", while as stated "any annotation" suffices. To rephrase: If the *first* parameter of the registered function isn't annotated, any non-first annotation suffices for registering, but will not dispatch correctly. Example: ``` >>> @functools.singledispatch ... def func(arg, x):... >>> @func.register ... def _int(arg, x:int):... >>> @func.register ... def _str(arg, x:str):... ``` No errors happen, although parameter `x` is annotated, not the first parameter `arg`. So `func()` will dispatch on the type of `arg` according to the annotation of `x`. So I'm afraid the PR solves the specific "return" example case, but not the flagged general issue. -- ___ Python tracker <https://bugs.python.org/issue40464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40464] functools.singledispatch doesn't verify annotation is on FIRST parameter
New submission from Dutcho : >From Python 3.7, `functools.singledispatch` makes the `register()` attribute >of the generic function infer the type of the first argument automatically for >functions annotated with types. That's great for DRY. However, in 3.7 and 3.8, no check is made that the *first* parameter of the registered function is actually annotated; *any* annotation suffices, even the *return* one. Example: ``` >>> @functools.singledispatch ... def func(arg):... >>> @func.register ... def _int(arg) -> int:... >>> @func.register ... def _str(arg) -> str:... ``` No errors happen, although the return type, *not* `arg`, is annotated. This results in: ``` >>> func.registry mappingproxy({: , : , : }) ``` Obviously, that doesn't dispatch correctly. Note that un-annotated functions *are* caught: ``` >>> @func.register ... def _no_annotation(arg): ... Traceback (most recent call last): ... TypeError: Invalid first argument to `register()`: . Use either `@register(some_class)` or plain `@register` on an annotated function. ``` -- components: Library (Lib) messages: 367824 nosy: Dutcho priority: normal severity: normal status: open title: functools.singledispatch doesn't verify annotation is on FIRST parameter type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39182] sys.addaudithook(hook) loops indefinitely on mismatch for hook
New submission from Dutcho : When hook is not a compatible callable, addaudithook() will loop forever. At the minimum, a check for being callable should be executed. Preferably, a non-compatible (i.e. signature != [[str, tuple], Any]) hook callable should also be detected. >py Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.addaudithook(0) error=10 Exception ignored in audit hook: TypeError: 'int' object is not callable File "", line 0 SyntaxError: unknown parsing error error=10 Exception ignored in audit hook: TypeError: 'int' object is not callable File "", line 0 SyntaxError: unknown parsing error error=10 Exception ignored in audit hook: TypeError: 'int' object is not callable File "", line 0 SyntaxError: unknown parsing error ... etc. ... -- messages: 359164 nosy: Dutcho priority: normal severity: normal status: open title: sys.addaudithook(hook) loops indefinitely on mismatch for hook type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)
New submission from Dutcho : In recent Python, a directory without __init__.py is also a package, and hence can be imported. When this directory/package is empty, and a doctest.testmod() is executed, the behaviour changed from 3.6 to 3.7, which I didn't find in the "what's new" documentation. Minimal example: >>> import doctest, os >>> os.mkdir('empty_package') >>> import empty_package >>> doctest.testmod(empty_package) Python 3.6.8 on Windows 7 prints TestResults(failed=0, attempted=0) Python 3.7.2 on Windows 7 raises below TypeError in doctest Traceback (most recent call last): File "bug_empty_package.py", line 4, in print(doctest.testmod(empty_package)) File "...\Python37\lib\doctest.py", line 1949, in testmod for test in finder.find(m, name, globs=globs, extraglobs=extraglobs): File "...\Python37\lib\doctest.py", line 932, in find self._find(tests, obj, name, module, source_lines, globs, {}) File "...\Python37\lib\doctest.py", line 982, in _find test = self._get_test(obj, name, module, globs, source_lines) File "...\Python37\lib\doctest.py", line 1063, in _get_test if filename[-4:] == ".pyc": TypeError: 'NoneType' object is not subscriptable -- components: Library (Lib) messages: 338670 nosy: Dutcho priority: normal severity: normal status: open title: doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6) type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34499] Extend registering of single-dispatch functions to parametrized generic pseudo-types
New submission from Dutcho : While issue #34498 signalled a break in Python 3.7 of legal Python 3.6 code that registers a single-dispatch function with a 'pseudo-type' like typing.Sequence, both Python 3.6 and Python 3.7 don't work with a 'parametrized pseudo-type' like typing.Sequence[int]. However, to fully benefit from Python 3.7's use of annotations for registering single-dispatch functions, these 'parametrized pseudo-types' should also be acceptable. E.g. in Python 3.6: $ py -3.6 Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from functools import singledispatch >>> from typing import Iterable, Sequence, T >>> >>> @singledispatch ... def last(iterable: Iterable[T]) -> T: ... for last in iterable: ... pass ... return 'slow', last ... >>> @last.register(Sequence) ... def _(sequence: Sequence[T]) -> T: ... return 'fast', sequence[-1] ... >>> print(*last(iter([1, 2, 3]))) slow 3 >>> print(*last([1, 2, 3])) fast 3 Note in Python 3.6 no match results if the 'parametrized pseudo-type' Sequence[T] is specified as argument to last.register() as isinstance(..., Sequence[T]) fails. To fully benefit from Python 3.7's use of annotations for single-dispatch functions, it should (1) accept >>> @last.register ... def _(sequence: Sequence[T]) -> T: ... return 'fast', sequence[-1] and (2) remove the T parameter of Sequence for matching when dispatching. I recognize this could potentially create a clash between e.g. Sequence[int] and Sequence[str] -- components: Library (Lib) messages: 324063 nosy: Dutcho priority: normal severity: normal status: open title: Extend registering of single-dispatch functions to parametrized generic pseudo-types type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted
New submission from Dutcho : In Python 3.6, the argument to the register() method of a single-dispatch function (i.e. a function decorated by @functools.singledispatch) can be a 'type-like' class (pseudo-type?) from e.g. the typing module that supports isinstance(). The below demonstrates it works in Python 3.6: $ py -3.6 Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from functools import singledispatch >>> from typing import Sequence >>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance True >>> @singledispatch ... def f(arg): ... print('unqualified', arg) ... >>> @f.register(Sequence) # 'pseudo-type' okay with register ... def _(arg): ... print('sequence', *arg) ... >>> f(1) unqualified 1 >>> f([1,2,3]) sequence 1 2 3 This code breaks in Python 3.7: $ py Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from functools import singledispatch >>> from typing import Sequence >>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance True >>> @singledispatch ... def f(arg): ... print('unqualified', arg) ... >>> @f.register(Sequence) # 'pseudo-type' NOT okay with register ... def _(arg): ... print('sequence', *arg) ... Traceback (most recent call last): File "", line 1, in File "D:\Program Files\Python\Python37\lib\functools.py", line 801, in register f"Invalid first argument to `register()`: {cls!r}. " TypeError: Invalid first argument to `register()`: typing.Sequence. Use either `@register(some_class)` or plain `@register` on an annotated function. While agreeing a check on the register() arg IS required, the current check isinstance(cls, type) seems overly restrictive. This is especially true when considering the (welcome!) Python 3.7 use of annotations for single dispatch functions. -- components: Library (Lib) messages: 324061 nosy: Dutcho priority: normal severity: normal status: open title: Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33762] temp file isn't IOBase
New submission from Dutcho : I'd expect isinstance(tempfile.TemporaryFile(), io.IOBase) to be True as you can read() from and write() to the temp file. However, on Python 3.6.5 64 bit on Windows 7 above isinstance() == False and and type(tempfile.TemporaryFile()) == tempfile._TemporaryFileWrapper, which has no super class (other than object). Whereas, on Python 3.6.1 on iOS 11.4 (Pythonista 3.2) above isinstance() == True and type(tempfile.TemporaryFile()) == io.BufferedRandom, which has io.IOBase as its (indirect) super class. The difference is likely caused by tempfile line 565 that equals TemporaryFile = NamedTemporaryFile in case of Windows. This may be somewhat related to issue 26175, but isn't a duplicate as 26175 is on a temp file's attributes, and this issue is on its type -- components: Library (Lib) messages: 318585 nosy: Dutcho priority: normal severity: normal status: open title: temp file isn't IOBase type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33219] x in IntFlag() should test int x's inclusion in IntFlag
Dutcho <dut...@ziggo.nl> added the comment: @Nitish The easiest way would probably be to change __contains__ in Flag to: def __contains__(self, other): try: return other & self == other # leave selection of _value_ attribute (if other is Flag) or conversion (if other is int mixin of IntFlag) to __and__ except TypeError: return False Although this would be somewhat convoluted (the generic delegation to __and__ isn't clear at first sight and therefore less maintainable) and may lead to confusing error messages -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33217] x in enum.Flag() is True when x is no Flag
Dutcho <dut...@ziggo.nl> added the comment: Ah, the mixin logic mentioned in 33219 solves most of my objections to returning False; agree that would make sense Only remaining inconsistency would be with 1 in 'hello' -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33217] x in enum.Flag() is True when x is no Flag
Dutcho <dut...@ziggo.nl> added the comment: Fully agree that Flag.__contains__ must RETURN False or True; that's why I suggested it RAISES TypeError The exception was to be consistent with e.g. Flag.__and__, which by returning NotImplemented transfers to type(other).__rand__, and assuming __rand__ cannot handle Flag and also returns NotImplemented, falls back to the interpreter raising TypeError. Also e.g. 1 in 'hello' raises TypeError. For Flag, I wouldn't strongly oppose to False for other being a different type. However, classes derived from Flag could face issues, e.g. `class MyIntFlag (Flag, int): pass`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33219] x in IntFlag() should test int x's inclusion in IntFlag
New submission from Dutcho <dut...@ziggo.nl>: While `enum.IntFlag.__and__` accepts an int arg `other` and converts it to `IntFlag` before masking, `enum.IntFlag.__contains__` handles an int arg `other` no different from a different type arg `other` (i.e. returns `True` in Python 3.6 due to issue 33217, but would raise `TypeError` after that's fixed): >>> import enum >>> ABC = enum.Flag('ABC', 'a, b, c') >>> ac = ABC.a | ABC.c >>> ABC.b in ac # works False >>> 2 in ac # should be the same; no exception due to issue 33217 True >>> ac & 3 # works, equivalent to ac & ABC(3) This is caused by a lack of specialized `IntFlag.__contains__`, so `Flag.__contains__` does the work. Can be fixed by adding a specialization, which (like in `IntFlag.__and__`) tests for `isinstance(other, (IntFlag, int))`. >>> def __contains__(self, other): ... if not isinstance(other, (self.__class__, int)): ... return TypeError ... return other & self == other # conversion of int to IntFlag implicitly handled by IntFlag.__and__ >>> IntFlag.__contains__ = __contains__ -- components: Library (Lib) messages: 314893 nosy: Dutcho priority: normal severity: normal status: open title: x in IntFlag() should test int x's inclusion in IntFlag type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33217] x in enum.Flag() is True when x is no Flag
New submission from Dutcho <dut...@ziggo.nl>: While `Flag() in Flag()` and `Flag() | Flag()` result in the expected outcomes, e.g. `str() in Flag()` unexpectedly returns `True`, whereas `Flag() | str()` as expected raises a TypeError. >>> import enum >>> ABC = enum.Flag('ABC', 'a, b, c') >>> ac = ABC.a | ABC.c >>> def test(): ... for x in (*ABC, 'test'): ... print(x, end=' ') ... try: ... print(x in ac, end=' ') ... except TypeError as e: ... print(e, end=' ') ... try: ... print(x | ac) ... except TypeError as e: ... print(e) >>> test() ABC.a True ABC.c|a ABC.b False ABC.c|b|a ABC.c True ABC.c|a test True unsupported operand type(s) for |: 'str' and 'ABC' Likely cause is modelling of Flag.__contains__ after Flag.__and__ etc., which is incorrect as __contains__ doesn't have a reflected version like __and__ etc. have. The returned `NotImplemented` is therefore not handled by the interpreter, although it is converted to bool to satisfy __contains__ return type. This can be fixed by redefinition of Flag.__contains__ to raise TypeError: >>> def __contains__(self, other): ... if not isinstance(other, self.__class__): ... raise TypeError(f"unsupported operand type(s) for 'in': " ... f"{type(other).__qualname__!r} and {type(self).__qualname__!r}") ... return other & self == other >>> enum.Flag.__contains__ = __contains__ >>> test() ABC.a True ABC.c|a ABC.b False ABC.c|b|a ABC.c True ABC.c|a test unsupported operand type(s) for 'in': 'str' and 'ABC' unsupported operand type(s) for |: 'str' and 'ABC' -- components: Library (Lib) messages: 314890 nosy: Dutcho priority: normal severity: normal status: open title: x in enum.Flag() is True when x is no Flag type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30037] inspect documentation on code attributes incomplete
New submission from Dutcho: The table at the top of the inspect documentation (https://docs.python.org/3/library/inspect.html#types-and-members) omits co_cellvars, co_freevars, and co_kwonlyargcount attributes of type code (note: the type's doc string does provide these attributes) -- assignee: docs@python components: Documentation messages: 291464 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: inspect documentation on code attributes incomplete type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30036] The bugs website doesn't use httpS by default
New submission from Dutcho: The footer of httpS://python.org links to httP://bugs.python.org, compromising user data for login and register options -- assignee: christian.heimes components: SSL messages: 291463 nosy: Dutcho, christian.heimes priority: normal severity: normal status: open title: The bugs website doesn't use httpS by default type: security versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com