[issue9703] default param values
New submission from vladimir :
This program:
class t( object):
def __init__(self,ime,param1=[],param2=[]):
print "+++init+++"
print "ime = ",ime
print "param1 = ", param1
print "param2 = ", param2
print
self.ime = ime
self.sirina = param1
self.visina = param2
def load(self):
print "load self.ime = ",self.ime
self.sirina.append('a')
self.visina.append('b')
t1 = t("jedan",[1,2],[3,4])
t2 = t("dva",[5,6],[7,8])
t3 = t("tri")
t3.load()
t4 = t("cetiri")
produces this output:
+++init+++
ime = jedan
param1 = [1, 2]
param2 = [3, 4]
+++init+++
ime = dva
param1 = [5, 6]
param2 = [7, 8]
+++init+++
ime = tri
param1 = []
param2 = []
load self.ime = tri
+++init+++
ime = cetiri
param1 = ['a']
param2 = ['b']
Question:
How's possible that call t4 = t("cetiri")
gives param1 value ['a'] and
param2 value ['b']
Is it possible that is bug or my computer gone crazy or maybe i am
executed on:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
--
messages: 115137
nosy: vladimir
priority: normal
severity: normal
status: open
title: default param values
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue9703>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9703] default param values
vladimir added the comment: On Sat, Aug 28, 2010 at 12:34 AM, Georg Brandl wrote: changes parameter value. It' would be understandable, as exmple in documentation with acumulating value of L, that changing parameter in side class affect default value in next call. But this is out of mind. Did you try to execute program on your computer? Does it give same output? I rather consider it bug. Languages like python should be semanticly understandable, without knowing how something works. I read that van Rossum working on it ( clearing something ) in version 3.0, did you try it? Does verison 3.0 correct this? -- Added file: http://bugs.python.org/file18668/unnamed ___ Python tracker <http://bugs.python.org/issue9703> ___On Sat, Aug 28, 2010 at 12:34 AM, Georg Brandl <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Georg Brandl <mailto:ge...@python.org";>ge...@python.org> added the comment: This is by design.  Parameter default values are evaluated when the function is defined, not when it is called.  Therefore, by assigning the default value to an instance attribute, you are basically sharing it between instances.    It's totaly unexpected that changing attribute with difrent name changes parameter value. It' would be understandable, as exmple in documentation with acumulating value of L, that changing parameter in side class affect default    value in next call. But this is out of mind. Did you try to execute program on your computer? Does it give same output? I rather consider it bug. Languages like python should be semanticly understandable, without knowing how    something works. I read that van Rossum working on it ( clearing something ) in version 3.0, did you try it? Does verison 3.0 correct this? ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9703] default param values
vladimir added the comment: On Sat, Aug 28, 2010 at 10:24 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > Rest assured: it's expected behavior. > > Thank you for your cooperation. -- Added file: http://bugs.python.org/file18678/unnamed ___ Python tracker <http://bugs.python.org/issue9703> ___On Sat, Aug 28, 2010 at 10:24 PM, Benjamin Peterson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Benjamin Peterson <mailto:benja...@python.org";>benja...@python.org> added the comment: Rest assured: it's expected behavior. Thank you for your cooperation. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39992] Windows line endings of pyc file detected on Ubuntu
New submission from Vladimir :
I have problem to run pyc file on one machine with Ubuntu Server 18.04.4 LTS.
This is my source code of the file:
#!/root/PycharmProjects/Project/venv/bin/python3.7
print("Hi")
When I compile it in python console with commands:
import py_compile
py_compile.compile('test2.py')
I get test2.cpython-37.pyc file. Then I add execution access by
chmod +x test2.cpython-37.pyc
If I run
./test2.cpython-37.pyc
on first machine (Ubuntu Server 18.04.4 LTS) I get simple "Hi".
But if I run similarly compiled file on other machine with the same OS - Ubuntu
Server 18.04.4 LTS, I get:
./test2.cpython-37.pyc: line 1: $'B\r\r': command not found
./test2.cpython-37.pyc: line 2: syntax error near unexpected token `)'
./test2.cpython-37.pyc: line 2: `z�p^=�@s
ed�dS)ZHiN)�print�rrtest2.py�'
It looks like it is reading Windows line endings. But why? It is created,
compiled and run on Ubuntu machine.
How can I solve this issue, and run this pyc file with the right result on
second machine?
--
messages: 364417
nosy: vladinko0
priority: normal
severity: normal
status: open
title: Windows line endings of pyc file detected on Ubuntu
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39992>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20914] pyopenssl-0.14-1 error
New submission from Vladimir: After update python2.7-pyopenssl-0.13.1-1 to python2.7-pyopenssl-0.14-1 i have this error on opening deluge. Packpage downgrade solv problem. OS: Archlinux /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) [ERROR ] 22:19:53 ui:168 No module named cryptography.hazmat.bindings.openssl.binding Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/deluge/ui/ui.py", line 149, in __init__ from deluge.ui.gtkui.gtkui import GtkUI File "/usr/lib/python2.7/site-packages/deluge/ui/gtkui/__init__.py", line 1, in from gtkui import start File "/usr/lib/python2.7/site-packages/deluge/ui/gtkui/gtkui.py", line 75, in from deluge.ui.client import client File "/usr/lib/python2.7/site-packages/deluge/ui/client.py", line 37, in from twisted.internet import reactor, ssl, defer File "/usr/lib/python2.7/site-packages/twisted/internet/ssl.py", line 25, in from OpenSSL import SSL File "/usr/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in from OpenSSL import rand, crypto, SSL File "/usr/lib/python2.7/site-packages/OpenSSL/rand.py", line 11, in from OpenSSL._util import ( File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 3, in from cryptography.hazmat.bindings.openssl.binding import Binding ImportError: No module named cryptography.hazmat.bindings.openssl.binding -- components: Library (Lib) messages: 213438 nosy: Vladimir priority: normal severity: normal status: open title: pyopenssl-0.14-1 error type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
New submission from Vladimir Feinberg : I have a request related to the rejected proposal (https://bugs.python.org/issue43255) to introduce a ceildiv operator. I frequently find myself wishing for a ceildiv function which computes `ceil(x/y)` for integers `x,y`. This comes up all the time when "batching" some resource and finding total consumption, be it for memory allocation or GUI manipulation or time bucketing or whatnot. It is easy enough to implement this inline, but `math.ceildiv` would express intent clearly. ``` # x, y, out: int # (A) import math out = math.ceil(x / y) # clear intent but subtly changes type, and also incorrect for big ints # (B) out = int(math.ceil(x / y)) # wordy, especially if using this multiple times, still technically wrong # (C) out = (x + y - 1) // y # too clever if you haven't seen it before, does it have desirable semantics for negatives? # (D) out = -(-x//y) def ceildiv(a: int, b: int) -> int: # Clearest and correct, but should my library code really invent this wheel? """Returns ceil(a/b).""" return -(-x//y) out = ceildiv(x, y) ``` Even though these are all "one-liners", as you can see leaving people to complex manually-implemented `ceildiv`s might result in bugs or unclear handling of negatives. -- components: Library (Lib) messages: 412527 nosy: Vladimir Feinberg priority: normal severity: normal status: open title: Ceil division with math.ceildiv type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
Vladimir Feinberg added the comment: Mark, I will say I'm pretty sympathetic to the feature-bloat avoidance perspective here, and if the outcome here is to improve docs, that's still a win, I think. That said, since this thread will become precedent, and I think `math.ceildiv` is the exactly-appropriate amount of commitment Lib should make to the function (not __ceildiv__ and not "just" a doc note), let me try to give `ceildiv` the strongest legs I can think of before we make a decision. 1. Not needing an import - I don't find importing such a standard library as `math` that onerous. We're not adding a new package here, just a function. This skepticism could be applied to any existing library function. Even `sys.stdout` needs an import. 2. Natural duck typing - I'll admit, this is pretty nice. But if that's the argument, I'd expect this to work to its fullest extent. Namely, I'd expect this to "naturally" work for any ring, and it doesn't. Z/nZ is a common one and np.uint is a more common one where the identity -(-x // y) = ceildiv(x, y) does not hold. The benefit of `math.ceildiv` is it'd either support it, or say it doesn't, but at least it's explicit. 3. Thin end of wedge - A priori, I would put ceildiv as special because of the "resource coverage" use case I described in my initial bug message. A posteriori, there's a clear "kink" in the graph of usage here: ceildiv (3033) <https://github.com/search?l=&q=ceildiv+language%3APython&type=code>, rounddiv (25) <https://github.com/search?q=rounddiv+language%3APython&type=code>, roundmod (7) <https://github.com/search?q=roundmod+language%3APython&type=code>, ceilrem (0) <https://github.com/search?q=ceilrem+language%3APython&type=code>, ceildivrem (0) <https://github.com/search?q=ceildivrem+language%3APython&type=code>. But most importantly, let me detail what motivated me to post this. I was working on unit tests for linear algebra code which blocked its operations. But to not involve a lot of context, I'll provide a similarly-structured use case. Say we're making a controller for a game engine GUI and need to figure out how to paint sprites. ``` # sprite_A.py class A: def get_covering_rectangle(): return self.x, self.y, self.x - (-self.width // GRID_WIDTH), self.y - (-self.height // GRID_HEIGHT) ``` Especially if I also use `-(-x//y)` elsewhere, this is just asking too much of the reader. I could leave a comment to the tune of `# Note below is equivalent to + (-(-x//y)), the ceildiv operator, and this works because x isn't a uint`. Should I do this at all usage sites? I'd end up factoring into my own `ceildiv` for clarity, especially if I use this elsewhere, like a test. Where should this hand-rolled ceildiv live, if not recreated in everyone's code? It seems too light to wrap as its own dependency, and we probably don't want to go down the leftpad <https://www.theregister.com/2016/03/23/npm_left_pad_chaos/> path. `math` seems most apt. On Sat, Feb 5, 2022 at 8:31 AM Mark Dickinson wrote: > > Mark Dickinson added the comment: > > I'm not convinced that this deserves to be a math module function. I agree > that `-(-x // y)`, while simple to write, isn't necessarily obvious. But it > does have some advantages, like not needing an import, and being naturally > duck-typed, so that it automatically does the right thing for floats, or > `fractions.Fraction` objects, or `numpy.int64` objects, or SymPy integers. > (Not for `Decimal` instances, but that's another story.) Unless we were to > add a whole __ceildiv__ mechanism, a math module implementation would > necessarily be limited to integers. (Or perhaps integers and floats.) > > There's also the "thin end of the wedge" argument: if ceildiv, why not > also ceilrem, ceildivrem, rounddiv, roundmod, etc. > > The main issue with the `-(-x // y)` spelling seems to be discoverability: > if everyone knew that this was the right way to spell ceiling division, > then there wouldn't be a problem. And I'm not convinced that a math.ceildiv > function would necessarily solve the discoverability problem, either. > > So maybe the solution is to advertise the `-(-x // y)` pattern better in > documentation, for example at the point where floor division is introduced > in the library reference? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue46639> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46787] ProcessPoolExecutor exception memory leak
New submission from Vladimir Vinogradenko : If an exception occurs in ProcessPoolExecutor work item, all the exception frame local variables are not garbage collected (or are garbage collected too lately) because they are referenced by the exception's traceback. Attached file is a test case. With unpatched python 3.9 (debian bullseye) it prints: root@truenas[~/freenas/freenas]# python test.py At iteration 0 memory usage is 226070528 At iteration 1 memory usage is 318763008 At iteration 2 memory usage is 318509056 At iteration 3 memory usage is 321662976 At iteration 4 memory usage is 321404928 At iteration 5 memory usage is 324292608 At iteration 6 memory usage is 324296704 At iteration 7 memory usage is 326922240 At iteration 8 memory usage is 326922240 At iteration 9 memory usage is 329543680 With the proposed patch there is no memory usage growth: At iteration 0 memory usage is 226410496 At iteration 1 memory usage is 226451456 At iteration 2 memory usage is 226451456 At iteration 3 memory usage is 226443264 At iteration 4 memory usage is 226443264 At iteration 5 memory usage is 226435072 At iteration 6 memory usage is 226426880 At iteration 7 memory usage is 226426880 At iteration 8 memory usage is 226435072 At iteration 9 memory usage is 226426880 -- components: Library (Lib) files: 1.py messages: 413485 nosy: themylogin priority: normal severity: normal status: open title: ProcessPoolExecutor exception memory leak type: resource usage versions: Python 3.9 Added file: https://bugs.python.org/file50628/1.py ___ Python tracker <https://bugs.python.org/issue46787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX
Vladimir Konjkov added the comment: look this http://www.mail-archive.com/python-bugs-list%40python.org/msg07749.html it's for python-2.3.5 under qnx4.25. about pyport.h under qnx4.25: I include "unix.h" instead of definition of function openpty()+forkpty() in pyport.h, openpty()+forkpty() naturaly defined in "unix.h" but configure doesn't knows. -- nosy: +Konjkov _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX
Vladimir Konjkov added the comment: However, I don't understand this entire point: What do you mean by "using TCGETA requires that struct termio be defined"? How is TCGETA defined to produce such a dependency? TCGETA is a constant, right? --- terminal I/O control has three different implementations under SVR4, BSD, and POSIX.1. SVR4 uses the termio structure, and various ioctl calls (such as TCGETA, TCSETA, TCSETAW, and TCSETAF) on a terminal device to obtain and set parameters with the termio structure. Under POSIX, the termios struct is used, along with various functions defined by POSIX.1, such as tcsetattr and tcgetattr. Under QNX - is POSIX implimentation with functions tcsetattr and tcgetattr defined, but in that included in define MACROS TCGETA, TCSETA, TCSETAW, and TCSETAF. That's why we need or simlink . Why do you want TCGETA, TCSETA, TCSETAW, and TCSETAF in Python if there is POSIX tcsetattr and tcgetattr functions? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX
Vladimir Konjkov added the comment: addition TCGETA is a constant. That's right! under QNX4 TCGETA defined as MACRO in . That's right! in Modules/termios.c there's #include That's right too! What's problem after all? Problem is that MACRO definition of TCGETA need sizeof(struct termio), that's (struct termio) defined in . But not included in instead of it included in and we need, if we want to have TCGETA, start with that's included both and too and do it right way! It's clearly now? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12223] Datamodel documentation page: 'operator' where 'operand' should be
New submission from Vladimir M. : The page at (http://docs.python.org/reference/datamodel.html) says: "In x * y, if one operator is a sequence that implements sequence repetition". Obviuosly, it should be changed to: "In x * y, if one operand is a sequence that implements sequence repetition". -- assignee: docs@python components: Documentation messages: 137352 nosy: Vladimir.M., docs@python priority: normal severity: normal status: open title: Datamodel documentation page: 'operator' where 'operand' should be versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12389] typo in urllib: missing space after dot at sentence end
New submission from Vladimir Rutsky : There is a typo in urllib module documentation: missing space after dot at sentence end. Please see attached path for details. -- assignee: docs@python components: Documentation files: urllib-typo-space-after-dot.patch keywords: patch messages: 138838 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in urllib: missing space after dot at sentence end versions: Python 2.7 Added file: http://bugs.python.org/file22425/urllib-typo-space-after-dot.patch ___ Python tracker <http://bugs.python.org/issue12389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10113] UnicodeDecodeError in mimetypes.guess_type on Windows
Changes by Vladimir Dmitriev : -- components: Library (Lib), Windows files: mime content types.reg nosy: vldmit priority: normal severity: normal status: open title: UnicodeDecodeError in mimetypes.guess_type on Windows type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file19242/mime content types.reg ___ Python tracker <http://bugs.python.org/issue10113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10113] UnicodeDecodeError in mimetypes.guess_type on Windows
New submission from Vladimir Dmitriev :
Windows 7, Python 2.7
Some windows applications (QuickTime) add content-types to Windows registry
with non-ascii names. mimetypes in unaware of that and fails with
UnicodeDecodeError:
>>> mimetypes.guess_type('test.js')
Traceback (most recent call last):
File "", line 1, in
File "c:\Python27\lib\mimetypes.py", line 294, in guess_type
init()
File "c:\Python27\lib\mimetypes.py", line 355, in init
db.read_windows_registry()
File "c:\Python27\lib\mimetypes.py", line 260, in read_windows_registry
for ctype in enum_types(mimedb):
File "c:\Python27\lib\mimetypes.py", line 250, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal
not in range(128)
Example registry leaf is attached to previous message.
I believe the correct behavior would be either to wrap UnicodeDecodeError
exception and skip those content-typer or use .decode() method for registry
keys and get encoding using locale.getdefaultlocale()
--
___
Python tracker
<http://bugs.python.org/issue10113>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
Vladimir Iofik added the comment: Here is a better patch. -- nosy: +vj Added file: http://bugs.python.org/file19332/9291a.patch ___ Python tracker <http://bugs.python.org/issue9291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
Vladimir Iofik added the comment: UnicodeDecodeException is thrown because 'ctype' is already a string, so it is first implicitly decoded by default encoder (which is 'ascii') and then reencoded back. I see no reason in all these actions, so I simply removed them. I think Antoine Pitrou (who is the author of these lines) can shed some light on this, but I guess it's just a copy-paste of the code below. -- ___ Python tracker <http://bugs.python.org/issue9291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11902] typo in argparse doc's: "action.."
New submission from Vladimir Rutsky : There is a typo in argparse module documentation: "The ``nargs`` keyword argument associates a different number of command-line arguments with a single action.." (two dots at end). Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_action_dot_dot.patch keywords: patch messages: 134237 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: "action.." versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21751/argparse_typo_action_dot_dot.patch ___ Python tracker <http://bugs.python.org/issue11902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11904] incorrect reStructuredText formatting in argparse module
New submission from Vladimir Rutsky : In Python 2.7 and 3 branch at http://svn.python.org/projects/python/branches/py3k/ file Doc/library/argparse.rst has incorrectly formatted list at line 648: > * ``'store'`` - This just stores the argument's value. This is the default >action. For example:: Second line must be indented according to first line. Next item at line 656 has invalid indentation too. -- assignee: docs@python components: Documentation messages: 134240 nosy: docs@python, rutsky priority: normal severity: normal status: open title: incorrect reStructuredText formatting in argparse module versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue11904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11905] typo in argparse doc's: missing dot at end of sentence
New submission from Vladimir Rutsky : There is missed dot at end of sentence in argparse module documentation. Please see attached patch for details. Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_missing_dot.patch keywords: patch messages: 134241 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: missing dot at end of sentence versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21752/argparse_typo_missing_dot.patch ___ Python tracker <http://bugs.python.org/issue11905> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10651] chr(13) is added before chr(10) when issuing ".write" under windows
New submission from Vladimir K : The following code (see attached file) was intended to remove chr(13) from end-of-lines under Windows to make the file Unix-compliant but it always appends chr(13) before chr(10). I'm under Windows XP. -- components: IO, Windows files: chr13remove.py messages: 123608 nosy: KZM priority: normal severity: normal status: open title: chr(13) is added before chr(10) when issuing ".write" under windows versions: Python 2.7 Added file: http://bugs.python.org/file19976/chr13remove.py ___ Python tracker <http://bugs.python.org/issue10651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10846] typo in threading doc's: "size of the resource size"
New submission from Vladimir Rutsky : I think there is a typo in threading documentation: > In any situation where the size of the resource size is fixed, > you should use a bounded semaphore. - "size of the resource size", see attached patch for proposed fix. (Based on official http://svn.python.org/projects/python/branches/py3k/ repository.) -- assignee: d...@python components: Documentation files: threading_typo_size_of_size.patch keywords: patch messages: 125580 nosy: d...@python, rutsky priority: normal severity: normal status: open title: typo in threading doc's: "size of the resource size" versions: Python 3.3 Added file: http://bugs.python.org/file20293/threading_typo_size_of_size.patch ___ Python tracker <http://bugs.python.org/issue10846> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
New submission from Vladimir Rutsky : This is code from recent trace.py (http://svn.python.org/view/python/branches/release27-maint/Lib/trace.py?view=markup): trace.py:169: # Ignore a file when it contains one of the ignorable paths for d in self._dirs: # The '+ os.sep' is to ensure that d is a parent directory, # as compared to cases like: # d = "/usr/local" # filename = "/usr/local.py" # or # d = "/usr/local.py" # filename = "/usr/local.py" if filename.startswith(d + os.sep): self._ignore[modulename] = 1 return 1 Directories comparison like "filename.startswith(d + os.sep)" works incorrect on case-insensitive filesystems (such as NTFS on Windows). This leads to confusing results on Windows: python trace.py --ignore-dir='$prefix' -t test.py or python trace.py --ignore-dir C:\Python26\Lib -t test.py shows all calls from standard library, but this one doesn't: python trace.py --ignore-dir=c:\python26\lib -t test.py See attached test files and log for details. -- components: Library (Lib) files: test.py messages: 126101 nosy: vrutsky priority: normal severity: normal status: open title: trace module compares directories as strings (--ignore-dir) versions: Python 2.7 Added file: http://bugs.python.org/file20368/test.py ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by Vladimir Rutsky : Added file: http://bugs.python.org/file20369/test.cmd ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by Vladimir Rutsky : Added file: http://bugs.python.org/file20370/test.out ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: Workaround for people on Windows who don't wan't to modify trace.py: to get clean trace of only your project calls add to ignore list python path with mix of character cases. For me worked out this string: python -m trace --ignore-dir=c:\python26\lib;C:\python26\lib;C:\Python26\Lib -t main.py -- ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: SilentGhost, thanks for the patch! I can confirm, that adding os.path.normcase fixes issues with different cases of files. I believe there also may be issue with FAT's long file name mangling, like "C:\PROGRA~1\python26\" instead of "C:\Program Files\python26\". But never experienced such issue with Python. -- ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: Sorry I was wrong - patch don't fix original issue. Case should be normalized not only for directories provided through --ignore-dir, but also for directories obtained from __file__. In my tests on Windows Ignore.names(self, filename, modulename) receives `filename''s argument like: C:\Python26\Lib\site-packages\shapely\__init__.pyc Attaching patch fixes this issue for me (for Python 2.7 from http://svn.python.org/projects/python/branches/release27-maint, patch attached by SilentGhost is for 3.X I think). -- nosy: +SilentGhost Added file: http://bugs.python.org/file20452/trace_ignore_case_fix.patch ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX
Vladimir Konjkov added the comment: willing you implement thread support for qnx6, or may be qnx4? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX 6
Vladimir Konjkov added the comment: For _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED look this http://opengroup.org/onlinepubs/007908775/xcurses/implement.html _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX 6
Vladimir Konjkov added the comment: there is script Misk/find_recursionlimit.py that can help to find real recursion limit for QNX4 for one recursion used ~900 kb of stack thus 1Mb sufficient for default recursion limit = 1000. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue175> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46965] Enable informing callee it's awaited via vector call flag
Change by Vladimir Matveev : -- nosy: +v2m ___ Python tracker <https://bugs.python.org/issue46965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46965] Enable informing callee it's awaited via vector call flag
Vladimir Matveev added the comment:
- introducing dedicated opcodes for each kind of awaited call is definitely an
option. In fact first implementation used it however as Dino has mentioned it
was more of a logistical issue (there were several spots that produced .pyc
files so compiler needed to be up to date across all of them).
- there was some perf win that was coming from rewriting `gather` in C however
main reason for us to do it was the ability to be await-aware which we made
only available in C (also returning completed waithandle is not exposed to
Python either) to reduce the scope. Providing ability to follow await-aware
protocol (read indicator that call is awaited + return completed waithandle for
eagerly completed calls) in pure Python is definitely possible
- to provide some context why it was beneficial: typical implementation of
endpoint in IG is an async function that in turn calls into numerous other
async functions to generate an output.
- `gather` is used all over the place in case if there are no sequential
dependency between calls
- amount of unique pieces of data that are ultimately fetched by async calls
is not very big, i.e. the same fragment of information can be requested by
different async calls which makes memoization a very attractive strategy to
reduce I/O and heavyweight computations.
- memoized pieces of data is represented effectively by completed futures and
it is very common to have `gather` accept either memoized value or coroutine
object that will be completed synchronously by awaiting memoized value.
Before making gather await-aware if always have to follow the standard process
and convert awaitables into tasks that are queued into the event loop for
execution. In our workload task creation/queueing were adding a noticeable
overhead. With await-aware gather we can execute coroutine objects eagerly and
if they were not suspended - bypass task creation entirely.
```
import asyncio
import time
async def step(i):
if i == 0:
return
await asyncio.gather(*[step(i - 1) for _ in range(6)])
async def main():
t0 = time.perf_counter()
await step(6)
t1 = time.perf_counter()
print(f"{t1 - t0} s")
N = 0
def create_task(loop, coro):
global N
N += 1
return asyncio.Task(coro, loop=loop)
loop = asyncio.get_event_loop()
loop.set_task_factory(create_task)
loop.run_until_complete(main())
print(f"{N} tasks created")
# Cinder
# 0.028410961851477623 s
# 1 tasks created
# Python 3.8
# 1.2157012447714806 s
# 55987 tasks created
```
--
___
Python tracker
<https://bugs.python.org/issue46965>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
New submission from Vladimir Ryabtsev : This is regarding the page https://docs.python.org/3.7/library/sqlite3.html. I believe this section on the very bottom of the page has been kept here for pretty long time, during that both SQLite and the sqlite3 module evolved and improved. Now the content contradicts to the description of function "connect()" in the part describing "check_same_thread" parameter. The function description says that using connections from multiple threads is allowed with serialization handled by the user (and it is true), while the bottom "Mutithreading" section says sharing connections is not allowed. I think we can remove "Mutithreading" section entirely unless there is something important to add to what already mentioned. -- assignee: docs@python components: Documentation messages: 354227 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Remove or change "Multithreading" section versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver
New submission from Vladimir Matveev :
Calling methods and lookup up attributes when receiver is `super()` has extra
cost comparing to regular attribute lookup. It mainly comes from the need to
allocate and initialize the instance of the `super` which for zero argument
case also include peeking into frame/code object for the `__class__` cell and
first argument. In addition because `PySuper_Type` has custom implementation of
tp_getattro - `_PyObject_GetMethod` would always return bound method.
```
import timeit
setup = """
class A:
def f(self): pass
class B(A):
def f(self): super().f()
def g(self): A.f(self)
b = B()
"""
print(timeit.timeit("b.f()", setup=setup, number=2000))
print(timeit.timeit("b.g()", setup=setup, number=2000))
7.329449548968114
3.892987059080042
```
One option to improve it could be to make compiler/interpreter aware of super
calls so they can be treated specially. Attached patch introduces two new
opcodes LOAD_METHOD_SUPER and LOAD_ATTR_SUPER that are intended to be
counterparts for LOAD_METHOD and LOAD_ATTR for cases when receiver is super
with either zero or two arguments.
Immediate argument for both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER is a pair
that consist of:
0: index of method/attribute in co_names
1: Py_True if super was originally called with 0 arguments and Py_False
otherwise.
Both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER expect 3 elements on the stack:
TOS3: global_super
TOS2: type
TOS1: self/cls
Result of LOAD_METHOD_SUPER is the same as LOAD_METHOD.
Result of LOAD_ATTR_SUPER is the same as LOAD_ATTR
In runtime both LOAD_METHOD_SUPER and LOAD_ATTR_SUPER will check if
`global_super` is `PySuper_Type` to handle situations when `super` is patched.
If `global_super` is `PySuper_Type` then it can use dedicated routine to
perform the lookup for provided `__class__` and `cls/self` without allocating
new `super` instance. If `global_super` is different from `PySuper_Type` then
runtime will fallback to the original logic using `global_super` and original
number of arguments that was captured in immediate.
Benchmark results with patch:
4.381768501014449
3.9492998640052974
--
components: Interpreter Core
messages: 389114
nosy: v2m
priority: normal
severity: normal
status: open
title: Use dedicated opcodes to speed up calls/attribute lookups with super()
as receiver
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43563>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +23696 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24936 ___ Python tracker <https://bugs.python.org/issue43563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver
Vladimir Matveev added the comment: >Currently, super() is decoupled from the core language. It is just a builtin >that provides customized attribute lookup. This PR makes super() more tightly >integrated with the core language, treating it as if it were a keyword and >part of the grammar. Also note, users can currently create their own versions >of super(), shadowing the builtin super(). This is true however: - this patch does not block people from introducing custom version of `super` so this scenario still work. The idea was to streamline the common case - based on digging into Instagram codebase and its transitive dependencies (which is reasonably large amount of code) all spots where `super()` appear in sources assume `super` to be builtin and for a pretty common use-case its cost is noticeable in profiler. - zero-argument `super()` still a bit magical since it requires compiler support to create cell for `__class__` and assumes certain shape of the frame object so this patch is a step forward with a better compiler support and removing runtime dependency on the frame > Do you have any evidence that the overhead of super() is significant in real > programs I do see the non-negligible cost of allocation/initialization of `super` object in IG profiling data. -- ___ Python tracker <https://bugs.python.org/issue43563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43698] Use syntactically correct examples on abc package page
New submission from Vladimir Ryabtsev : There are code snippets on the package's page (https://docs.python.org/3.10/library/abc.html) like this: class C(ABC): @classmethod @abstractmethod def my_abstract_classmethod(cls, ...): ... Here, the author probably wanted to demonstrate that the method may have _any other arguments_ in addition to `cls`, but it makes the code not compilable: def my_abstract_classmethod(cls, ...): ^ SyntaxError: invalid syntax Additionally it uses the same Ellipsis as in the method's body (that is supposed to indicate a stub), which is confusing. I think that all code samples must be syntactically correct, so that if a reader copypastes them into their code editor they would work right away. I suggest to remove ellipsis in the argument lists everywhere on the page and replace them with one of the following: - sample parameters such as `a, b, c` or `my_arg1, my_arg2`, - `*args, **kwargs`, - nothing. -- assignee: docs@python components: Documentation messages: 390004 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Use syntactically correct examples on abc package page type: compile error versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver
Vladimir Matveev added the comment: Apologies for the delay in reply: in more concrete numbers for IG codebase enabling this optimization resulted in 0.2% CPU win. -- ___ Python tracker <https://bugs.python.org/issue43563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- pull_requests: +22974 pull_request: https://github.com/python/cpython/pull/24145 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- stage: patch review -> resolved status: open -> closed versions: +Python 3.10 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: The issue won't be fixed, but other useful changes applied. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
New submission from Vladimir Feinberg :
Python's standard logger provides an exception() method, which is to be called
from except blocks to log out exception traces by pulling from sys.exc_info().
Per https://github.com/python/cpython/blob/3.9/Lib/logging/__init__.py#L617 ,
logger.exception('my message') eventually boils down to something like
traceback.print_exception(ei[0], ei[1], ei[2], None, some_buffer) where ei is
the sys.exc_info().
However, the traceback code generates that printout by constructing a
TracebackException recursively for every `except` context.
In turn, if a RecursionError was generated from an exception thrown across many
except blocks, the TracebackException construction itself will have a
RecursionError. This is particularly bad in cases where you'd want to capture
this failure information, such as when you're printing the exception, since
you'll never find out about the originating error.
Certain (well-used) libraries rely on try/except for control flow, and
occasionally do recurse in their except blocks, so such exceptions are not
hypothetical.
A solution to this might be to avoid constructing a TracebackException, and
instead unwind traceback context using a while loop.
--
components: Library (Lib)
files: exc.py
messages: 385828
nosy: vlad2
priority: normal
severity: normal
status: open
title: Printing RecursionError results in RecursionError
versions: Python 3.6, Python 3.7, Python 3.9
Added file: https://bugs.python.org/file49769/exc.py
___
Python tracker
<https://bugs.python.org/issue43048>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
Vladimir Feinberg added the comment: I agree with both the duplicate classification and am glad the fix works in 3.10. Thanks all for the responses. Given the issue can be triggered with a fairly benign setup (pandas triggers such an error, and logger.exception is idiomatic), I do think backport should be worth consideration, but maybe I'm overindexing on the frequency of such exceptions in the wild. -- ___ Python tracker <https://bugs.python.org/issue43048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
Vladimir Feinberg added the comment: A simple catch may not work (the very first TracebackException is the one that gets the RecursionError during initialization of its __context__), but one thing I was thinking about was walking the __context__ pointers and nulling out anything past the sys.getrecursionlimit() with a warning. On Sat, Jan 30, 2021 at 10:00 AM Irit Katriel wrote: > > Change by Irit Katriel : > > > -- > keywords: +easy > > ___ > Python tracker > <https://bugs.python.org/issue43048> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
Vladimir Feinberg added the comment: Oh, yes, I suppose, that'll truncate to just the first TracebackException. On Mon, Feb 1, 2021 at 4:38 PM Irit Katriel wrote: > > Irit Katriel added the comment: > > I meant to catch the exception in the constructor’s recursive call, and if > necessary then the same again in format (if there are more function calls > per exception in format, it will be necessary. The unit test from the 3.10 > patch will tell). > > Would that not work? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43048> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
Vladimir Feinberg added the comment: Yep, you're right. I'd be happy to (but I've never done it before, so please give me some time). On Tue, Feb 2, 2021 at 12:35 AM Irit Katriel wrote: > > Irit Katriel added the comment: > > It should truncate at the call that raised the recursion error, not the > first one. Do you want to create a patch? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43048> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43048] Printing RecursionError results in RecursionError
Change by Vladimir Feinberg : -- keywords: +patch pull_requests: +23256 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24460 ___ Python tracker <https://bugs.python.org/issue43048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
New submission from Vladimir Matveev :
Currently async functions are more expensive to use comparing to their sync
counterparts. A simple microbenchmark shows that difference could be quite
significant:
```
import time
def f(a):
if a == 0:
return 0
return f(a - 1)
async def g(a):
if a == 0:
return 0
return await g(a - 1)
N = 10
C = 200
t0 = time.time()
for _ in range(N):
f(C)
t1 = time.time()
for _ in range(N):
try:
g(C).send(None)
except StopIteration:
pass
t2 = time.time()
print(f"Sync functions: {t1 - t0} s")
print(f"Coroutines: {t2 - t1} s")
```
Results from master on my machine:
Sync functions: 2.8642687797546387 s
Coroutines: 9.172159910202026 s
NOTE: Due to viral nature of async functions their number in codebase could
become quite significant so having hundreds of them in a single call stack is
not something uncommon.
One of reasons of such performance gap is that async functions always return
its results via raising StopIteration exception which is not cheap. This can be
avoided if in addition to `_PyGen_Send` always return result via exception we
could have another function that will allow us to distinguish whether value
that was returned from generator is a final result (return case) of whether
this is yielded value.
In linked PR I've added function `_PyGen_SendNoStopIteration` with this
behavior and updated ceval.c and _asynciomodule.c to use it instead of
`_PyGen_Send` which resulted in a measurable difference:
Sync functions: 2.8861589431762695 s
Coroutines: 5.730362176895142 s
--
messages: 376698
nosy: v2m, yselivanov
priority: normal
severity: normal
status: open
title: Do not always use exceptions to return result from coroutine
type: performance
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +21255 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22196 ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: If I understand proposed shape of API correctly - it was not supposed to return exception via "result" so contract for new `PyGen_Send` function is something like: Return value | result | Comment - PYGEN_RETURN | not NULL | Returned value PYGEN_NEXT | not NULL | Yielded value PYGEN_ERROR | NULL | Regular PyErr_* functions should be used to work with error case -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment:
Also should it be specific to generators/coroutines and accept PyGenObject* or
should it try to handle multiple cases and expose the result for them in
uniform way, i.e.
```
if (PyGen_CheckExact(gen) || PyCoro_CheckExact(gen)) {
// use coroutine/generator specific code that avoids raising exceptions
*result = ...
return PYGEN_RETURN;
}
PyObject *ret;
if (arg == Py_None) {
ret = Py_TYPE(gen)->tp_iternext(gen);
}
else {
ret = _PyObject_CallMethodIdOneArg(coro, &PyId_send, arg);
}
if (ret != NULL) {
*result = ret;
return PYGEN_YIELD;
}
if (_PyGen_FetchStopIterationValue(result) == 0) {
return PYGEN_RETURN;
}
return PYGEN_ERROR;
```
--
___
Python tracker
<https://bugs.python.org/issue41756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: I guess `PyIter_Send` would imply that this function should work for all inputs (like in https://bugs.python.org/msg377007) which also sounds reasonable. -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: so to summarize: Proposed function signature: ``` PySendResult PyIter_Send(PyObject *obj, PyObject *arg, PyObject **result); ``` For generators/coroutines function will delegate to specialized implementation that does not raise StopIteration exception For types that provide `tp_iternext` if arg is Py_None function call invoke `Py_TYPE(obj)->tp_iternext(obj)` For all other cases function will try to call `send` method Regarding of the case function will not raise StopIteration and will always return pair status/result. Does it sound correct? -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: Sounds like a good middleground to start: add ``PySendResult `` and `PySendResult PyGen_Send(PyGenObject*, PyObject* PyObject**)` specific to generators and coroutines. Subsequent changes could introduce `PySendResult PyIter_Send(PyObject*, PyObject*, PyObject**)` that would be more generic (call tp_next, invoke "send" or maybe in the future use dedicated slot for "send" operator so i.e. asyncio.Future or Cython coroutines could benefit from the same optimization) -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: Yes, it should be -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment: Serhiy, AFAIR PyIter_Send in my PR appear only as a rename from placeholder `Name_TBD` and it still was specific to PyGenObjects. Do you mean something that was listed in https://bugs.python.org/msg377007 ? -- ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Vladimir Matveev added the comment:
No, I don't think so but I can definitely make one. A few questions first:
- having PySendResult as a result type of PyIterSend seems ok, however prefix
for each concrete value (PYGEN_*) is not aligned with the prefix of the
function itself (PyIter_)
- should it also deal with tstate->c_tracefunc (probably not) or just be
something like
```
PySendResult
PyIter_Send(PyObject *iter, PyObject *arg, PyObject **result)
{
_Py_IDENTIFIER(send);
assert(result != NULL);
if (PyGen_CheckExact(iter) || PyCoro_CheckExact(iter)) {
return PyGen_Send((PyGenObject *)iter, arg, result);
}
if (arg == Py_None && Py_TYPE(iter)->tp_iternext != NULL) {
*result = Py_TYPE(iter)->tp_iternext(iter);
}
else {
*result = _PyObject_CallMethodIdOneArg(iter, &PyId_send, arg);
}
if (*result == NULL) {
if (_PyGen_FetchStopIterationValue(result) == 0) {
return PYGEN_RETURN;
}
return PYGEN_ERROR;
}
return PYGEN_NEXT;
}
```
--
___
Python tracker
<https://bugs.python.org/issue41756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Change by Vladimir Matveev : -- pull_requests: +21473 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/22443 ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Change by Vladimir Matveev : -- pull_requests: +21639 pull_request: https://github.com/python/cpython/pull/22663 ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41756] Do not always use exceptions to return result from coroutine
Change by Vladimir Matveev : -- pull_requests: +21649 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/22677 ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42085] Add dedicated slot for sending values
New submission from Vladimir Matveev :
https://bugs.python.org/issue41756 has introduced PyIter_Send as a common
entrypoint for sending values however currently fast path that does not use
StopIteration exception is only available for generators/coroutines. It would
be quite nice if this machinery was extensible and other types (both internal
and 3rd party) could opt-in into using exception-free way of returning values
without needing to update the implementation of PyIter_Send. One way of solving
this is adding a new slot with a signature that matches PyIter_Send. With it:
- it should be possible to implement this slot for coroutines/generators and
remove special casing for them in PyIter_Send
- provide implementation for this slot for internal types (i.e. FutureIter in
_asynciomodule.c) - results of this experiment can be found below
- enable external native extensions to provide efficient implementation of
coroutines (i.e. Cython could benefit from it)
Microbenchmark to demonstrate the difference of accessing the value of fulfiled
Future without and with dedicated slot:
```
import asyncio
import time
N = 1
async def run():
fut = asyncio.Future()
fut.set_result(42)
t0 = time.time()
for _ in range(N):
await fut
t1 = time.time()
print(f"Time: {t1 - t0} s")
asyncio.run(run())
```
Time: 8.365560054779053 s - without the slot
Time: 5.799655914306641 s - with the slot
--
components: Interpreter Core
messages: 378999
nosy: v2m
priority: normal
severity: normal
status: open
title: Add dedicated slot for sending values
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42085] Add dedicated slot for sending values
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +21739 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22780 ___ Python tracker <https://bugs.python.org/issue42085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42085] Add dedicated slot for sending values
Change by Vladimir Matveev : -- type: -> performance ___ Python tracker <https://bugs.python.org/issue42085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42113] Replace _asyncio.TaskWakeupMethWrapper with PyCFunction
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +21817 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22875 ___ Python tracker <https://bugs.python.org/issue42113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42113] Replace _asyncio.TaskWakeupMethWrapper with PyCFunction
New submission from Vladimir Matveev : `TaskWakeupMethWrapper` looks like a more limited version of `PyCFunction` so it can be replaced with one. Pros: remove a bunch of code, use better calling convention Cons: now `wakeup` object will expose slightly more properties but I'm not sure whether this is bad -- components: asyncio messages: 379258 nosy: asvetlov, v2m, yselivanov priority: normal severity: normal status: open title: Replace _asyncio.TaskWakeupMethWrapper with PyCFunction versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: I see no point in researching the version of sqlite, since Python does not allow user to specify it, you just use the compiled version that comes with Python distribution. 10 years now to the commit that introduced that piece of text: https://github.com/python/cpython/commit/c34d76cdc3212615f9a3c2c4b1c542592372b5f8 Let's just remove it, what it says is simply not true. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: May by I was wrong above and it uses system's Sqlite... But anyway it does not cancel the fact that this section contradicts to another one. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: Also the footnote requires some minor corrections (formatting and style). I suggest the following wording: To get loadable extension support, your Python must be compiled with ``-–enable-loadable-sqlite-extensions`` option in ``PYTHON_CONFIGURE_OPTS``. I believe otherwise it is basically not clear what is said here. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
New submission from Vladimir Ryabtsev : A new section has been added to the page as a result of https://bugs.python.org/issue37826. The change: https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dcf59392 The wording it uses (in the beginning of section 8.5), defines chaining as setting __cause__ attribute in an exception, and later states that "Exception chaining happens automatically when an exception is raised inside an exception handler or finally section". This may lead the reader to a wrong idea that re-raising an exception without "from" in "except" and "finally" automatically sets __cause__. In reality it sets only __context__ attribute, which is similar concept to __cause__, but work a bit differently, as explained in library/exceptions.rst. I suggest to mention that difference and provide a link to the main article. -- assignee: docs@python components: Documentation messages: 379823 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Clarify chaining exceptions in tutorial/errors.rst versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- pull_requests: +22071 pull_request: https://github.com/python/cpython/pull/23159 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Change by Vladimir Ryabtsev : -- keywords: +patch pull_requests: +22072 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23160 ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: 1. Such understanding of a tutorial is debatable. Tutorial is just a material for learning written with some system in mind, which is more interesting to read than dry reference material. A tutorial, generally dpeaking, may be both for beginners and for professionals. 2. The question about exception chaining is popular on Stackoverflow in people who came to Python with Java or C# background (see “python inner exception”). 3. Whatever material is given, it should not cause confusion, but now it does. Since this section has been added recently, it is better to fix it rather than remove entirely, aren’t you agree? -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: > I can not find confusion caused by this tutorial section Inada, have you read the very first message in this ticket? It explains why this wording may cause confusion (and it did in me), and describes the problem part. A link for your convenience: https://docs.python.org/3/tutorial/errors.html#exception-chaining > Describing the default behavior and "from None" is enough for new users Strange that you think that "from None" is more useful for beginners than these special attributes. Without understanding of __cause__ and __context__, stack traceback message looks like magic. Say you want to handle an exception and retrieve its cause (context) in runtime (this is what exception chaining for) – this section makes no clues about how to do that. -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: We have automatic chaining, so you don't need to use "from X" unless you want to have some control on the traceback message. Even without knowing of this syntax (and without using "from exc"), a user will get a traceback message similar to what is shown in the example. What is the purpose of the entire section then? As I see it, the purpose might be providing some details about how exactly chaining works, so a user: a) could make an informed decision whether they need "from X" or not, b) would know how to retrieve the linked exception programmatically. I generally feel that we don't want to deprive a user from special attributes, in Python they are everywhere, you cannot even construct a class instance without __init__(). -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: Also, the choice of the exception type in the example looks not very apt: you raise "IOError" but the traceback message says "OSError" (which is due to strange design decision "IOError = OSError"). For the tutorial, I would choose an exception that does not disguise as another exception. -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: All right, you won. I hope beginner users will be happy :) I removed my proposal paragraph about __cause__ and __context__ and kept only changes about exception type (https://bugs.python.org/issue42179#msg380435). -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42085] Add dedicated slot for sending values
Change by Vladimir Matveev : -- pull_requests: +22267 pull_request: https://github.com/python/cpython/pull/23374 ___ Python tracker <https://bugs.python.org/issue42085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
Changes by Vladimir Rutsky : -- nosy: +rutsky ___ Python tracker <http://bugs.python.org/issue13857> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29326] Blank lines in ._pth file are not ignored
Change by Vladimir Chebotarev : -- pull_requests: +13537 pull_request: https://github.com/python/cpython/pull/7243 ___ Python tracker <https://bugs.python.org/issue29326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35306] OSError [WinError 123] when testing if pathlib.Path('*') (asterisks) exists
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +10365 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23057] [Windows] asyncio: support signal handlers on Windows (feature request)
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +10367 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue23057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31446] _winapi.CreateProcess (used by subprocess) is not thread-safe
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +10371 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31446> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14094] ntpath.realpath() should use GetFinalPathNameByHandle()
Vladimir Matveev added the comment: I can give it a try. -- nosy: +v2m ___ Python tracker <https://bugs.python.org/issue14094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14094] ntpath.realpath() should use GetFinalPathNameByHandle()
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +10488 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue14094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35568] Expose the C raise() function in the signal module, for use on Windows
Change by Vladimir Matveev : -- nosy: +v2m ___ Python tracker <https://bugs.python.org/issue35568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35568] Expose the C raise() function in the signal module, for use on Windows
Change by Vladimir Matveev : -- keywords: +patch pull_requests: +10606 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35568] Expose the C raise() function in the signal module, for use on Windows
Change by Vladimir Matveev : -- keywords: +patch, patch pull_requests: +10606, 10607 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35568] Expose the C raise() function in the signal module, for use on Windows
Change by Vladimir Matveev : -- keywords: +patch, patch, patch pull_requests: +10606, 10607, 10608 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35665] Function ssl.create_default_context raises exception on Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
New submission from Vladimir Perić : In Python 3.7.1 on Windows 10 ssl library function call ssl.create_default_context(ssl.Purpose.SERVER_AUTH) raises an ssl error: File "C:\Python37\lib\ssl.py", line 471, in _load_windows_store_certs self.load_verify_locations(cadata=certs) ssl.SSLError: nested asn1 error (_ssl.c:3926) In Python 3.6.4 same function call raises no error. -- assignee: christian.heimes components: SSL messages: 333054 nosy: christian.heimes, pervlad priority: normal severity: normal status: open title: Function ssl.create_default_context raises exception on Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35665] Function ssl.create_default_context raises exception on Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
Vladimir Perić added the comment: Same outcome in Python 3.7.2. See first comment for detailed explanation of issue. -- ___ Python tracker <https://bugs.python.org/issue35665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35665] Function ssl.create_default_context raises exception on Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
Vladimir Perić added the comment: Public Certificate file cert.pem is attached. Version of ssl lib in pythons on my machine: Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 1.1.0j 20 Nov 2018' Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 1.0.2q 20 Nov 2018' -- Added file: https://bugs.python.org/file48029/cacerts.pem ___ Python tracker <https://bugs.python.org/issue35665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35665] Function ssl.create_default_context raises exception on Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
Vladimir Perić added the comment: Thank you all for this expeditive help. Sorry for taking your time. I will remove bad certificates from my machine. Thanks again. I will try to close this one. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30586] Encode to EBCDIC doesn't take into account conversion table irregularities
New submission from Vladimir Filippov:
These 4 symbols were encoded incorrectly to EBCDIC (codec cp500): "![]|".
Correct table of conversation for these symbols described in
https://www.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg.im.iis.ds.parjob.adref.doc/topics/r_deeadvrf_Conversion_Table_Irregularities.html
This code:
ascii = '![]|';
print("ASCII: " + bytes(ascii, 'ascii').hex())
res = ascii.encode('cp500')
print ("EBCDIC: " +res.hex())
on Python 3.6.1 produce this output:
ASCII: 215b5d7c
EBCDIC: 4f4a5abb
Expected encoding (from IBM's table):
! - 5A
[ - AD
] - BD
| - 4F
Workaround: use this translation after encoding
bytes.maketrans(b'\x4F\x4A\x5A\xBB', b'\x5A\xAD\xBD\x4F')
--
components: Unicode
messages: 295329
nosy: Vladimir Filippov, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Encode to EBCDIC doesn't take into account conversion table
irregularities
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30586>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30586] Encode to EBCDIC doesn't take into account conversion table irregularities
Vladimir Filippov added the comment: According to ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/EBCDIC/CP037.TXT symbols [ and ] have other codes (instead of 0xAD and 0xBD): 0xBA0x005B #LEFT SQUARE BRACKET 0xBB0x005D #RIGHT SQUARE BRACKET Looks like ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/EBCDIC/CP500.TXT was created based on https://www.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg.im.iis.ds.parjob.adref.doc/topics/r_deeadvrf_ASCII_to_EBCDIC.html But this information "This translation is not bidirectional. Some EBCDIC characters cannot be translated to ASCII and some conversion irregularities exist in the table. For more information, see Conversion table irregularities." was ignored. Additional, this line from CP500.TXT: 0xBB0x007C #VERTICAL LINE haven't any source in IBM's table. Example from z/OS mainframe: --- bash-4.3$ iconv -f 819 -t 1047 -T ascii.txt > ebcdic.txt bash-4.3$ ls -T *.txt t ISO8859-1 T=on ascii.txt t IBM-1047T=on ebcdic.txt bash-4.3$ cat ascii.txt ![]|bash-4.3$ od -h ascii.txt 0021 5B 5D 7C 04 bash-4.3$ cat ebcdic.txt ![]|bash-4.3$ od -h ebcdic.txt 005A AD BD 4F 04 --- -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue30586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36407] xml.dom.minidom wrong indentation writing for CDATA section
New submission from Vladimir Surjaninov :
If we are writing xml with CDATA section and leaving non-empty indentation and
new-line parameters, a parent node of the section will contain useless
indentation, that will be parsed as a text.
Example:
>>>doc = minidom.Document()
>>>root = doc.createElement('root')
>>>doc.appendChild(root)
>>>node = doc.createElement('node')
>>>root.appendChild(node)
>>>data = doc.createCDATASection('')
>>>node.appendChild(data)
>>>print(doc.toprettyxml(indent=‘ ‘ * 4)
If we try to parse this output doc, we won’t get CDATA value correctly.
Following code returns a string that contains only indentation characters:
>>>doc = minidom.parseString(xml_text)
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue
Returns a string with CDATA value and indentation characters:
>>>doc.getElementsByTagName('node')[0].firstChild.wholeText
But we have a workaround:
>>>data.nodeType = data.TEXT_NODE
…
>>>print(doc.toprettyxml(indent=‘ ‘ * 4)
It will be parsed correctly:
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue
But I think it will be better if we fix the writing function, which would set
this as default behavior.
--
components: XML
messages: 338681
nosy: vsurjaninov
priority: normal
severity: normal
status: open
title: xml.dom.minidom wrong indentation writing for CDATA section
type: enhancement
___
Python tracker
<https://bugs.python.org/issue36407>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36407] xml.dom.minidom wrong indentation writing for CDATA section
Change by Vladimir Surjaninov : -- keywords: +patch pull_requests: +12465 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27456] asyncio: set TCP_NODELAY flag by default
Vladimir Magamedov added the comment: Seems like this fix is incomplete. It contains this check: sock.type == socket.SOCK_STREAM But sock.type is not only a type (at least in Linux and FreeBSD), it also may contain SOCK_NONBLOCK and SOCK_CLOEXEC flags. So I'm hitting the same problem: on the Linux in asyncio I have: > sock.type == socket.SOCK_STREAM | socket.SOCK_NONBLOCK == 2049 True So this check isn't working and TCP_NODELAY still disabled by default. Links: - http://man7.org/linux/man-pages/man2/socket.2.html - https://github.com/torvalds/linux/blob/v4.13/include/linux/net.h#L77 - https://github.com/freebsd/freebsd/blob/stable/11/sys/sys/socket.h#L110 Linux has SOCK_TYPE_MASK definition equal to 0xf, but I can't find such definition in the FreeBSD sources. And I don't know how to reliably and with forward compatibility check sock.type without calling getsockopt() syscall. Currently I have a fix in my project, where: _sock_type_mask = 0xf if hasattr(socket, 'SOCK_NONBLOCK') else 0x And then in my own _set_nodelay(sock) function: sock.type & _sock_type_mask == socket.SOCK_STREAM Should I make a pull request or someone knows more reliable check? Or it is ok to add one more syscall? sock.getsockopt(socket.SOL_SOCKET, socket.SO_TYPE) == socket.SOCK_STREAM -- nosy: +vmagamedov ___ Python tracker <https://bugs.python.org/issue27456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26340] modal dialog with transient method; parent window fails to iconify
Vladimir Semenenko added the comment: After they marked the issue as "resolved" earlier this year I tested a subsequent 3.x release in Windows 7 and Vista (I don't have 10). The issue was still there. I don't have a workaround. I am forced to stay with 2.7.3. On Dec 8, 2017 9:32 AM, "jarb" wrote: jarb added the comment: I am having the exactly same issue. Was this issue resolved for Windows 10? This does not happen in Linux. Any workaround for Windows 10? -- nosy: +jarb ___ Python tracker <https://bugs.python.org/issue26340> ___ -- nosy: +Vladimir Semenenko ___ Python tracker <https://bugs.python.org/issue26340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29326] Blank lines in ._pth file are not ignored
Vladimir Chebotarev added the comment: Hi. I guess this issue has to be reopen because Alexey erroneously broke adding empty paths to `sys.path` along with his patch. Official embeddable Pythons do contain a blank line in its ._pth, and this allowed users to import modules from script directory. Kind regards, Vladimir. -- nosy: +excitoon ___ Python tracker <https://bugs.python.org/issue29326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
