[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. -- ___ Python tracker <https://bugs.python.org/issue46256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "/opt/homebrew/lib/python3.10/site-packages/psycopg/pq/pq_ctypes.py", line 91, in __del__ TypeError: 'NoneType' object is not callable Where `None` is some module-level objects, such as `os.getpid`. Unfortunately I don't have a full repro. The error seems only happening in Python 3.10. -- components: Interpreter Core messages: 409684 nosy: piro priority: normal severity: normal status: open title: Objects __del__ called after module have been removed versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 >>> import datetime, backports.zoneinfo >>> d1 = datetime.datetime(2255, 10, 28, 7, 31, 21, 393428, >>> tzinfo=datetime.timezone(datetime.timedelta(seconds=27060))) >>> d2 = datetime.datetime(2255, 10, 28, 2, 0, 21, 393428, >>> tzinfo=backports.zoneinfo.ZoneInfo(key='Europe/Rome')) >>> d1 - d2 datetime.timedelta(0) >>> d1 == d2 False Added Python 3.7 to the affected list. -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue45347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "license" for more information. >>> import datetime as dt >>> from zoneinfo import ZoneInfo >>> for i in range(3): ... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc) ... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) == ref.astimezone(dt.timezone(dt.timedelta(seconds=3600 ... True False True >>> for i in range(3): ... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc) ... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - ref.astimezone(dt.timezone(dt.timedelta(seconds=3600 ... 0:00:00 0:00:00 0:00:00 Is this a float rounding problem? If so I think it should be documented that datetimes bewhave like floats instead of like Decimal, although they have finite precision. -- components: Library (Lib) messages: 403059 nosy: piro priority: normal severity: normal status: open title: datetime subject to rounding? versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 format conversion. This is likely caused by the use of Decimal.as_tuple(), which creates tuples for the return value and the digits and requires Python calls to access their values. I have considered using libmpdec directly: personally I wouldn't be opposed to that, but the additional dependency on libmpdec-dev would earn the project no new fan :\ Ref. https://github.com/psycopg/psycopg3/issues/54 -- ___ Python tracker <https://bugs.python.org/issue41324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:
"""Wait for a connection to be set and return it.
Raise an exception if the wait times out or if fail() is called.
"""
async with self._cond:
if not (self.conn or self.error):
try:
await asyncio.wait_for(self._cond.wait(), timeout)
except asyncio.TimeoutError:
# HERE
self.error = PoolTimeout(
f"couldn't get a connection after {timeout} sec"
)
In python 3.6, printing self._cond.locked() in the HERE position gives False,
even if it's inside the with block. Everything grinds to a halt afterwards.
However I don't have the same problem in other Python versions (3.7.10, 3.8.5
among the ones tested) so I'm not sure it is the same issue.
Is this a manifestation of the same bug or a different one? Is there any
workaround or should I make the async pool just not supported on Python 3.6?
--
nosy: +piro
___
Python tracker
<https://bugs.python.org/issue42600>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <https://bugs.python.org/issue40910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +piro versions: +Python 3.9 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue15577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Python XML libraries are unreliable and that by default I should use lxml is a sufficient solution to my sporadic xml uses. Your mileage should vary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 = '\x09\x0a\x0d\x20'
data
'\t\n\r '
import xml.etree.ElementTree as ET
e = ET.Element('x', attr=data)
s = ET.tostring(e)
s
'x attr=\t#10;\r /'
e1 = ET.fromstring(s)
data1 = e1.attrib['attr']
data1 == data
False
data1
' \n '
cElementTree suffers of the same bug::
import xml.etree.cElementTree as cET
cET.fromstring(cET.tostring(cET.Element('a', attr=data))).attrib['attr']
' \n '
but not the external library lxml.etree::
import lxml.etree as LET
LET.fromstring(LET.tostring(LET.Element('a', attr=data))).attrib['attr']
'\t\n\r '
The bug is analogous to #5752 but it refers to a different and independent
module. Proper escaping should be added to the _escape_attrib() function into
/xml/etree/ElementTree.py (and equivalent for cElementTree).
[1] http://www.w3.org/TR/REC-xml/#white
[2] http://www.w3.org/TR/REC-xml/#AVNormalize
--
components: Library (Lib), XML
messages: 185574
nosy: piro
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree does not preserve whitespaces in attributes
versions: Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17582
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue5752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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('xml /')
In [4]: doc.set('attr', here\tthere)
In [5]: etree.tostring(doc)
Out[5]: 'xml attr=here\tthere /'
In [6]: etree.fromstring(_5).attrib['attr']
Out[6]: 'here there'
bye bye tab.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5752
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 not reported in this page at all: I've been googling forever about ElementTree tabs attributes without result. I've found this (and the network of duplicates) only searching for less generic xml tabs into the python bug tracker, when I was already filing the bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-0249.txt messages: 174965 nosy: docs@python, lemburg, piro priority: normal severity: normal status: open title: PEP 249 (DB-API 2.0) converted to reStructuredText type: enhancement Added file: http://bugs.python.org/file27908/pep-0249.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16420 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue16420 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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’ first. The object returned by PyBuffer_FillInfo is 'B' format: this means that python code finds itself dealing in Py 3.3 with a different object respect to what returned in Py 3.1 and 3.2. Is this change in the behavior wanted? Wouldn't have been better having FillInfo return a 'c' buffer instead? I'm adding support to Py 3.3 to psycopg2 and the B buffers make the test suite fail. I want psycopg to return consistent objects across 3.x. Is the change in this commit correct? https://github.com/dvarrazzo/psycopg/commit/469b6f8aff4cafe203d851b19bedfab0128e795a Is this a good way to return a 'c' buffer? -- messages: 172710 nosy: piro priority: normal severity: normal status: open title: PyBuffer_FillInfo returns 'B' buffer, whose behavior has changed w.r.t. 3.1/3.2 type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11195] next fixer fooled by trailing cheracters
New submission from Daniele Varrazzo p...@develer.com: 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 3.0 conversion tool) messages: 128412 nosy: piro priority: normal severity: normal status: open title: next fixer fooled by trailing cheracters versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Daniele Varrazzo p...@develer.com 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 my responsibility and I had the bad luck to find a 10.4 to test on. I don't have a direct interest in this bug to be fixed. Thank you very much again for your time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Daniele Varrazzo p...@develer.com 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= LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= -- keywords: +patch versions: +Python 3.2 Added file: http://bugs.python.org/file17881/test-argv.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Daniele Varrazzo p...@develer.com 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, credits or license for more information. import sys, os snowman = '\u2603' os.system((sys.executable + -c 'import sys; print(sys.argv[-1].encode(\utf8\))' + snowman).encode(sys.getdefaultencoding())) Traceback (most recent call last): File string, line 1, in module UnicodeEncodeError: 'utf-8' codec can't encode character '\udce2' in position 0: surrogates not allowed 256 Notice that I had to use an explicit encoding or os.system would have tried to encode using ascii and barf, probably because of bug #8775. I've also been reported about issue #4388: I've checked and test_run_code() fails as described. So I think this bug can be considered a #4388 duplicate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
Changes by Daniele Varrazzo p...@develer.com: -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)
Changes by Daniele Varrazzo p...@develer.com: -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
New submission from Daniele Varrazzo p...@develer.com: 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) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. import os, sys snowman = '\u2603' os.system(sys.executable + -c 'import sys; [print(a.encode(\utf8\)) for a in sys.argv]' foo bar + snowman) b'-c' b'foo' b'bar' b'\xe2\x98\x83' 0 On OSX (uname -a is Darwin comicbookguy.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386) $ python3 Python 3.1.2 (r312:79147, Jul 5 2010, 11:57:14) [GCC 4.2.1 (Apple Inc. build 5659)] on darwin Type help, copyright, credits or license for more information. import os, sys snowman = '\u2603' os.system(sys.executable + -c 'import sys; [print(a.encode(\utf8\)) for a in sys.argv]' foo bar + snowman) b'-c' b'foo' b'bar' b'\xc3\xa2\xc2\x98\xc2\x83' 0 Is this a known limitation of the platform? I don't know much about OSX, just found it testing for regressions in setproctitle http://code.google.com/p/py-setproctitle/ Reported correctly working on Windows. -- components: Interpreter Core messages: 109333 nosy: piro priority: normal severity: normal status: open title: argv double encoding on OSX type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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 package. I'm not going to champion a PEP for its inclusion though, as I'm not the right person to do what described in the pep approval process. I have no objection if somebody wanted to push for it anyway and to fulfill the requirements outlined by Martin. Marcelo, I think it's up to you :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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 because python2 exports the original argv pointer using Py_GetArgcArgv() whereas python3 only exports a decoded version in a wchar_t* array. This may not be a showstopper: probably the original argv can still be found scanning backwards from environ: I want to test it but I haven't had requests for it yet, so it wasn't a top priority. So, while I'd be pleased to have it included in the stdlib, I'm not really convinced it would be useful to such a large audience. Anyway I'm available for any improvement it would make the tool more useful and to anybody eager to push for its inclusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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 the module is considered worthy for stdlib inclusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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 should include a module whose version number is 0.2. I agree: I started the project 4-5 days ago and, albeit very limited in its scope, for portability reasons is way more complex than a simple syscall and needs to be tested on many other platforms. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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_ARGV strategy: it writes over the area pointed by argv and by environ (after checked they are contiguous and moved away). Sounds scary, but I've tested that environ keeps working fine (the environ can be modified and forked processes receive the correct environment). My question is because I think there's a better and supported method for Linux, that is, using prctl [1]. I read somewhere that changing argv causes some inconsistencies between programs who read /sys files, /proc files... or I don't remember what, but it is, in fact, not the *recommended* way. Prctl is. :-) This is interesting: do you have any reference? I've tested with the difference between clobbering argv and call prctl: two demo programs are in the tools directory of the module project [2]. For what I observed, clobbering argv changes what shown in ``/proc/PID/cmdline``, whereas prctl changes what can be read in ``/proc/PID/status`` (and ``stat`` too). ``ps`` uses the former, but switches to the latter when calling ``ps a`` and ``ps f``. ``top`` toggles between the two pressing ``c``. I don't know which method is better (well, I happen to prefer the extended visualization provided by the cmdline, which natively shows more detail than just the process name shown in ``status`` but this is probably subjective). Could this module be altered to use a prctl call in Linux (2.6.9)? I think is probably better to have both strings updated: I'd prefer this behavior instead of the title being set in different places on different Linux versions. [2] http://code.google.com/p/py-setproctitle/source/browse/tools/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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 (changing argv) *and* /proc/PID/status (calling prctl()). I installed py-setproctitle, and can't kill it with killall once I set the name to hello, for example. :-( Just released setproctitle 0.2 where I also call prctl() if available. It is actually the string used by killall. For what I observed, clobbering argv changes what shown in ``/proc/PID/cmdline``, whereas prctl changes what can be read in ``/proc/PID/status`` (and ``stat`` too). ``ps`` uses the former, but switches to the latter when calling ``ps a`` and ``ps f``. ``top`` toggles between the two pressing ``c``. Sorry, but here (Ubuntu 9.10) it works the other way around: ps lists the /proc/PID/status - name field and ps a lists the /proc/PID/cmdline. But I got the explanation. :-) Yup, sorry: it was the other way round :P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com 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) but the core functionality is surely well tested. I've put the module on http://code.google.com/p/py-setproctitle/ : testing (yes, there is an unit test) and tweaking setup on other platforms is welcome. -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 example, where the output collected before the signal is valuable) The bug happens only when stdout and stderr are not merged and is tested on linux platform. -- files: subprocess_signal_bug.py messages: 62392 nosy: piro severity: normal status: open title: Bad interaction between signal and subprocess type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9431/subprocess_signal_bug.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2113 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2113 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 as expected:: q = Queue() ONEYEAR = 365 * 24 * 60 * 60 q.get(True, ONEYEAR) # ctrl-c works here Traceback (most recent call last): File queuebug.py, line 6, in module q.get(True, ONEYEAR) File /usr/lib/python2.5/Queue.py, line 174, in get self.not_empty.wait(remaining) File /usr/lib/python2.5/threading.py, line 233, in wait _sleep(delay) KeyboardInterrupt -- components: Library (Lib) messages: 56942 nosy: piro severity: normal status: open title: Queue.get() can't be interrupted with Ctrl-C unless timed out type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1360 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1360 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: fix_function_docstring.patch
messages: 55945
nosy: piro
severity: normal
status: open
title: Option -OO doesn't remove docstrings from functions
type: compile error
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1169
__--- compile.c.bak 2007-09-16 17:23:43.0 +0200
+++ compile.c 2007-09-16 17:26:38.0 +0200
@@ -1336,7 +1336,7 @@
st = (stmt_ty)asdl_seq_GET(s-v.FunctionDef.body, 0);
docstring = compiler_isdocstring(st);
- if (docstring)
+ if (docstring Py_OptimizeFlag 2)
first_const = st-v.Expr.value-v.Str.s;
if (compiler_add_o(c, c-u-u_consts, first_const) 0) {
compiler_exit_scope(c);
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __Module docstring class Test: Class docstring def test(self): Method docstring. pass def fun(): Function docstring. pass print 'module', __doc__ print 'class', Test.__doc__ print 'method', Test.test.__doc__ print 'fun', fun.__doc__ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
