[issue46256] Objects __del__ called after module have been removed

Daniele Varrazzo added the comment: Thank you @pablogsal. For me it was surprising as never seen before 3.10 instance. If this is the expected behaviour (and the stdlib expects it) we can try and take the same type of care in psycopg

[issue46256] Objects __del__ called after module have been removed

New submission from Daniele Varrazzo : The following bug has been reported to Psycopg: https://github.com/psycopg/psycopg/issues/198 At the end of the program, errors such as the following are dumped: Exception ignored in: Traceback (most recent call last): File "

[issue43112] SOABI on Linux does not distinguish between GNU libc and musl libc

Change by Daniele Varrazzo : -- nosy: +piro ___ Python tracker <https://bugs.python.org/issue43112> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45347] datetime subject to rounding?

Daniele Varrazzo added the comment: Considering that I have found another pair of dates failing equality, and they are too on the last Sunday of October, the hypothesis of rounding in timezone code starts to look likely Python 3.7.9 (default, Jan 12 2021, 17:26:22) [GCC 8.3.0] on linux

[issue45347] datetime subject to rounding?

New submission from Daniele Varrazzo : I found two datetimes at difference timezone whose difference is 0 but which don't compare equal. Python 3.9.5 (default, May 12 2021, 15:26:36) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "l

[issue41324] Add a minimal decimal capsule API

Daniele Varrazzo added the comment: Ah, just noticed that this has been now reverted. Oh well, I'll see what to do then :( -- ___ Python tracker <https://bugs.python.org/is

[issue41324] Add a minimal decimal capsule API

Daniele Varrazzo added the comment: FYI, will try to use this API in psycopg3, which supports the PostgreSQL decimal binary format. Thank you very much: it seems exactly what needed. Binary conversion with Python Decimal currently has disappointing performances and is slower than the text

[issue42600] Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError: Lock is not acquired.

Daniele Varrazzo added the comment: I have stumbled in this bug, or something similar, implementing psycopg3 async connection pool. A function such as the following fails but only in Python 3.6 (tested 3.6.12): async def wait(self, timeout: float) -> AsyncConnection: "&q

[issue40910] Py_GetArgcArgv() is no longer exported by the C API

Daniele Varrazzo added the comment: Thank you for opening this. FYI: > probably the original argv can still be found scanning backwards from environ this is how the module works indeed in Python 3. -- nosy: +piro ___ Python tracker <

[issue15577] Real argc and argv in embedded interpreter

Daniele Varrazzo added the comment: Py_GetArgcArgv gone broke setproctitle indeed. https://github.com/dvarrazzo/py-setproctitle/issues/76 Is there a way to get the same feature in 3.9 or should setproctitle become no-op from 3.9 on and Python loses this feature? Thank you. -- nosy

[issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes

Daniele Varrazzo added the comment: No, I cannot. I take the fact there has been no answer for more than 18 months as an acknowledgement that the issue is not deemed important by Python maintainers: it's not important for me either. I'm not a heavy xml user: just knowing that the

[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values

Daniele Varrazzo added the comment: Added separate issue #17582 as ElementTree implementation doesn't depend on whatever causes the bug in xml.dom.minidom. -- ___ Python tracker <http://bugs.python.org/i

[issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes

New submission from Daniele Varrazzo: XML defines the following chars as whitespace [1]:: S ::= (#x20 | #x9 | #xD | #xA)+ However the chars are not properly escaped into attributes, so they are converted into spaces as per attribute-value normalization [2] >>> data = 

[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values

Daniele Varrazzo added the comment: I was going to open an issue on itself about etree and tabs, but I've found this and thought it would have been marked as duplicate. If you don't think it's the case I will open it anyway. I've added my comment because ElementTree is

[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values

Daniele Varrazzo added the comment: ElementTree issue is with tabs: In [1]: import xml.etree.cElementTree as etree In [2]: doc = etree.fromstring('') In [4]: doc.set('attr', "here\tthere") In [5]: etree.tostring(doc) Out[5]: ''

[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values

Daniele Varrazzo added the comment: Just got bitten by this bug, which affects xml.etree.ElementTree and cElementTree too. Any chance to have it fixed? Note that lxml.etree is not affected by the bug and can be used as a replacement for the stdlib module if you happen to have some work to do

[issue16420] PEP 249 (DB-API 2.0) converted to reStructuredText

Daniele Varrazzo added the comment: Andrew, I've probably changed every single line (as almost all the original was indented), so diff wouldn't show anything useful. -- ___ Python tracker <http://bugs.python.o

[issue16420] PEP 249 (DB-API 2.0) converted to reStructuredText

New submission from Daniele Varrazzo: I've converted the DBAPI to reST, mostly to allow linking from external documentation. It would be great to replace the current text only version with it. File attached. -- assignee: docs@python components: Documentation files: pep-024

[issue16204] PyBuffer_FillInfo returns 'B' buffer, whose behavior has changed w.r.t. 3.1/3.2

New submission from Daniele Varrazzo: Definitely related to this change in Python 3.3: Accessing a memoryview element with format ‘B’ (unsigned bytes) now returns an integer (in accordance with the struct module syntax). For returning a bytes object the view must be cast to ‘c

[issue11195] next fixer fooled by trailing cheracters

New submission from Daniele Varrazzo : An expression such as "x = i.next()[0]" is not fixed by 2to3 in Python 3.1. "x = (i.next())[0]" works instead. https://github.com/dvarrazzo/psycopg/commit/9e9c22163706b0fffb9da67fe50ea23f91fe1c72 -- components: 2to3 (2.x to

[issue9167] argv double encoding on OSX

Daniele Varrazzo added the comment: Ronald, Thank you for the interest. For me trying to deal with such a tricky issue on a system whose Best Before date is already passed would be a waste of time. I was only interested in factor out the bugs in my extension module from the ones not under

[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)

Changes by Daniele Varrazzo : -- nosy: +piro ___ Python tracker <http://bugs.python.org/issue8775> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4388] test_cmd_line fails on MacOS X

Changes by Daniele Varrazzo : -- nosy: +piro ___ Python tracker <http://bugs.python.org/issue4388> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9167] argv double encoding on OSX

Daniele Varrazzo added the comment: I've made some other test with LANG=C on other platforms. It seems resulting in a clean error on Linux: $ LANG=C ./here/bin/python3 Python 3.2a0 (py3k, Jul 6 2010, 12:40:29) [GCC 4.3.2] on linux2 Type "help", "copyright", "

[issue9167] argv double encoding on OSX

Daniele Varrazzo added the comment: Attached patch with test cases to check sys.argv and sys.executable. The tests fail against the daily snapshot, so adding python 3.2 to the affected versions. Variable __CF_USER_TEXT_ENCODING is undefined. Locale of the system is C: $ locale LANG

[issue9167] argv double encoding on OSX

New submission from Daniele Varrazzo : Looks like the wchar_t* array returned by Py_GetArgcArgv() on OSX suffers by double encoding. This can affect sys.argv, sys.executable and C code relying on the above function of course. On Linux: $ python3 Python 3.0rc1+ (py3k, Oct 28 2008, 09:22:29

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: Hello everybody, I've finished porting the module to Python 3, so I think it's a good starting point for considering its inclusion into the stdlib. The source is already out; tomorrow I'll test for regressions on mac osx and release the pa

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: > No. It will also be required that it's authors agree to contribute it to > Python, agree to stop maintaining the out-of-Python version > (eventually), and agree to fill out a contributor form. I would have no problem with these points if

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: setproctitle is quite stable, my company uses it in production environment very heavily with python 2.x. Probably its users base is not huge, but that's because it's a relatively specialized tool. Python3 porting is not straightforward becau

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: >> I've just tested it and it works fine here... Any possibility this >> module can be included in the regular python standard library, in the >> future? >Only in the far future. I don't think the Python standard library

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: > It seems that some utilities and programs (killall, > gnome-system-monitor, and so on) looks for the process name in > /proc/PID/status, not in /proc/PID/cmdline, so it should be better > (in Linux), to modify both, /proc/PID/cmdline (changin

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: > I'm taking a look at it, and it seems to use setproctitle() in BSD, and > writes over the argv array "in most Sys-V like systems"; this includes > Linux? Yes: Linux uses what in the source is referred as the PS_USE_CLOBBER_

[issue5672] Implement a way to change the python process name

Daniele Varrazzo added the comment: I wrote a wrapper around the PostgreSQL implementation of setproctitle (probably the most portable around). I've only tested it on Linux: probably will require tweaking constants to compile on other platforms (something postgres does at configure time

[issue2113] Bad interaction between signal and subprocess

Daniele Varrazzo added the comment: Just noticed that in the patch "except select.error:" suffices instead of "except:"... __ Tracker <[EMAIL PROTECTED]> <htt

[issue2113] Bad interaction between signal and subprocess

Changes by Daniele Varrazzo: -- components: +Library (Lib) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2113> __ ___ Python-bugs-list mailing list

[issue2113] Bad interaction between signal and subprocess

Changes by Daniele Varrazzo: Added file: http://bugs.python.org/file9432/subprocess_signal_bug.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2113> __ ___

[issue2113] Bad interaction between signal and subprocess

New submission from Daniele Varrazzo: During Popen.communicate(), if a signal is caught during the select(), an unhandled exception is raised, and the output gathered is lost. This means that a long running or hanged process can't be killed after a timeout (as shown in the attached ex

[issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out

Daniele Varrazzo added the comment: Because the easy workaround, we can live with the issue. Anyway, because the workaround is not trivial to find, and because the behavior is supposed to remain unchanged, maybe the issue should be mentioned in the docs. Thank you for the explanation

[issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out

New submission from Daniele Varrazzo: This issue probably depends on #1167930 When waiting on a queue in blocking mode, in no timeout is set, ctrl-C doesn't raise KeyboardInterrupt:: q = Queue() q.get(True) # ctrl-c doesn't work here If any timeout is set, ctrl-c works a

[issue1169] Option -OO doesn't remove docstrings from functions

Daniele Varrazzo added the comment: The attached file shows the issue: running with -OO no docstring should be printed. In rev 58163 the functions docstrings are still printed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1169] Option -OO doesn't remove docstrings from functions

New submission from Daniele Varrazzo: The issue was already addressed in Issue1722485. The fix applied in rev. 55732, 55733 only fixes module and class docstrings, not function docstrings. The attached patch fixed the issue for function docstrings too. -- components: None files