[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
Kirill Balunov added the comment: I am reading "equivalence" too strictly (like "as a substitute"), because this is part of the documentation :) and I agree that in ordinary speech I would use it rather in the sense of “similar”. In order to make sure, that everyone agrees only on that this requires only a documentation change? Because as for me, I think that it will better for `os.path.isdir` to raise `ValueError` or `DeprecationWarning` - `False` on empty string is not well defined behavior. But I'm fine to be alone with the last one. -- ___ Python tracker <https://bugs.python.org/issue37688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
Kirill Balunov added the comment:
I understand the reasons, I only say that it does not correspond to my
perception of their equivalence, because:
os.path.isdir('') != os.path.isdir('.')
while:
Path('').is_dir() == Path('.').is_dir()
and I can confirm that some libraries rely on os.path.isdir('') -> False
behavior.
--
___
Python tracker
<https://bugs.python.org/issue37688>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
Kirill Balunov added the comment: Forgot to write the result for Path variant: >>> Path(dummy).is_dir() True -- ___ Python tracker <https://bugs.python.org/issue37688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
New submission from Kirill Balunov : In the documentation it is said that os.path.isdir(...) an Path(...).is_dir()are equivalent substitutes. https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module But they give different result for empty path strings: >>> import os >>> from pathlib import Path >>> dummy = "" >>> os.path.isdir(dummy) False Obviously it's not an equivalence, so either this should be noted in the documentation or corrected in the code. -- assignee: docs@python components: Documentation, Library (Lib) messages: 348475 nosy: docs@python, godaygo priority: normal severity: normal status: open title: The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings. type: behavior ___ Python tracker <https://bugs.python.org/issue37688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type
Kirill Balunov <kirill.balu...@gmail.com> added the comment: I apologize for FutureWarning and __getattr__. I myself do not understand what I meant and how it will help in this situation :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type
Kirill Balunov <kirill.balu...@gmail.com> added the comment: Small risk of breaking is a fair point (maybe some FutureWarning with new __getattr__ PEP 562?). I've checked several packages: --- vstinner/bytecode:: uses: @staticmethod def _has_jump(opcode): return (opcode in _opcode.hasjrel or opcode in _opcode.hasjabs) --- maynard:: defines them as sets and does not rely on opcode module. all_jumps = absolute_jumps | relative_jumps --- numba:: converts them to frozensets: JREL_OPS = frozenset(dis.hasjrel) JABS_OPS = frozenset(dis.hasjabs) JUMP_OPS = JREL_OPS | JABS_OPS --- codetransfromer:: uses: absjmp = opcode in hasjabs reljmp = opcode in hasjrel --- anotherassembler.py:: uses elif opcode in hasjrel or opcode in hasjabs: --- byteplay:: converts them to set: hasjrel = set(Opcode(x) for x in opcode.hasjrel) hasjabs = set(Opcode(x) for x in opcode.hasjabs) hasjump = hasjrel.union(hasjabs) --- byterun:: uses: elif byteCode in dis.hasjrel: arg = f.f_lasti + intArg elif byteCode in dis.hasjabs: arg = intArg In fact, all of the above indicated does not mean anything, but I have not found cases of hasjrel+hasjabs. Despite the fact that they are small, on average, with sets I gain 5-6x speed-up. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type
Change by Kirill Balunov <kirill.balu...@gmail.com>: -- nosy: +larry, serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful
Kirill Balunov <kirill.balu...@gmail.com> added the comment:
Sorry if this doesn't fit this issue and needs a separate one.
Since Python switched to 2 byte wordcode, all opcodes which do not imply an
argument, technically have it - augmented with 0. So it is convenient to
iterate over bytecode like:
op, arg = instruction.
But there is a check in stack_effect that the second argument for this opcodes
must be None.
file::_opcode.c
else if (oparg != Py_None) {
PyErr_SetString(PyExc_ValueError,
"stack_effect: opcode does not permit oparg but oparg was
specified");
return -1;
}
So you need to perform a somewhat _redundant_ check before calling:
arg = arg if op >= opcode.HAVE_ARGUMENT else None.
st = stack_effect(op, arg)
Maybe it's normal to relax this condition - be None or 0 for opcode <
opcode.HAVE_ARGUMENT?
--
nosy: +godaygo
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32455>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type
New submission from Kirill Balunov <kirill.balu...@gmail.com>: The opcode module contains several collections: `cmp_op` `hasconst` `hasname` `hasjrel` ... which are only used for `in` checks. At the same time, they are stored as `list`s and `cmp_op` as tuple. Both these types are not optimal for `__contains__` checks. Maybe it is worth at least to convert them to `frozenset` type after they are filled? -- components: Library (Lib) messages: 315576 nosy: godaygo priority: normal severity: normal status: open title: Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type type: performance versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Kirill Balunov <kirill.balu...@gmail.com> added the comment: Hello, what is the future of this patch? Such a feeling that the transition to wordcode is still in some half-way state. -- nosy: +godaygo ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used
Kirill Balunov <kirill.balu...@gmail.com> added the comment: Yes, I agree, I did not understand the documentation correctly. It seems to me that the problem in the perception arose because of the fact that "deactivate" is not formatted as shell command, while `Deactivate.ps1` and others are. So I think simple formatting will be enough. Also, it is not mentioned in the documentation that it is possible to activate environment in Powershell with "Drive:\> \Scripts\activate", but maybe it's not always true and I have nowhere to check. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used
Kirill Balunov <kirill.balu...@gmail.com> added the comment: Sorry, `deactivate` works in both cases `Scripts/Activate.ps1` and `Scripts/activate`. Only `Deactivate.ps1` is not created for the former, but the docs says that it should. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used
New submission from Kirill Balunov <kirill.balu...@gmail.com>: There was a related issue, which was closed https://bugs.python.org/issue26715. If virtual environment was activated using Powershell script - Activate.ps1, the Deactivate.ps1 was not created, while the documentation says that it should. "You can deactivate a virtual environment by typing “deactivate” in your shell. The exact mechanism is platform-specific: for example, the Bash activation script defines a “deactivate” function, whereas on Windows there are separate scripts called deactivate.bat and Deactivate.ps1 which are installed when the virtual environment is created." Way to reproduce under Windows 10, Python 3.6.4 1. Open elevated Powershell (Administrator access). 2. Activate virtual environment using Activate.ps1. 3. There is no Deactivate.ps1 Also, when the environment was activated with Activate.ps1, `deactivate` will not work. On the other hand, if the environment was activated simply with `activate` (it works) in Powershell, `deactivate` will also work. -- components: Windows messages: 312551 nosy: godaygo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: venv: Deactivate.ps1 is not created when Activate.ps1 was used type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28685] Optimizing list.sort() by performing safety checks in advance
Kirill Balunov <kirill.balu...@gmail.com> added the comment: What is the current status of this issue and will it go into Python 3.7? -- nosy: +godaygo ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
