[issue13427] string comparison with ==
Alan added the comment:
Using repr highlights the issue which lies in the behaviour of str.strip()
which does not strip away null spaces as I would have expected:
' 'utm10\x00' ' == ' 'utm10' '
not equal
Changing the code to:
currColl=line.split(":")[1].strip().strip("\0")
works but I think strip() should already do that by default, shouldn't it?
--
___
Python tracker
<http://bugs.python.org/issue13427>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28708] Low FD_SETSIZE limit on Windows
Alan added the comment: The big innovation with poll() is that it takes an array of descriptors like a normal function. https://www.geometrydash.me/ -- nosy: +alanpreston ___ Python tracker <https://bugs.python.org/issue28708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34991] variable type list [] referential integrity data loss
New submission from Alan : Dear PythonDev, Thank you for your tremendous work in building a simpler programming language for all. As an avid user of lists, I am upset that my list cannot preserve its referential integrity in the attached pythonissue.txt file. In the following, (EXPECTED) includes my expected checkvisit data values, and the following two (OUTPUT)s include the actual checkvisit data structures when called. Perhaps this is not an issue in Python 3.8., but this is a matter in Python 3.6. Sincerely, Alan Jerry Pan, CPA alan@sjtu.edu.cn alt. alan@alumni.iu.edu (EXPECTED) Checkvisit (for every isGoal iteration): [[5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] [[5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0], [5, 3, 4, 2, 1, 0]] (OUTPUT) Checkvisit print result inside def(visitedPath): [] [] [] [] [] [[5]] [[5, 3]] [[5, 3, 4]] [[5, 3, 4, 2]] [[5, 3, 4, 2, 1]] [[5], [5]] [[5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5]] [[5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5], [5]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5], [5], [5]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5], [5], [5], [5]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] (OUTPUT)Checkvisit print result in while 0 loop [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [[5]] [[5]] [[5]] [[5]] [[5]] [[5, 3]] [[5, 3]] [[5, 3]] [[5, 3]] [[5, 3]] [[5, 3]] [[5, 3, 4]] [[5, 3, 4]] [[5, 3, 4]] [[5, 3, 4]] [[5, 3, 4, 2]] [[5, 3, 4, 2]] [[5, 3, 4, 2, 1]] [[5], [5]] [[5], [5]] [[5], [5]] [[5], [5]] [[5], [5]] [[5, 3], [5, 3]] [[5, 3], [5, 3]] [[5, 3], [5, 3]] [[5, 3], [5, 3]] [[5, 3], [5, 3]] [[5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5]] [[5], [5], [5]] [[5], [5], [5]] [[5], [5], [5]] [[5], [5], [5]] [[5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5], [5]] [[5], [5], [5], [5]] [[5], [5], [5], [5]] [[5], [5], [5], [5]] [[5], [5], [5], [5]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1], [5, 3, 4, 2, 1]] [[5], [5], [5], [5], [5]] [[5], [5], [5], [5], [5]] [[5], [5], [5], [5], [5]] [[5], [5], [5], [5], [5]] [[5], [5], [5], [5], [5]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3], [5, 3], [5, 3], [5, 3], [5, 3]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4], [5, 3, 4]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2]] [[5, 3, 4, 2], [5, 3, 4, 2], [5, 3, 4, 2], [5
[issue34991] variable type list [] referential integrity data loss
Alan added the comment:
Thank you for your feedback steven.daprano and eric.smith. My first experience
with a computer was 22 years ago and started as a computer science student 13
years ago. I began in the Visual Basic programming community in 2008, so I
apologize as I am new to the Python community.
To summarize, the variable list[] should equal to A, but as the code runs
through loops the list[] is mutable (perhaps too literally) into A', A'', A''',
etc.
There is no immediate solution to this issue, but an alternative to this issue
would be to use variable type dictionary {}.
A more permanent resolution would probably require a conference presentation
and/or publication.
Thanks again.
--
___
Python tracker
<https://bugs.python.org/issue34991>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22990] bdist installation dialog
New submission from Alan: The "Select Python Installations" dialog box contains the line "Select the Python locations where should be installed." If is anything other than a very short string, the line is truncated, due to the following factors: - the line doesn't wrap - the dialog box can't be resized - the message (aside from the distribution name) is fairly lengthy See the screenshot, where I created a distribution of a package whose name is "not_such_a_long_name". At the same time as the line is made wrappable and/or the dialog box is made resizable, it would be nice to improve the wording of the message. It took me a while to figure out what was going on because the GUI elements have different meanings from the ones seen more commonly. Usually these elements (the menu with choices beginning with "Will be installed on local hard drive" and ending with "Entire feature will be unavailable") are used to choose one or more features of an application to install, not one or more places to install the same application. Maybe something like this would work: Select Where to Install Select Python locations in which to install : Python 2.7 (found in the registry) Python 3.3 (found in the registry) Python (other location) instead of the current: Select Python Installations Select the Python locations where should be installed: Python 2.7 from registry Python 3.3 from registry Python from another location -- components: Distutils files: bdist_screenshot.PNG messages: 232094 nosy: Alan, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist installation dialog type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file37353/bdist_screenshot.PNG ___ Python tracker <http://bugs.python.org/issue22990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25037] ValueError: invalid literal for int() with base 16: b'[\r\n'
New submission from Alan:
I've written a piece of code to POST request to a web service.
===
import json
import urllib
from urllib import request
from urllib import parse
def Payload(start_date, end_date, pnode_list):
payload = {"startDate": start_date,
"endDate": end_date,
"pnodelist": pnode_list}
return json.dumps(payload)
def DownloadData(url, payload, header):
data = []
request = urllib.request.Request(url, payload, header)
try:
response = urllib.request.urlopen(request)
except urllib.error.URLError as e:
print("URLError occured.")
except urllib.error.HTTPError as e:
print("HTTPError occured.")
else:
#response.chunked = False #if this line is commented, ValueError
will be thrown...
data = json.loads(response.read().decode("utf-8"))
return data
def main():
url =
"https://dataminer.pjm.com/dataminer/rest/public/api/markets/dayahead/lmp/daily";
payload = Payload("2015-07-01", "2015-07-01", [135389795])
header = {"Content-Type": "application/json"}
data = DownloadData(url, payload.encode("utf-8"), header)
print(data)
if __name__ == "__main__":
main()
===
However, "ValueError:invalid literal for int() with base 16: b'[\r\n'" is
thrown when the HTTPResponse.read() is invoked:
Traceback (most recent call last):
File "C:\Python34\lib\http\client.py", line 587, in _readall_chunked
chunk_left = self._read_next_chunk_size()
File "C:\Python34\lib\http\client.py", line 559, in _read_next_chunk_si
return int(line, 16)
ValueError: invalid literal for int() with base 16: b'[\r\n'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "textpjm.py", line 34, in
main()
File "textpjm.py", line 30, in main
data = DownloadData(url, payload.encode("utf-8"), header)
File "textpjm.py", line 23, in DownloadData
data = json.loads(response.read().decode("utf-8"))
File "C:\Python34\lib\http\client.py", line 506, in read
return self._readall_chunked()
File "C:\Python34\lib\http\client.py", line 591, in _readall_chunked
raise IncompleteRead(b''.join(value))
http.client.IncompleteRead: IncompleteRead(0 bytes read)
I've found a solution to avoid this exception: before HTTPResponse.read() is
called, I have to set HTTPResponse.chunked to be False!
I wonder if there's something wrong in HTTPResponse.
--
components: Library (Lib)
files: testpjm.py
messages: 250275
nosy: alan
priority: normal
severity: normal
status: open
title: ValueError: invalid literal for int() with base 16: b'[\r\n'
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file40416/testpjm.py
___
Python tracker
<http://bugs.python.org/issue25037>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28159] Deprecate isdst argument in email.utils.localtime
Alan WiIliams added the comment: Hi, I'd like to work on this issue. Based on the discussion, the main thing to do here is to raise a deprecation warning when isdst is used? -- nosy: +Alan.Williams ___ Python tracker <https://bugs.python.org/issue28159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1134] Parsing a simple script eats all of your memory
Alan McIntyre added the comment: Confirmed that this happens on Mac OS X with a fresh build of py3k from svn. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1134> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1201] Error in array concept
Alan McIntyre added the comment: The last character is n-1, but the section you quote says the *right edge* of the last character (not the last character itself) has index n; this seems correct in the context of the mnemonic scheme. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1201> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1381] cmath is numerically unsound
Alan McIntyre added the comment: I have to review a few complex math topics for some of my current course work, so I wouldn't mind taking a look into this. I can't promise I'll have the time required to make all of cmath correct (assuming it's as unsound as claimed), but I'll do what I can. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1381> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Changes by Alan Hourihane : -- resolution: accepted -> remind ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
Alan McIntyre added the comment: I also can't see any file operations that might occur between the two .tell() calls, and a full test pass (including test_zipfile64) on the py3k development branch doesn't turn up any problems on Linux (2.6.38, x86_64) for me, so I agree the second .tell() could be removed. -- ___ Python tracker <http://bugs.python.org/issue11981> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Alan McIntyre added the comment: I re-checked testzip-patch3.diff since some time has passed since I last commented on it, and it still seems to work ok (the small test_zipfile.py block failed to apply, but that's easy enough to do manually). Passes full test run, test_zipfile64.py, etc., on Linux x86_64. If there is something about the patch that still needs to be addressed before it can be committed, let me know and I'll see what I can do. -- ___ Python tracker <http://bugs.python.org/issue1739648> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
Alan McIntyre added the comment: So far I haven't had the opportunity to sit down and write up a "lenient zipfile handling" patch; my apologies to those that could really use one. If somebody does propose a patch, I'll be glad to test and review it. I suppose I would like to see the issue kept open for a while, even if just to collect common "bending of the rules" cases that people would like to see supported. -- ___ Python tracker <http://bugs.python.org/issue1757072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13346] re.split() should behave like string.split() for maxsplit=0 and maxsplit=-1
New submission from Alan Grow :
If you split a string in a maximum of zero places, you should get the original
string back. "".split(s,0) behaves this way. But re.split(r,s,0) performs an
unlimited number of splits in this case.
To get an unlimited number of splits, "".split(s,-1) is a sensible choice. But
in this case re.split(r,s,-1) performs zero splits.
Where's the sense in this?
>>> import string, re
>>> string.split("foo bar baz"," ",0)
['foo bar baz']
>>> re.split("\s+","foo bar baz",0)
['foo', 'bar', 'baz']
>>> string.split("foo bar baz"," ",-1)
['foo', 'bar', 'baz']
>>> re.split("\s+","foo bar baz",-1)
['foo bar baz']
--
components: Library (Lib)
messages: 147066
nosy: acg
priority: normal
severity: normal
status: open
title: re.split() should behave like string.split() for maxsplit=0 and
maxsplit=-1
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue13346>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13427] string comparison with ==
New submission from Alan Beccati :
Hello,
did I discover a python string comparison bug or is this behaviour expected and
I am doing something wrong?
This is the code I run:
for line in lines[4:]:
currColl=line.split(":")[1].strip()
print "'",currColl,"'","==","'",collName,"'"
if currColl == collName :
return True
else:
print "not equal"
where currColl is a method parameter and lines is built from subprocess Popen
like:
p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
lines=[]
for line in p.stdout.readlines():
lines.append(line)
The output of the abovementioned code is:
' utm ' == ' utm10 '
not equal
' utm1000 ' == ' utm10 '
not equal
' utm100 ' == ' utm10 '
not equal
' utm10 ' == ' utm10 '
not equal
' utm1 ' == ' utm10 '
not equal
as you can see the fourth comparison should return True while it gives a "not
equal" as the others.
Python info:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2] on linux2
--
messages: 147854
nosy: Alan.Beccati
priority: normal
severity: normal
status: open
title: string comparison with ==
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13427>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: Hi Antoine, Unfortunately the #undef is too early and later #includes redefine it. We should move the #undef closer to the code that actually uses them. -- resolution: fixed -> accepted status: closed -> open ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: No, that patch still doesn't work. -- resolution: fixed -> accepted ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: I've had to split the three #undef's up to just before they're used. -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: Well, I'd probably prefer something akin to my first patch then. There's no need to #undef things at all if we just prefix the usage with PYTHON_ -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9528] Add pure Python implementation of time module to CPython
Changes by Alan Justino : -- nosy: +alanjds versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue9528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9528] Add pure Python implementation of time module to CPython
Alan Justino added the comment: @haypo: Because it affects version 2.7 too. @Victor: Even since we will not backport any modules to Python 2.7, is not worth to sign that this affects it too? Even wontfix or rejected, it affects, does not? Have I made something wrong? Sorry to be so newbie about this. Long explanation: Is not easy to change/extend datetime, as stated by several other before. Searching the bugs for 2.x only does not shows that someone else already care about this issue AND that it exists at 2.x too. I am getting a hard time trying to do some BDD with c-based datetime because I cannot mock it easily to force datetime.datetime.now() to return a desired value, making almost impossible to test time-based code, like the accounting system that I am refactoring right now. Another solution would be to "open" C-based classes to allow modification, that is not planned to be into near future Python versions AFAIK. I came to fill a new bug with all this, but then found this one that is already mature enough, with even BDFL and python-dev opinion. Then my (maybe pointless) plan was to gather more arguments favor to change into python-based datetime, but you replied first... -- ___ Python tracker <http://bugs.python.org/issue9528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9528] Add pure Python implementation of time module to CPython
Alan Justino added the comment: (noticed a typo at the start of my last msg: @Victor should be @brett.cannon) -- ___ Python tracker <http://bugs.python.org/issue9528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Alan McIntyre added the comment: Here's an updated patch against the py3k trunk (testzip-patch3.diff) that passes all tests (including test_zipfile64) on Linux on a 64-bit machine. I can backport this to 2.x, but I'll wait until somebody indicates a need for it before I spend any time on it. -- Added file: http://bugs.python.org/file18533/testzip-patch3.diff ___ Python tracker <http://bugs.python.org/issue1739648> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1710703] zipfile.ZipFile behavior inconsistent.
Alan McIntyre added the comment: Apparenty _EndRecData64 needed the same kind of check that _EndRecData has when trying to seek to the end-of-archive record. So I added that, and everything seems to work correctly now. All tests pass on my 64-bit Linux box (including test_zipfile64). The updated patch against py3k/trunk is attached as zipfile_empty2.diff. -- Added file: http://bugs.python.org/file18534/zipfile_empty2.diff ___ Python tracker <http://bugs.python.org/issue1710703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4844] ZipFile doesn't range check in _EndRecData()
Alan McIntyre added the comment: I wrote a test for this and tried out the patch on the Python3 trunk, and it seems to work ok. I've attached an updated patch that includes the test. It probably wouldn't hurt to go look for other places where a struct is being unpacked without checking lengths first, and see if it makes sense to add a similar check in those places, too. I may do that later if I have some more free time. -- Added file: http://bugs.python.org/file18604/issue4844-with-test.diff ___ Python tracker <http://bugs.python.org/issue4844> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9720] zipfile writes incorrect local file header for large files in zip64
Alan McIntyre added the comment: Thanks for the patch, Craig; I should have some time later today or tomorrow to do a review. Did you have a patch for the test suite(s) as well? If not, I can just make sure your test case is covered in test_zipfile64. -- ___ Python tracker <http://bugs.python.org/issue9720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9720] zipfile writes incorrect local file header for large files in zip64
Alan McIntyre added the comment: Here's an updated patch for the py3k trunk with tests. This pretty much doubles the runtime of test_zipfile64.py. The patch also removes some unnecessary code from the existing test_zipfile64 tests. Note: It looks like writestr will also suffer from a struct.pack overflow if it's given a ZipInfo with the third general purpose flag bit set. I won't have time to address that until next weekend, probably. -- Added file: http://bugs.python.org/file18780/zipfile-huge-files.diff ___ Python tracker <http://bugs.python.org/issue9720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
Alan McIntyre added the comment: Maybe ZipFile should have an option to handle archives in a non-strict mode, in which it would raise warnings or just completely ignore a small set of minor violations of the spec. That way people that want behavior that's in compliance with the spec will have it (by default), but those that need to handle ZIP files that bend the rules can still choose to use the Python standard libraries to get their work done. If there's any interest in this I can work up a patch, tests, and documentation. -- ___ Python tracker <http://bugs.python.org/issue1757072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4844] ZipFile doesn't range check in _EndRecData()
Alan McIntyre added the comment: I had to look up the abbreviation (Easier to Ask Forgiveness than Permission), but that does sound like a good idea. Thanks for mentioning it. :-) -- ___ Python tracker <http://bugs.python.org/issue4844> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1710703] zipfile.ZipFile behavior inconsistent.
Changes by Alan McIntyre : Removed file: http://bugs.python.org/file9144/empty-zipfile.diff ___ Python tracker <http://bugs.python.org/issue1710703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1710703] zipfile.ZipFile behavior inconsistent.
Alan McIntyre added the comment: My apologies if Georg was waiting on me to say, "Yes." :-) I've attached an updated patch that has the NEWS/doc changes Antoine mentioned. I also just checked that the tests still pass on Linux against the current trunk, and that the docs still build properly. -- Added file: http://bugs.python.org/file19112/zipfile_empty3.diff ___ Python tracker <http://bugs.python.org/issue1710703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1710703] zipfile.ZipFile behavior inconsistent.
Changes by Alan McIntyre : Removed file: http://bugs.python.org/file18534/zipfile_empty2.diff ___ Python tracker <http://bugs.python.org/issue1710703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Changes by Alan Kennedy : -- nosy: +amak ___ Python tracker <http://bugs.python.org/issue3566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
New submission from Alan Hourihane :
Python 2.7.1 redefines FSTAT, but the problem is my libc already defines FSTAT
in sys/ioctl.h.
I've worked around this by prefixing the FSTAT define with PYTHON. It should
probably be done with STAT too.
--- Modules/posixmodule.c.old 2011-01-12 01:46:45.0 +
+++ Modules/posixmodule.c 2011-01-12 01:47:05.0 +
@@ -344,11 +344,11 @@
#undef STAT
#if defined(MS_WIN64) || defined(MS_WINDOWS)
# define STAT win32_stat
-# define FSTAT win32_fstat
+# define PYTHON_FSTAT win32_fstat
# define STRUCT_STAT struct win32_stat
#else
# define STAT stat
-# define FSTAT fstat
+# define PYTHON_FSTAT fstat
# define STRUCT_STAT struct stat
#endif
@@ -6641,7 +6641,7 @@
if (!_PyVerify_fd(fd))
return posix_error();
Py_BEGIN_ALLOW_THREADS
-res = FSTAT(fd, &st);
+res = PYTHON_FSTAT(fd, &st);
Py_END_ALLOW_THREADS
if (res != 0) {
#ifdef MS_WINDOWS
--
messages: 126120
nosy: alanh
priority: normal
severity: normal
status: open
title: posixmodule.c redefines FSTAT
type: compile error
___
Python tracker
<http://bugs.python.org/issue10898>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: On Tue, 2011-01-18 at 19:59 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > How about adding "#undef FSTAT" instead? Would it work for you? Sure. Alan. -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11023] pep 227 missing text
New submission from Alan Isaac : In PEP 227 missing text is marked with XXX. Most of this is just calls for examples and elaboration. However under the Implementation section XXX marks a substantive question about the documentation. Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ... -- assignee: docs@python components: Documentation messages: 127184 nosy: aisaac, docs@python priority: normal severity: normal status: open title: pep 227 missing text type: feature request ___ Python tracker <http://bugs.python.org/issue11023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11023] pep 227 missing text
Alan Isaac added the comment: Bear with my confusion about your response. Are you saying that CPython documentation bugs cannot be submitted here, or that this does not constitute a CPython documentation bug? I assume the latter. But then, can you tell me where to find the correct CPython documentation after I read the following quote from PEP 277? http://www.python.org/dev/peps/pep-0227/ "Implementation XXX Jeremy, is this still the case? The implementation for C Python uses flat closures [1]." In case you might care about a user confusion ... Your reply left me puzzled that PEPs that have reached the standards track would not be considered part of the CPython documentation distribution. Thank you, Alan Isaac -- ___ Python tracker <http://bugs.python.org/issue11023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Changes by Alan Kennedy <[EMAIL PROTECTED]>: -- nosy: +amak __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre <[EMAIL PROTECTED]> added the comment: Sure, I'll look at it later today or over the weekend. I should probably break out the parts that apply to other issues and update those patches as well. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3317] duplicate lines in zipfile.py
Alan McIntyre <[EMAIL PROTECTED]> added the comment: I don't see a patch attached, but the duplicated code does need removing. If you can attach a patch I'll try it out. As much as I dislike the "string" names (magicXXX seemed much more descriptive), I suppose they're publicly available and shouldn't be renamed without a good reason. (Unless not being in __all__ counts as being something one shouldn't depend on as part of the API ;) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3317] duplicate lines in zipfile.py
Alan McIntyre <[EMAIL PROTECTED]> added the comment: The patch seems to work just fine for me, all tests pass (including test_zipfile64) on an Intel Mac. I'd vote to go ahead and revert the magicXXX variables back to their original names--I'm sure Twisted isn't the only project out there that made use of them. If the magicXXX name change gets checked in along with the current patch I'll run the zip64 tests on Mac and Linux afterward, since they don't get run in the standard test run on the buildbots. I don't currently have a Windows machine to test with. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3317] duplicate lines in zipfile.py
Alan McIntyre <[EMAIL PROTECTED]> added the comment: Thanks for fixing this, Amaury. I ran the test_zipfile64 and test_zipfile tests on Linux and OS X, and they pass. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3535] zipfile has problem reading zip files over 2GB
Alan McIntyre <[EMAIL PROTECTED]> added the comment: Your patch seems like a better way to detect whether a file is written as Zip64, and it seems to be able to properly handle extracting a >2GB file from a >2GB archive, so I'd vote to include it. I tested it with r66233, using a file made from the output of large.c, zipped with the built-in archiver on OS X 10.4.11. All regression tests pass, including test_zipfile64, on both Linux and OS X. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3535> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3535] zipfile has problem reading zip files over 2GB
Alan McIntyre <[EMAIL PROTECTED]> added the comment: No, I don't have commit access at the moment. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3535> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3980] win32file.GetCommState incorrect handling of DCB
New submission from Alan Gardner <[EMAIL PROTECTED]>: I believe I have found a bug in win32file.GetCommState and win32file.SetCommState. I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version. It exists in Win2k and WinXP. I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file. The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program). I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi). In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message. After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file. When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872. When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState(). >From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096. For example, if I try to execute DCB.XoffLim = 16128 SetCommState(porthandle,DCB) I get an exception: (87, 'SetCommState', 'The parameter is incorrect.') However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message. For example, after having opened and closed the port in Procomm: >>> DCB = GetCommState(porthandle) >>> DCB.XoffLim 16128L >>> SetCommState(porthandle,DCB) (.. hangs here for several seconds ..) If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine. For example, after having opened and closed the port in Procomm: >>> DCB = GetCommState(porthandle) >>> DCB.XoffLim = 128 >>> DCB.XonLim = 512 >>> SetCommState(porthandle,DCB) >>> This works fine, and I can go on to open the port normally. I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution. I am still baffled by why SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically. I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports. Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers. Thank you -Alan Gardner Woods Hole Oceanographic Institution Woods Hole, MA 02543 -- components: Extension Modules, Windows messages: 73888 nosy: jiaailun severity: normal status: open title: win32file.GetCommState incorrect handling of DCB type: crash versions: Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3980> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8283] series of lamdas in loop sets the paramater on all calls to that of the last call
New submission from alan hoover : Background: building a screen using Tkinter based on information from a database to let user take action on the database rows. I don't know how many rows there will be, so I'm storing the widgets in arrays for each column. Code: for row in getDBrows(): self.buttons.append(Tkinter.Button(self,text='UnLoad it', command=lambda :self.unload(row[0]))) Problem: When executing the above code, all the buttons have the key to the database table that belongs to the last row. I found a work around -- by moving the call to create the button (containing the lambda) to a separate function and call that function to create the button instead of creating the button directly, the buttons then make their callback with a correct database key. Workaround: for row in getDBrows(): self.buttons.append(self.buildbutton(row[0])) . . def buildbutton(self,key): return Tkinter.Button(self,text='UnLoad it', command=lambda: self.unload(key)) When using the workaround code instead of the original code, the button for each row has the appropriate key to the database. Speculation: It acts like the lambda definitions don't get solidified until the containing block exits; at that time, the lambda definition(s) get locked in with the current value of the variable getting passed into the lambda as a parameter. By moving the lambda call to a different block (separate function), the lambda gets "locked" when that block (function) exits instead of when the containing block (loop) exits. -- components: IDLE, Tkinter, Windows messages: 102120 nosy: alan.hoover severity: normal status: open title: series of lamdas in loop sets the paramater on all calls to that of the last call type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue467924] Improve the ZipFile Interface
Alan McIntyre added the comment: There was another issue that also asked for an extract feature, and if I recall correctly I said I'd try to work on it (I think I have some code somewhere for it but I'll have to look). Tonight or tomorrow I will see if I can find that other issue and let you know about it, and maybe take a look around at the various zipfile improvement/change requests to see if they've been completely addressed. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue467924> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1760357] ZipFile.write fails with bad modification time
Alan McIntyre added the comment: At the moment I don't have a Windows machine available, but on my Mac, time.localtime doesn't seem to mind interpreting negative input values. So I doubt that forcing timestamps to be non-negative is the way to fix this. I poked around a bit in the current 2.6 source, and it seems to me that in this case the Windows XP localtime function doesn't like a timestamp value that was generated by the same platform's stat function. It seems like raising a ValueError is the correct thing for the time module to do, since it relies on the platform to do the conversions; what should zipfile.writestr do? I don't like the idea of silently using some dummy timestamp if the conversion of os.stat results fails, and I can't think of an alternative at the moment. -- nosy: +alanmcintyre _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1760357> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Alan McIntyre added the comment: This sort of change definitely needs to be made to avoid reading huge files into memory for testzip(). I've attached a modified patch as zipfile_testzip_amcintyre.diff; it didn't seem appropriate to have a module-level variable for the size of the test read, and I made a few other minor tweaks. -- nosy: +alanmcintyre Added file: http://bugs.python.org/file9057/zipfile_testzip_amcintyre.diff _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1739648> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue683910] zipfile should have a tarfile-like API
Alan McIntyre added the comment: I just posted a patch on issue 467924 (http://bugs.python.org/issue467924) that adds extract and extractall methods. Recommend closing this issue unless the patch over there is insufficient for some reason. -- nosy: +alanmcintyre Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue683910> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue467924] Improve the ZipFile Interface
Alan McIntyre added the comment: I attached a patch with the following changes (as zipfile_extract.diff): (1) Add a note to the docs (under writestr) about how the compression is selected if a ZipInfo is passed as the zinfo_or_arcname parameter. If anybody thinks it's a good idea to add a compression argument to the ZipInfo constructor, I can modify the patch/docs accordingly. (2) Add an extract method to ZipFile and associated test/documentation changes. Added file: http://bugs.python.org/file9066/zipfile_extract.diff Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue467924> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue467924] Improve the ZipFile Interface
Alan McIntyre added the comment: Are the method renames/additions suggested in the original issue worth doing? When I first started using this module, I found the documentation easy and thorough enough to understand how to use it, so I would vote for just leaving the ZipFile interface the way it is. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue467924> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files
Alan McIntyre added the comment: The reported warning was being produced when writing the "end of central directory record", in ZipFile.close(). Based on a little experiment with 70k test text files, the default archiver in OS X appears to just use the number of files mod 64k in the end of central directory record. I tweaked the ZipFile close() method to do this, and the resulting ZIP file appears to work just fine, both with the OS X archiver and with ZipFile (without ZIP64 enabled). There's a blurb in the ZIP format description about this sort of thing: "If an archive is in ZIP64 format and the value in this field is 0x, the size will be in the corresponding 8 byte zip64 end of central directory field." I don't know if that means "the right thing" is to switch the archive to ZIP64 format if more than 64k files are added, though. If I have time I'll go look at some other open source ZIP implementations, but I won't swear I'll ever get around to it. :) -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1526> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files
Alan McIntyre added the comment: Here's a patch that just uses the "mod 64k" approach. If I get time to look at some other implementations, and find a better way to handle it, I'll submit an update. Otherwise, maybe on bug day people can try it out with a variety of archiving utilities to see if there's any compatibility issues. Added file: http://bugs.python.org/file9075/zipfile_lotsafiles.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1526> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Based on the ZIP spec (I'm using the one here: http://www.pkware.com/documents/casestudies/APPNOTE.TXT), I'm inclined to agree. There's a general note that says "All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order." I can't find any explicit mention of any fields that should be signed. Since I find myself poking around in the ZIP file format today, I may try changing all the format strings to unsigned, and writing up some tests to check cases that can be run in a reasonable amount of time. If I get anything usable I'll post a patch. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011893] Problems importing packages in ZIP file
Alan McIntyre added the comment: I just tried out this test with the trunk and 2.5.2 from svn (on OS X, not sure if that might make a difference), and didn't get the reported error. Since the issue has apparently been fixed at some point, is there any reason not to close this issue? -- nosy: +alanmcintyre _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1011893> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue774221] 2.3c1: zipfile.py confused by garbage at the very end of zip
Alan McIntyre added the comment: Since there's no reply about where ZIP files with appended 'garbage' might come from, should this be closed? I agree with amk; it doesn't seem wise to ignore incorrectly formatted files without a good reason. On a related note, it seems that correctly formatted ZIP files with comments longer than 4k will not be recognized as a ZIP file by the zipfile module. There's some comment about not looking at more than the last 4k of the file for "efficiency" reasons, but failing to interpret a correct file seems to override the efficiency concern of reading/searching another 60k of data. I'll open a separate tracker item for this, since it's not strictly related to the original issue. -- nosy: +alanmcintyre Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue774221> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module
New submission from Alan McIntyre: The current behavior of zipfile._EndRecData is to look in the last 4k of data in a file if it appears it might have an archive comment; this results in flagging proper ZIP files with comments longer than ~4074 bytes as "not a ZIP file." I plan on posting a patch for this later, but figured this should be documented in case I don't get around to it. -- components: Library (Lib) messages: 59411 nosy: alanmcintyre severity: normal status: open title: ZIP files with archive comments longer than 4k not recognized as valid by zipfile module type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1746> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files
Alan McIntyre added the comment: Oh thanks, I meant to ask whether or not the run time was too long, but forgot. Only running when -ulargefile is enabled seems fine to me. I can tweak the patch for that if you'd like; moving it to test_zipfile64 should do that, right? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1526> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011893] Problems importing packages in ZIP file
Alan McIntyre added the comment: I just tried it on 2.5 and 2.6, since I didn't have the earlier versions available. If I find some time I'll see if I can try it on 2.3 & 2.4; maybe that will shed some light on whether it's been fixed or if is something specific to Windows that could still be broken. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1011893> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Well I can't promise it will be swift, since my winter vacation ended today, but I'll keep on top of it as best I can. :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Here's the first draft of a patch (zipfile-unsigned-fixes.diff) that does a few things: - Interpret fields as unsigned unless required (CRC, etc.) - Corrects reading of ZIP files with large archive comments - Replaces hard-coded structure sizes with module-level variables (calculated using struct.calcsize) - When writing a file in ZipFile.close(), if the ZipFile instance has a comment value, this value is now written as the archive comment - Renamed some of the module variables to better match the names used in the ZIP file spec - General cleanup & addition of comments to (hopefully) make the code a little easier to follow Test & doc changes are included, & this code currently passes regression test suite with -uall on OS X. Added file: http://bugs.python.org/file9113/zipfile-unsigned-fixes.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Thanks for the reminder, Eric; I'll include that and post the updated patch. As a side note, on OS X, running regrtest with -uall or -ulargefile still skips test_zipfile4 for some reason. I'll have a look at that before submitting the next version of the patch as well. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Currently the extra field data is only parsed when it contains Zip64 extended information. It could probably be broken up into a list of (id, data) pairs at a minimum for all data types, since the spec says that's the structure that "should" be used. I don't know whether the results of that parse should be kept in a new slot; putting it in the ZipInfo.extra slot would probably be bad for 2.6, since users might be counting on the current behavior of a raw chunk of data still being there. Does anybody else have any suggestions for this? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module
Alan McIntyre added the comment: A fix for this is included in the patch for issue 1622. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1746> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: Here's an updated patch (zipfile-unsigned-fixes2.diff) that contains Eric's fixes. I also changed the structure for the Zip64 extension data to be unsigned. I think this should cover all the deficiencies caused by the improper use of unsigned values. Note: if this patch is committed, then issue 1746 should be closed since it is fixed with this patch. Added file: http://bugs.python.org/file9139/zipfile-unsigned-fixes2.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre added the comment: I just noticed that my changes for issue 1526 are included in this patch. Eric, if you have time could you have a look at that issue and see if you think I addressed it properly? If not I can back them out into a separate patch for that issue. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files
Alan McIntyre added the comment: I just noticed that my changes for this issue are included in the patch for issue 1622; if that gets committed then this issue should be closed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1526> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1710703] zipfile.ZipFile behavior inconsistent.
Alan McIntyre added the comment: Here's a quick patch that covers the issues mentioned in my post from 2007-05-09. Added file: http://bugs.python.org/file9144/empty-zipfile.diff _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1710703> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1698917] ZipFile.printdir fix (2.6)
Alan McIntyre added the comment: I think you applied the wrong patch; the referenced revision doesn't include the tests from zipfile-printdir-2.diff. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1698917> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
Alan McIntyre added the comment: It would seem that such a zip file is not consistent with the spec (http://www.pkware.com/documents/casestudies/APPNOTE.TXT). My first reaction is that we shouldn't accept behavior outside the spec unless it's something that's done by many popular ZIP applications. However, if somebody can convince me that this is a deviation from the spec that we should support, I'll write a patch for it. :) -- nosy: +alanmcintyre _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1757072> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting
Alan McIntyre added the comment: I noticed that in the trunk, ZipFile._extract_member, at line 865, still uses 777 (the default of os.makedirs) to create directories. I attached a patch for it. A quick grep shows that tarfile still uses the default permissions for os.makedirs and mkdir. Should these all be changed to 700? -- nosy: +alanmcintyre Added file: http://bugs.python.org/file9351/zipfile-dirperm.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2004> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Factorial
Alan McIntyre added the comment: It seems like most of the methods on integers are for two-argument operations (add, mul, div, etc.), while a lot of single-argument operations are in the math module. If this gets added would it fit better as a function in the math module? I have to say a factorial function is something I've found myself writing several times, so I certainly wouldn't mind having one included. Yeah, it's a one-liner, but so is hypot, and that's already in the stdlib. And most calculators don't have a hypot button. ;) -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Factorial
Alan McIntyre added the comment: >Except that hypot is not a one-liner, if you want to get edge cases right. Ah, true; thanks for pointing that out. Should there be some upper limit on the argument math.factorial would take? At the moment I can't think of any reason for picking a given limit, except perhaps execution time. (10**4)! can be done in about 1 second on my old & slow laptop; are there realistic use cases for numbers much bigger than that? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2381] test_subprocess fails if your sys.executable is on a path with a space in it
New submission from Alan Brooks <[EMAIL PROTECTED]>: Patch attached that escapes the executable name so this test doesn't fail. -- components: Tests files: test_subprocess-r61479.patch keywords: patch messages: 63883 nosy: lanny severity: normal status: open title: test_subprocess fails if your sys.executable is on a path with a space in it versions: Python 2.6 Added file: http://bugs.python.org/file9719/test_subprocess-r61479.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2381> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1503] test_xmlrpc is still flakey
Alan McIntyre <[EMAIL PROTECTED]> added the comment: It's my fault the xmlrpc tests try to use non-blocking sockets. That got added because sometimes failing tests would just sit there with the server blocking until the entire test process got killed for running too long. There are some tests that are skipped in test_xmlrpc because of (apparent) Windows socket quirks; should they also be skipped for OS X PPC, or should the flaky tests just be scrapped? When I was last working on this I couldn't come up with a better way to run these tests, so unless somebody can suggest a new approach I'm just left with recommending the skip & scrap options as the only way to stop the flakiness. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1503> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2452] inaccuracy in httplib timeout documentation
Changes by Alan Kennedy <[EMAIL PROTECTED]>: -- nosy: +amak __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2452> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre <[EMAIL PROTECTED]> added the comment: Is there anything else that needs to be addressed before this can be committed? At the moment I don't know of anything, just wanted to make sure somebody wasn't waiting on me. As a reminder, issues #1526 and #1746 should be closed if this patch is committed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3432] Mac, 2.6 framework install error
Alan Brooks added the comment: I also get this exact same problem. Mac OS 10.5.6 on an Intel MacBook trying to install the release version of 2.6.1. I found it was failing to build _Res, but worked around by *not* using --enable-universalsdk. -- nosy: +lanny ___ Python tracker <http://bugs.python.org/issue3432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38780] SysLogHandler crash atexit
Alan Robertson added the comment: There are a variety of different reasons this can fail, not just on MacOS. You could give it a bad IP address of a server, etc. [That was my particular case]. The constructor should create an attribute 'socket' and initialize it to None early on. Then, the close function in logging/handlers.py should check for None. Or alternatively, it shouldn't register the object with atexit until it's been constructed "well-enough". -- nosy: +alanr ___ Python tracker <https://bugs.python.org/issue38780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39841] "as" variable in except block deletes local variables with same name
New submission from Alan Robertson :
When an exception "as" variable occurs, it deletes local variables with the
same name. This is certainly surprising, and doesn't appear to be a documented
behavior (but maybe I don't know where to look). The word "bug" comes to mind.
The following few lines of code illustrate it nicely:
def testme():
err = Exception("nothing worked")
try:
raise ValueError("no value")
except ValueError as err:
pass
print(err)
testme()
--
components: Interpreter Core
files: foo.py
messages: 363300
nosy: alanr
priority: normal
severity: normal
status: open
title: "as" variable in except block deletes local variables with same name
versions: Python 3.7
Added file: https://bugs.python.org/file48946/foo.py
___
Python tracker
<https://bugs.python.org/issue39841>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39841] "as" variable in except block deletes local variables with same name
Alan Robertson added the comment: Thanks for your kind explanation. I may even vaguely remember seeing this sometime in the past. Thanks much for your time! -- ___ Python tracker <https://bugs.python.org/issue39841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38780] SysLogHandler crash atexit
Alan Robertson added the comment: On Wed, Jan 6, 2021, at 10:30 AM, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > TBH as I said in the now-closed PR, using a NullSocket seems overkill. > As mentioned in msg359594, it seems to make more sense to assign a > socket attribute to None early in the constructor. If an error occurs > during socket creation, the socket attribute will remain at None. When > closing, just ensure the socket attribute isn't None before trying to > close it. This mirrors what SocketHandler does. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue38780> > ___ > -- Alan Robertson al...@unix.sh -- ___ Python tracker <https://bugs.python.org/issue38780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38780] SysLogHandler crash atexit
Alan Robertson added the comment: As far as I know, this only happens during shutdown. During shutdown it has already removed the attribute as part of the teardown process. In this case adding the attribute at the begining will do no good. On Wed, Jan 6, 2021, at 10:30 AM, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > TBH as I said in the now-closed PR, using a NullSocket seems overkill. > As mentioned in msg359594, it seems to make more sense to assign a > socket attribute to None early in the constructor. If an error occurs > during socket creation, the socket attribute will remain at None. When > closing, just ensure the socket attribute isn't None before trying to > close it. This mirrors what SocketHandler does. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue38780> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43240] IDLE Classic Unix keyboard shortcuts broken
New submission from Alan Moore : Using IDLE 3.9.1 on Arch Linux. In IDLE I've selected the "classic unix" key set. It worked for a while, then stopped registering key combinations for more than one key (e.g. Ctrl-x Ctrl-s). Have tried creating a custom key set and manually setting the shortcuts, but it still fails the same way. Caps lock is not on (disabled on my system). Have also tried moving configs and starting fresh, does not help. It had been working, then suddenly stopped in the middle of a work day and I can't get it working again. -- assignee: terry.reedy components: IDLE messages: 387124 nosy: Alan Moore, terry.reedy priority: normal severity: normal status: open title: IDLE Classic Unix keyboard shortcuts broken type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43240] IDLE Classic Unix keyboard shortcuts broken
Alan Moore added the comment: OK, it seems that closing all my firefox windows restored correct behavior to IDLE. I can only guess that somehow firefox was eating the Ctrl-x. Not sure if this is a firefox issue, a window manager issue, or an IDLE issue. If you think it's not the latter, feel free to close. -- ___ Python tracker <https://bugs.python.org/issue43240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43240] IDLE Classic Unix keyboard shortcuts broken
Alan Moore added the comment: An interesting note this morning, and again I don't know if this is actually an IDLE bug; I had left IDLE running overnight and opened a new code window this morning. Somehow IDLE "forgot" that Ctrl-N means "next line" and not "new window". I closed all my firefox windows, then went into IDLE settings, changed the key set to something else and back to Classic Unix, now it works correctly again. Firefox has been known to steal my keyboard input from time to time when not focused, though it's usually all-or-nothing. I don't know if it's the culprit or if I'm just blaming it due to past prejudice, but it seems to set things right in IDLE faster if I close all firefox windows. In any case, I don't know if this could be an IDLE bug or not, just thought I'd share. -- ___ Python tracker <https://bugs.python.org/issue43240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43240] IDLE Classic Unix keyboard shortcuts broken
Alan Moore added the comment: Ok, sorry to keep poking at this issue, but I think I was too hasty in blaming firefox. As I previously mentioned, IDLE "forgot" that Ctrl-N meant "next line" and reverted it to "new window". I fixed that behavior by changing and resetting the key set, HOWEVER, now the multiple-key sequences like Ctrl-X-Ctrl-S are broken again. Closing all other programs, rebooting the system, defaulting my IDLE configuration -- none of that makes a difference. Truly I'm baffled. Is there actually code in IDLE/Tkinter to handle those kind of keyboard shortcuts, or is that a Tcl/Tk feature that is merely exposed by the Python side? If the former, could someone point me in the direction of said code? -- ___ Python tracker <https://bugs.python.org/issue43240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43240] IDLE Classic Unix keyboard shortcuts broken
Alan Moore added the comment:
Spent some time today with IDLE and PDB, and I've ruled out any other program
on my system as the culprit:
- I can create a tkinter GUI that will respond to a binding like
and it works fine.
- In pdb, I can bind <> to a callback and it is getting fired when
Ctrl-x is pressed. Thus, I was wrong to think anything else is "eating" the
ctrl-x.
- Also in pdb, an .event_info('<>') call on the editor's Text
widget returns ('',), so it looks bound
correctly? If I generate a <> event, the dialog pops up as it
should.
Nevertheless, Ctrl-x Ctrl-s opens the find dialog, and no other Ctrl-x (other
keystroke) binding works. I'm stumped.
--
___
Python tracker
<https://bugs.python.org/issue43240>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40815] Multiprocessing docs don't describe thread-safety
Change by Alan Briolat : -- nosy: +alan.briolat ___ Python tracker <https://bugs.python.org/issue40815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41339] make queue.Queue objects iterable
New submission from Alan Iwi : It is possible to make `queue.Queue` and `queue.SimpleQueue` objects iterable by adding simple `__iter__` and `__next__` methods. This is to suggest adding these methods to the existing `Queue` and `SimpleQueue` so that they are iterable by default. ``` class Fifo(SimpleQueue): def __iter__(self): return self def __next__(self): if not self.empty(): return self.get() raise StopIteration ``` -- components: Library (Lib) messages: 373950 nosy: alaniwi priority: normal severity: normal status: open title: make queue.Queue objects iterable type: enhancement ___ Python tracker <https://bugs.python.org/issue41339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35749] Rewrite asyncio signal handler
Alan Jenkins added the comment: Here's a simple test case that fails on the main branch. https://github.com/sourcejedi/cpython/commit/50184ea3b354fd775866d036ccee058ec6734927 > the patch assumes that python signal handler will be called *before* reading > from self-pipe. > Otherwise, a signal callback will be postponed up to next writing to the > pipe, which looks like a hidden bug. I think it will be? I can imagine it being a concern for future changes though. I thought it could break if anyone takes seriously the comment "XXX Signals should be recorded per thread, now we have thread state." :-). But if we're not confident, surely all we have to do is make sure to call _write_to_self() at the end of the python signal handler (_UnixSelectorEventLoop._sig_handler()). It seems a pity not to have example code we can point to, that handles signals correctly. Even if it's too tedious to explain the correct way in the official docs. -- nosy: +sourcejedi ___ Python tracker <https://bugs.python.org/issue35749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher
New submission from Alan Jenkins : ## Test program ## import asyncio import time import os import signal import sys # This bug happens with the default, ThreadedChildWatcher # It also happens with MultiLoopChildWatcher, # but not the other three watcher types. #asyncio.set_child_watcher(asyncio.MultiLoopChildWatcher()) # Patch os.kill to call sleep(1) first, # opening up the window for a race condition os_kill = os.kill def kill(p, n): time.sleep(1) os_kill(p, n) os.kill = kill async def main(): p = await asyncio.create_subprocess_exec(sys.executable, '-c', 'import sys; sys.exit(0)') p.send_signal(signal.SIGTERM) # cleanup await p.wait() asyncio.run(main()) ## Test output ## Traceback (most recent call last): File "", line 1, in File "/home/alan-sysop/src/cpython/Lib/asyncio/runners.py", line 44, in run return loop.run_until_complete(main) File "/home/alan-sysop/src/cpython/Lib/asyncio/base_events.py", line 642, in run_until_complete return future.result() File "", line 3, in main File "/home/alan-sysop/src/cpython/Lib/asyncio/subprocess.py", line 138, in send_signal self._transport.send_signal(signal) File "/home/alan-sysop/src/cpython/Lib/asyncio/base_subprocess.py", line 146, in send_signal self._proc.send_signal(signal) File "/home/alan-sysop/src/cpython/Lib/subprocess.py", line 2081, in send_signal os.kill(self.pid, sig) File "", line 3, in kill ProcessLookupError: [Errno 3] No such process ## Tested versions ## * v3.10.0a1-121-gc60394c7fc * python39-3.9.0-1.fc32.x86_64 * python3-3.8.6-1.fc32.x86_64 ## Race condition ## main thread vs ThreadedChildWatcher._do_waitpid() thread p=create_subprocess_exec(...) waitpid(...) # wait for process exit p.send_signal(9) ## Result ## A signal is sent to p.pid, after p.pid has been reaped by waitpid(). It might raise an error because p.pid no longer exists. In the worst case the signal will be sent successfully - because an unrelated process has started with the same PID. ## How easy is it to reproduce? ## It turns out the window for this race condition has been kept short, due to mitigations in the subprocess module. IIUC, the mitigation protects against incorrect parallel use of a subprocess object by multiple threads. def send_signal(self, sig): # bpo-38630: Polling reduces the risk of sending a signal to the # wrong process if the process completed, the Popen.returncode # attribute is still None, and the pid has been reassigned # (recycled) to a new different process. This race condition can # happens in two cases [...] self.poll() if self.returncode is not None: # Skip signalling a process that we know has already died. return os.kill(self.pid, sig) ## Possible workarounds ## * SafeChildWatcher and FastChildWatcher should not have this defect. However we use ThreadedChildWatcher and MultiLoopChildWatcher to support running event loops in different threads. * PidfdChildWatcher should not have this defect. It is only available on Linux, kernel version 5.3 or above. It would be possible to avoid the ThreadedChildWatcher race by using native code and pthread_cancel(), so that the corresponding waitpid() call is canceled before sending a signal. Except the current implementation of pthread_cancel() is also unsound, because of race conditions. * https://lwn.net/Articles/683118/ "This is why we can't have safe cancellation points" * https://sourceware.org/bugzilla/show_bug.cgi?id=12683 "Race conditions in pthread cancellation" -- components: asyncio messages: 379229 nosy: asvetlov, sourcejedi, yselivanov priority: normal severity: normal status: open title: race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher
Alan Jenkins added the comment: There's one way to fix this in MultiLoopChildWatcher (but not ThreadedChildWatcher). Make sure the waitpid() runs on the same thread that created the subprocess. Prototype: https://github.com/sourcejedi/cpython/commit/92f979bce4582e807facb1c274a962b3caf0d2eb The other approach would be to copy subprocess.wait(timeout) - keep waking up regularly and polling to see if the process has exited yet. I'm not convinced ThreadedChildWatcher is fixable. You can't call waitpid() in one thread, and let someone call kill() in a different thread. You could try avoiding calling waitpid() until someone does `await asyncio.subprocess.Process.wait()`. I think I didn't like it because - what happens if you cancel a wait() task? I think you want to cancel the waitpid() so you could safely kill() again... And we don't have any way to cancel the blocking waitpid() call, at least not from python, definitely not since PEP-475. -- ___ Python tracker <https://bugs.python.org/issue42110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42110] race condition in ThreadChildWatcher (default) and MultiLoopChildWatcher
Alan Jenkins added the comment: Put the other way, if you wanted to fix this bug in ThreadedChildWatcher, and go as far as allowing cancelling Process.wait(), followed by kill() / send_signal(), then I think you need - * siginterrupt(SIGCHLD, 1) * not to mind about any random C code that doesn't really handle being interrupted. Like printf(), ho hum. https://groups.google.com/g/comp.unix.programmer/c/QZmFw1VytYs/m/BSBXBHTI1REJ * add & use a new call like os.waitpid_interruptible(), which doesn't restart on EINTR, as a workaround for PEP-475. * set a "stop" flag for the watcher thread * use threading.pthread_kill() (available on *most* python platforms) to interrupt the watcher thread. Spoof SIGCHLD, this will avoid conflicts with a python handler for any other signal. * wait for the watcher thread to finish using Thread.join() * now you can safely find out whether the child process has been reaped, or whether it's safe to kill it. -- ___ Python tracker <https://bugs.python.org/issue42110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42173] Drop Solaris support
Change by Alan Coopersmith : -- nosy: +alanc ___ Python tracker <https://bugs.python.org/issue42173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown
Alan Yorinks added the comment: Hi Carol, Thanks for the update. I retested on Python 3.7 and the problem seems to have been resolved some where along the way. BTW, I am using MicroPython on an ESP8266 remotely controlled from a Python program on a PC. You can read about it here: https://mryslab.github.io/python_banyan/#gpio_intro/. Looking forward to 3.8! Thanks again, Alan On 6/6/19 3:56 PM, Carol Willing wrote: > Change by Carol Willing : > > > -- > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue23324> > ___ -- ___ Python tracker <https://bugs.python.org/issue23324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1
Change by Alan Huang : -- pull_requests: +11509, 11510 ___ Python tracker <https://bugs.python.org/issue35045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1
Change by Alan Huang : -- pull_requests: +11509 ___ Python tracker <https://bugs.python.org/issue35045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
