[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
