[issue3027] if extended c module is calling Windows API waitForSingleObject, it will block other thread.
New submission from patrick <[EMAIL PROTECTED]>: The c extend module is as the attached file "WindowsFuncs.cpp", it wraps some Windows event APIs The python script is as the attached file "test.py", run that script, we could find in the new thread, the calling to Windows API waitForSingleObject will block the main thread printing, that's really strange. The output of running is as the attached file "test.output". -- components: Interpreter Core files: attach.zip messages: 67633 nosy: patrick severity: normal status: open title: if extended c module is calling Windows API waitForSingleObject, it will block other thread. versions: Python 2.5 Added file: http://bugs.python.org/file10502/attach.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3027> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3027] if extended c module is calling Windows API waitForSingleObject, it will block other thread.
patrick <[EMAIL PROTECTED]> added the comment: Yes, after wrapping the calling to block operation with marco Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, that issue is gone. Thank you. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3027> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2438] subprocess.Popen with wildcard arguments
New submission from Patrick <[EMAIL PROTECTED]>: When using wildcards as arguments to the processes being spawned by Popen, it seems to interpret them as hard literals. IE, when doing something like: >>> import subprocess >>> output = subprocess.Popen(['ls', '*'], stdout=subprocess.PIPE).communicate()[0] ls: *: No such file or directory >>> -- components: Library (Lib) messages: 64204 nosy: pbrandt severity: normal status: open title: subprocess.Popen with wildcard arguments type: behavior versions: Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2438> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10296] ctypes catches BreakPoint error on windows 32
Patrick added the comment: This affects me too. -- nosy: +pjlbyrne ___ Python tracker <http://bugs.python.org/issue10296> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10365] IDLE Crashes on File Open Dialog when code window closed before other file opened
Patrick added the comment: Forgive me if I'm not following the correct process. But I believe I have seen this issue again in 3.3. Not sure I captured exactly what is needed from the command line. The file being openeed is from the Python Hands On Class Examples http://anh.cs.luc.edu/python/hands-on/ c:\python33\python.exe -m idlelib.idle Exception in Tkinter callback Traceback (most recent call last): File "c:\python33\lib\tkinter\__init__.py", line 1442, in __call__ return self.func(*args) File "c:\python33\lib\idlelib\MultiCall.py", line 174, in handler doafterhandler.pop()() File "c:\python33\lib\idlelib\MultiCall.py", line 221, in doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func) ValueError: list.remove(x): x not in list Traceback (most recent call last): File "c:\python33\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "c:\python33\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "c:\python33\lib\idlelib\idle.py", line 11, in idlelib.PyShell.main() File "c:\python33\lib\idlelib\PyShell.py", line 1477, in main root.mainloop() File "c:\python33\lib\tkinter\__init__.py", line 1038, in mainloop self.tk.mainloop(n) -- nosy: +Patrick.Walters ___ Python tracker <http://bugs.python.org/issue10365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10365] IDLE Crashes on File Open Dialog when code window closed before other file opened
Patrick added the comment: Thanks for the pointer to the other issue. It looks spot on. -- ___ Python tracker <http://bugs.python.org/issue10365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window
Patrick added the comment: I am seeing this as well. It does not repro 100% of the time, but frequently enough that its hard to get anything done. My repro is a little simpler and might help understanding the fix. Win7 Python 3.3 I start IDLE normally from the shortcut in the install. Ctrl-N to open and edit window. Ctrl-O to open a file. Select file and then Idle exits. As mentioned, using the menu to open the file seems to work more reliably. I've not had a crash that way. -- nosy: +Patrick.Walters ___ Python tracker <http://bugs.python.org/issue8900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46820] SyntaxError on `1not in...`
New submission from Patrick Reader : The following code gives a SyntaxError in 3.10, but used to work fine before (I have tested it in 2.7, 3.8, 3.9): 1not in [2, 3] It seems to be only the `not in` syntax which is affected; all other keywords still work correctly: 1in [2, 3] 1or 2 1and 2 1if 1else 1 1is 1 I know this syntax is deprecated in 3.10 (bpo43833), but it still needs to work for now, so that old code written like this can keep working. -- components: Parser messages: 413664 nosy: lys.nikolaou, pablogsal, pxeger priority: normal severity: normal status: open title: SyntaxError on `1not in...` type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1366] popen spawned process may not write to stdout under windows
New submission from Patrick Mézard:
Let child.py be:
"""
import sys
sys.stdout.write('1:stdout\n')
sys.stdout.flush()
sys.stderr.write('2:stderr\n')
sys.stderr.flush()
sys.stdout.write('3:stdout\n')
sys.stdout.flush()
"""
and parent.py:
"""
import os
cmd = 'python child.py'
for l in os.popen(cmd):
print l,
"""
Then running it:
"""
>python parent.py
1:stdout
>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
"""
I would have expected at least:
"""
1:stdout
3:stdout
"""
to be output, which actually happens if the stderr is nullified like
"python child.py 2>nul" in parent.py call.
Am I wrong ?
--
components: Windows
messages: 56991
nosy: pmezard
severity: normal
status: open
title: popen spawned process may not write to stdout under windows
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1366>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1366] popen spawned process may not write to stdout under windows
Patrick Mézard added the comment: pythonmeister: I never expected stderr to be redirected, just *all stdout* to be captured. But... gagenellina: you are completely right about the failure. Still, this issue happened with a real world application written in C, and redirecting manually stderr to :NUL: solved it unexpectedly. I did not expect spawned process behaviour to differ when its stderr is being redirected. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1366> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13142] Add support for other HTTP methods in urllib.request
New submission from Patrick Westerhoff : Hey, I would like to request the support of other HTTP methods (other than GET and POST) in urllib.request. While it’s actually simple enough to override the Request class to add such a possibility, I think it is far too simple to leave it out of the standard library. I’ve attached a patch that adds the functionality with a simple `method` property. The `get_method` function then simply looks if a custom method was entered, and otherwise falls back to the default behaviour. Thanks a lot! Patrick Westerhoff Btw. Being a Git user, I hope the patch is actually useful ;) -- components: Library (Lib) files: urllib.patch keywords: patch messages: 145283 nosy: poke priority: normal severity: normal status: open title: Add support for other HTTP methods in urllib.request type: feature request versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23362/urllib.patch ___ Python tracker <http://bugs.python.org/issue13142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13142] Add support for other HTTP methods in urllib.request
Patrick Westerhoff added the comment: Oh sorry, I didn’t see that one. :) -- ___ Python tracker <http://bugs.python.org/issue13142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673007] urllib2 requests history + HEAD support
Changes by Patrick Westerhoff : -- nosy: +poke ___ Python tracker <http://bugs.python.org/issue1673007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673007] urllib2 requests history + HEAD support
Patrick Westerhoff added the comment: Senthil, I highly disagree with what you said: > The next problem comes when a user has specified both data and method="GET". > This becomes an invalid scenario, but a decision has been to taken as what > should be given preference? That is incorrect, RFC2616 states that the server should ignore the message body when the request method does not define any semantics for it, but there is nothing that makes the inclusion of a message body along with the GET request method invalid. > - As the user has sent "data", should the request be considered a POST? No, absolutely not. Sending data via other request methods, like DELETE or PUT, is semantically correct and should be supported completely if we are going to include a way to set the request method. If I set the method to PUT, and include data, I don’t want the library to override that to POST just because I set data. > - But user specified it as "GET" (intentionally or by mistake), so should the > data not be used and Request should do only a GET? If I data is included and the request method is explicitely set to GET, make a GET request and include the data in the request body. It might not be a semantically good decision to send data over GET, but it still is not disallowed and as such should be possible (for whatever reasons). > - Or should we throw an error? We especially should’t throw an error, as this is not invalid at all. > A person would just send data and forget about changing the method to "POST". I agree that the library should still default to POST if data is included and the request method was not explicitely set (see also below). > 1) should method always have priority or should 'POST' always be used whenever >data is passed? > If data is passed use POST. No, if data is passed and no special method is set, use POST, otherwise use the method the user specified, because that is what he expects. > 2) if the method is e.g. 'GET' and data is passed, should an error be raised? > Nope, give data the priority and do POST. (As urllib is currently doing) Don't give data any priority if the method was set explicitely. Otherwise the ability to set a custom method is totally useless, especially with request methods where a message body is semantically useful (i.e. all other than HEAD and GET). > 3) should Request.method be private? > Not necessarily, it should be public. Depends on the way the method will be set. Looking at the way, the other request parameters are set (especially with the accessors being “deprecated”), it makes sense to leave this public. > 4) should the value of Request.method be initialized in the __init__ or can it >also be None? > My take - It should be initialized to default (GET), instead of None. Initializing it to GET will make the implementation difficult, especially if we want to continue supporting the behaviour of setting the method to POST when data is changed (and the method was not explicitely set). Unless we override the built-in property accessors I don’t think this is possible. > 5) if the value of Request.method is always initialized, should we deprecate >get_method? > This is an interesting question. get_method essentially becomes less useful or > it could serve as an arbiter when data and GET is sent and may be used as > reliable way to get the Request's method. It should not be deprecated. To my understanding, and this is also why I provided the same patch on the duplicate bug, `get_method` is used by the other libraries to get the used request method. Unless we change the other libraries to determine the method in a different way, deprecating `get_method` won’t get us anywhere. What I tried to respect with the patch, and I think this was also Denver’s intention, is to add this functionality without breaking the current behaviour. That behaviour is that GET is default, and POST is set as default if there is any data. The functionality requires that the request method can be set (and the default behaviour can be overriden) without looking at the data (as explained above). Ideally I would probably like to see the functionality of `get_method` done in another library, which performs the request. I.e. check `request.method` and use that if it’s set, otherwise check `request.data` and choose either POST or GET. But again this would require far too many changes in other libraries for this simple change. And again on the `data` property: I think the name “data” is a bit confusing. Request does not provide any encoding details on that “data”, and it is actually just the request body in its original form. What I usually do in my subclass of Request is to provide a way to encode the data I pass to the constructor (often even with multipart encoding for file streams), while the `request.dat
[issue13280] argparse should use the new Formatter class
New submission from Patrick Westerhoff : Hey, according to PEP 3101, the new string.Formatter class is supposed to replace the old string formatting with %. At least that is what I was always thinking. Given that argparse is a Python 3.2+ exclusive module, I think it should make use of that new formatting method. Is there any special reason why that is not the case and the old %-formatting is used? It feels a bit weird to have Python 3 code using only string.Formatter and then have a short section where the old formatter is used – especially when that module was introduced with Python 3.2. -- components: Library (Lib) messages: 146516 nosy: poke priority: normal severity: normal status: open title: argparse should use the new Formatter class type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
New submission from patrick vrijlandt :
This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2
C:\Python32>python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime(1899,12,31).strftime("%y")
The crash happens with %y but not with %Y.
The crash happens with any year < 1900.
On 2.7.2 a ValueError is raised because strftime requires year >= 1900. This is
what IMHO should happen (and would have saved me a lot of time)
--
components: Library (Lib)
messages: 150323
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: crash in datetime.strftime
type: crash
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
patrick vrijlandt added the comment: Is it relevant that 2.7.2 _does_ throw a correct exception? -- ___ Python tracker <http://bugs.python.org/issue13674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
patrick vrijlandt added the comment:
Somewhere in the code is also/still a seperate check concerning strftime:
PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> import datetime
>>> datetime.datetime(-1, 1, 1)
Traceback (most recent call last):
File "", line 1, in
ValueError: year is out of range
>>> datetime.datetime(0, 1, 1)
Traceback (most recent call last):
File "", line 1, in
ValueError: year is out of range
>>> datetime.datetime(1, 1, 1)
datetime.datetime(1, 1, 1, 0, 0)
>>> datetime.datetime(1, 1, 1).strftime("Y")
Traceback (most recent call last):
File "", line 1, in
ValueError: year=1 is before 1000; the datetime strftime() methods require year
>= 1000
>>>
--
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick Westerhoff added the comment: Yeah, I would really like that solution, especially as it separates from the `from X` syntax that sets the exception’s cause. Also I would prefer a syntax solution over a class method simply because the exception context is something that is implicitely set by Python with the `raise` statement. So it would make sense to overwrite that behaviour with a syntax construct as well. -- ___ Python tracker <http://bugs.python.org/issue6210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12321] documentation of ElementTree.find
New submission from patrick vrijlandt : >From the python docs for version 3.2: 19.12.3. ElementTree Objects find(match) [...] Same as getroot().find(match). [...] This is not true: tree.find accepts an absolute path (like "/*") , whereas element.find doesn't. Also applies to findall and findtext. -- components: XML messages: 138228 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: documentation of ElementTree.find type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12322] ElementPath 1.3 expressions documentation
New submission from patrick vrijlandt : Python 3.2 supports ElementPath version 1.3. The relevant documentation is http://effbot.org/zone/element-xpath.htm. It says: .. (New in 1.3) Selects the parent element. However, a CHANGES document says: The engine also provides limited support for the ".." parent operator; you can use it inside the subtree, but it cannot go above the target element (the element you called "find" on). The normal documentation should document the limitation. -- components: XML messages: 138229 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: ElementPath 1.3 expressions documentation type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12323] ElementPath 1.3 expressions
New submission from patrick vrijlandt : >From http://effbot.org/zone/element-xpath.htm: [position] (New in 1.3) Selects all elements that are located at the given position. The position can be either an integer (1 is the first position), the expression “last()” (for the last position), or a position relative to last() (e.g. “last()-1” for the second to last position). This predicate must be preceeded by a tag name. Testing shows, that [0] is accepted, and seems to be [last()]. However [-1] selects no elements. I think these expressions should raise an exception. (Or the feature should be 0-based and behave like python list indices) -- components: XML messages: 138230 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: ElementPath 1.3 expressions type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12323> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12321] documentation of ElementTree.find
patrick vrijlandt added the comment: [...] Same as getroot().find(match). [...] -> [...] For a relative path, this is equivalent to getroot().find(match). Additionally, this form accepts an absolute path. [...] This is easy, but might not be a very good solution. Random thoughts/Points to consider: It does help the novice in debugging his expressions. A peculiarity of this implementation is documented. As others have stated, the whole elementpath documentation within the python docs is incomplete. Should we document the exception but not the rule? It makes no real sense to do a an absolute search from an element. However, it's not ambiguous. lxml does accept the absolute path search from an element. Actually, I think it's up to Fredrik to decide. 2011/6/18 Terry J. Reedy > > Terry J. Reedy added the comment: > > Are you requesting that the doc be changed or the code? > >From the title, I would infer the doc (which is much easier ;-). > If so, can you suggest an actual revised text? > > -- > nosy: +terry.reedy > stage: -> needs patch > versions: +Python 3.3 > > ___ > Python tracker > <http://bugs.python.org/issue12321> > ___ > -- Added file: http://bugs.python.org/file22406/unnamed ___ Python tracker <http://bugs.python.org/issue12321> ___[...] Same as getroot().find(match). [...] ->[...] For a relative path, this is equivalent to getroot().find(match). Additionally, this form accepts an absolute path. [...] This is easy, but might not be a very good solution. Random thoughts/Points to consider: It does help the novice in debugging his expressions. A peculiarity of this implementation is documented. As others have stated, the whole elementpath documentation within the python docs is incomplete. Should we document the exception but not the rule? It makes no real sense to do a an absolute search from an element. However, it's not ambiguous. lxml does accept the absolute path search from an element. Actually, I think it's up to Fredrik to decide. 2011/6/18 Terry J. Reedy <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> Terry J. Reedy <mailto:tjre...@udel.edu";>tjre...@udel.edu> added the comment: Are you requesting that the doc be changed or the code? >From the title, I would infer the doc (which is much easier ;-). If so, can you suggest an actual revised text? -- nosy: +terry.reedy stage:  -> needs patch versions: +Python 3.3 ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue12321"; target="_blank">http://bugs.python.org/issue12321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
New submission from Patrick Strawderman : cStringIO.StringO's seek method has O(n) characteristics in certain, albeit pathological, cases, while the pure Python implementation and cStringIO.StringI's seek methods both execute in constant time in all cases. When the file offset is set n bytes beyond the end of actual data, the gap is filled in with n bytes in cStringIO.StringO's seek method. however, POSIX states that reads of data in the gap will return null bytes only if a subsequent write has taken place, so filling in the gap is not required at the time of the seek. This patch for 2.7 corrects the behavior by unifying StringO and StringI's seek methods, and moving the writing of null bytes to StringO's write method. There may be a more elegant way to write this, I don't know. I believe this issue affects Python 3 as well, though I have yet to test it. NOTE: Perhaps this seems like an extreme edge case not worthy of a fix, but this actually caused problems for us when parsing images with malformed EXIF data; a web request for uploading such a photo was taking on the order of 15 minutes. When we stopped using cStringIO.StringO, it took seconds. -- files: cStringIO.diff keywords: patch messages: 118123 nosy: boogenhagn priority: normal severity: normal status: open title: poor cStringIO.StringO seek performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file19150/cStringIO.diff ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Changes by Patrick Strawderman : -- components: +None type: -> performance ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Changes by Patrick Strawderman : -- components: -None ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Patrick Strawderman added the comment: The second sentence should have said "the gap is filled in with n null bytes" -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Patrick Strawderman added the comment: Fair enough, but there is a great deal of existing code that already uses cStringIO. -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8631] subprocess.Popen.communicate(...) hangs on Windows
Patrick Gansterer added the comment:
I can reproduce this on WinXP with 2.5, 2.7 and 3.2. On my other box (Win7
64bit) the same code works without problems.
This problem happens only when I make a subprocess.call() to executables from
my msysgit installation (e.g. echo, git). A call to 'notepad' or 'svn' works
without problems.
After entering the following python does not respond to any input:
>>> import subprocess
>>> subprocess.call('echo')
--
nosy: +paroga
versions: +Python 2.5, Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue8631>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11784] multiprocessing.Process.join: timeout argument doesn't specify time unit.
New submission from Patrick Sabin : The documentation of multiprocessing.Process.join doesn't tell the user of which time unit the timeout argument is. It seems to be seconds. -- assignee: docs@python components: Documentation files: join-timeout-doc-improvement.patch keywords: patch messages: 133142 nosy: docs@python, pyfex priority: normal severity: normal status: open title: multiprocessing.Process.join: timeout argument doesn't specify time unit. type: behavior Added file: http://bugs.python.org/file21551/join-timeout-doc-improvement.patch ___ Python tracker <http://bugs.python.org/issue11784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
New submission from patrick vrijlandt : Line 154 in standard library's queue.py, in the definition of Queue.put() is: self.unfinished_tasks += 1 This line should be protected by acquiring the all_tasks_done lock. Theoretically, the increment could occur somewhere during task_done()! Additional note: Personally, I would like the increment to occur *before* instead of *after* _put(). This is because I would like to be able to implement a _put() that does not put everything. This put should be able to undo the increment. As it is, calling task_done() from put might decrease the counter to zero inadvertently. -- components: Library (Lib) messages: 135063 nosy: patrick.vrijlandt priority: normal severity: normal status: open title: queue.Queue.put should acquire mutex for unfinished_tasks type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
patrick vrijlandt added the comment: I agree. Please close the ticket. Thanks, Patrick 2011/5/3 Raymond Hettinger > > Raymond Hettinger added the comment: > > > This line should be protected by acquiring the all_tasks_done lock. > > All of three of the condition variables share the same underlying lock. > The increment occurs only with the lock has been acquired. > > > Theoretically, the increment could occur somewhere during task_done()! > > I don't understand what you mean. The semantics of task_done() method > implies that the count gets decremented. > > > Personally, I would like the increment to occur *before* > > instead of *after* _put(). > > There may be some merit to this but I don't see how it matters much since > both occur within the context of the same lock being held. A user defined > method can still add or subtract any number it wants from the unfinished > task count. The result of +1 -5 is the same as -5 +1. > > I'm reluctant to change the order though because the code is already > published and some user's _put code may be inspecting the unfinished tasks > count. I wouldn't want to break that code without good reason. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue11987> > ___ > -- Added file: http://bugs.python.org/file21877/unnamed ___ Python tracker <http://bugs.python.org/issue11987> ___I agree. Please close the ticket.Thanks,Patrick2011/5/3 Raymond Hettinger <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> Raymond Hettinger <mailto:raymond.hettin...@gmail.com";>raymond.hettin...@gmail.com> added the comment: > This line should be protected by acquiring the all_tasks_done lock. All of three of the condition variables share the same underlying lock. Â The increment occurs only with the lock has been acquired. > Theoretically, the increment could occur somewhere during task_done()! I don't understand what you mean. Â The semantics of task_done() method implies that the count gets decremented. > Personally, I would like the increment to occur *before* > instead of *after* _put(). There may be some merit to this but I don't see how it matters much since both occur within the context of the same lock being held. Â A user defined method can still add or subtract any number it wants from the unfinished task count. Â The result of +1 -5 is the same as -5 +1. I'm reluctant to change the order though because the code is already published and some user's _put code may be inspecting the unfinished tasks count. Â I wouldn't want to break that code without good reason. -- ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue11987"; target="_blank">http://bugs.python.org/issue11987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick W. added the comment: Nick Coghlan (ncoghlan) at 2010-12-29 08:46 (UTC): > No, the context must always be included unless explicitly suppressed. Then there should be some actually working way to suppress it, right? I think the standard behaviour that automatically sets the `__context__` of an exception is fine, especially when thinking about exceptions that get raised inside `except` blocks and are not custom made. However there should be some way to suppress the context in some way. Personally, I would prefer if `raise .. from ..` would set the exception's cause, but would *not* automatically print that cause. But then again, it would be a problem to get the cause afterwards when the program terminated because of that exception. So obviously, in such situations, both the cause and the context of a raised exception cannot be used (because both prints out the full trackback). So we obviously need some new mechanism or syntax to ignore the previous exception. As it seems that the cause has a higher precedence than the context (which is fine as the cause is changeable), using `None` as the cause of an exception would be the best solution in my opinion: try: x / y except ZeroDivisionError as e: raise Exception( 'Invalid value for y' ) from None While it might be difficult as the cause is `None` before and gets set to `None` afterwards, Python is totally able to detect that the value was explicitely set to `None`. Either the raise statement should set some internal flag, or the setter for `__cause__` should just check when it is first written to. If that would be too complicated (although it would be possible and very logically to do it like that), maybe a different syntax would work: try: x / y except ZeroDivisionError as e: raise Exception( 'Invalid value for y' ) instead Something like that. -- ___ Python tracker <http://bugs.python.org/issue6210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick W. added the comment: Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC) > We are talking about context, not cause. Yes, but - as said before - obviously the cause takes a higher precedence than context (otherwise it wouldn't show a context message when you explicitely set that). So when *explicitely* setting the cause to `None`, it should use the cause `None` and ignore the context, and as such display nothing. -- ___ Python tracker <http://bugs.python.org/issue6210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8010] tkFileDialog.askopenfiles crashes on Windows 7
New submission from Patrick Holz : When using the function "tkFileDialog.askopenfiles()" on Windows 7 (32-bit) the following error occurs after choosing one or more arbitrary files: Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit(Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import tkFileDialog >>> tkFileDialog.askopenfiles() Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\lib-tk\tkFileDialog.py", line 163, in askopenfiles ofiles.append(open(filename, mode)) IOError: [Errno 2] No such file or directory: u'C' So it seems that the colon after "C" (the drive letter) is wrongly used as a delimiter. The functions "askopenfile" (for a single file to choose) and "askopenfilenames" (to choose only the filenames instead of open the files immediately) don't seem to be affected, furthermore the error doesn't occur on Linux or WinXP. -- components: Tkinter messages: 100020 nosy: Patrick.Holz severity: normal status: open title: tkFileDialog.askopenfiles crashes on Windows 7 type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8230] Lib/test/sortperf.py fails to run
New submission from Patrick Sabin : There is a test file Lib/test/sortperf.py, which isn't properly updated to python3, because it considers map and range returning a list instead of an iterator and therefore throwing an exception when run. I have attached a patch to fix it. -- components: Tests files: sortperf.diff keywords: patch messages: 101693 nosy: pyfex severity: normal status: open title: Lib/test/sortperf.py fails to run versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file16643/sortperf.diff ___ Python tracker <http://bugs.python.org/issue8230> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8277] ElementTree won't parse comments
New submission from Patrick W. : When using xml.etree.ElementTree to parse external XML files, all XML comments within that file are being stripped out. I guess that happens because there is no comment handler in the expat parser. Example: test.xml test.py --- from xml.etree import ElementTree with open( 'test.xml', 'r' ) as f: xml = ElementTree.parse( f ) ElementTree.dump( xml ) Result -- -- components: XML messages: 102051 nosy: poke severity: normal status: open title: ElementTree won't parse comments type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue8277> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8277] ElementTree won't parse comments
Patrick W. added the comment:
Thanks for your reply, Amaury. That page really might mean that it was not
intended for ElementTree to parse such things by default. Although it might be
nice if there was some easy way to simply enable it, instead of having to hack
it into there and depending on details of some internal code (which might
change in the future).
Your code btw. didn't work for me, but based on it and on that effbot page, I
came up with the following solution, which works fine.
test.py
---
from xml.etree import ElementTree
class CommentedTreeBuilder ( ElementTree.XMLTreeBuilder ):
def __init__ ( self, html = 0, target = None ):
ElementTree.XMLTreeBuilder.__init__( self, html, target )
self._parser.CommentHandler = self.handle_comment
def handle_comment ( self, data ):
self._target.start( ElementTree.Comment, {} )
self._target.data( data )
self._target.end( ElementTree.Comment )
with open( 'test.xml', 'r' ) as f:
xml = ElementTree.parse( f, parser = CommentedTreeBuilder() )
ElementTree.dump( xml )
--
___
Python tracker
<http://bugs.python.org/issue8277>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8546] The parameter buffering in _pyio.open doesn't work the same as in the builtin open
New submission from Patrick Sabin : As far as I understand the _pyio.open function should resemble the builtin open, but in case of the buffering parameter, it doesn't. The builtin version doesn't allow None as argument, but this is the default in the _pyio.open signature. I attached a patch, which changes the default value of the buffering parameter to -1, which is the default in the builtin version. -- assignee: d...@python components: Documentation, Library (Lib) files: change_pyio_open_buffering_parameter.diff keywords: patch messages: 104301 nosy: d...@python, pyfex priority: normal severity: normal status: open title: The parameter buffering in _pyio.open doesn't work the same as in the builtin open type: behavior versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17103/change_pyio_open_buffering_parameter.diff ___ Python tracker <http://bugs.python.org/issue8546> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1861] sched scheduler.queue class member is unordered
New submission from Patrick Bureau: In Python 2.4, retrieving sched's scheduler.queue class member would return a time ordered list of events as expected. Since Python 2.5, the same operation retrieves a list of unordered scheduled events. This makes it difficult to know which events are really next in queue, especially if scheduled at the same time. -- components: Library (Lib) messages: 60033 nosy: pbureau severity: minor status: open title: sched scheduler.queue class member is unordered type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1861> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1861] sched scheduler.queue class member is unordered
Patrick Bureau added the comment: Indeed, the queue is not directly exposed by a method, but the information is nonetheless interesting for monitoring the content. If it's not a bug, then maybe this could be changed to a feature request for a new method to retrieve the queue's events. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1861> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5063] python-2.6.spec doesn't build properly
New submission from Patrick Toal : Attempting to build an RPM with the python-2.6.spec contained in the python-2.6.1 distribution tar fails. The following diff's enabled me to cleanly build the rpm's on a standard CentOS 5.1 installation. -- components: Build files: python-2.6.1.spec.diff keywords: patch messages: 80558 nosy: ptoal severity: normal status: open title: python-2.6.spec doesn't build properly type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file12863/python-2.6.1.spec.diff ___ Python tracker <http://bugs.python.org/issue5063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
New submission from Patrick Gerken : When running the command install_lib, the command build_clib is not run. If a package contains clibs they can be dependencies for extension libs, at least that is stated in the module docstring of build_clib. In real life you can see it when trying to run the command install_lib on the current reportlab2.3. The patch provided needs do be applied in the distutils dir directly with patch install_lib.py dependency.patch As requested, I asked on the mailing list first, whether this really is a bug. http://mail.python.org/pipermail/distutils-sig/2009-February/010974.html I am half finished writing a test case, that I'll append to this ticket later. -- assignee: tarek components: Distutils files: dependency.patch keywords: patch messages: 81892 nosy: do3cc, tarek severity: normal status: open title: Missing dependency in distutils build type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file13064/dependency.patch ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Patrick Gerken added the comment: The attached test works breaks without the patch and passes with the patch. I am not sure whether the test itself is written following best practice. I would be more than happy for a review, with hints what should be done better. Added file: http://bugs.python.org/file13103/test_install_lib.py ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
New submission from Patrick Reader : I would like to be able to use a `yield from` expression in a `return` statement without parentheses, as a small quality of life tweak, i.e.: return yield from gen instead of return (yield from gen) I think this makes sense, since `yield from` can be used on the right-hand-side of an assignment, which accepts any expression, and so should `return`. Here is a medium-sized real-world example of where I'm using this, where it would be nice to allow `return yield from`: https://gist.github.com/pxeger/48f97484364bf0b43dee974a8f0f4265 -- components: Parser messages: 416198 nosy: lys.nikolaou, pablogsal, pxeger priority: normal severity: normal status: open title: Allow `return yield from` type: enhancement ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
Patrick Reader added the comment: Ok, will do, but what is the bar for a feature to need to go to the mailing lists first? I thought as this was a relatively minor one it wouldn't need to. Is it just because it's an actual syntax change? -- ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
Patrick Reader added the comment: As the one who wrote the code, I can guarantee you that the StopIteration value is not always None. But I understand your point that for most other users it is always None, and therefore having special syntax might be misleading. -- ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38171] super() is passing wrong parameters while handling diamond inheritance
New submission from Patrick Monnerat : Running the attached program outputs: top.__init__(<__main__.top object at 0x7fc1dea24048>,) called i1.__init__(<__main__.top object at 0x7fc1dea24048>, 'arg from top') called i2.__init__(<__main__.top object at 0x7fc1dea24048>, 'arg from i1') called base.__init__(<__main__.top object at 0x7fc1dea24048>, 'arg from i2') called base.__init__ returns None i2.__init__ returns None i1.__init__ returns None top.__init__ returns None i2.__init__() argument is wrong: since it is is not a parent class of i1, it should be "arg from top". I can understand i2.__init__() is called after i1.__init__() and before base.__init__() but arguments given to super(i1, self).__init__() should not be substituted for calling i2.__init__(). -- files: super.py messages: 352429 nosy: monnerat priority: normal severity: normal status: open title: super() is passing wrong parameters while handling diamond inheritance type: behavior Added file: https://bugs.python.org/file48608/super.py ___ Python tracker <https://bugs.python.org/issue38171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38717] csv DictWriter's internal _dict_to_list raise error unsupported operand
New submission from Patrick Schneeweiß :
I switched over to Python 3.7 and still using my csv DictWriter.
No I'm receiving an error when calling the writerow() method.
unsupported operand type(s) for -: 'list' and 'list'
Digging deeped in the problem I found out, that the internal
_dict_to_list(self, rowdict) method works different compared to Python 2.7
It tries to substract the fieldnames list and the keys of the dict to find keys
not included.
But substracting lists is not possible. As a workaround I defined the
Dictwriter with the option extrasaction="ignore".
I would be better to use the method like in Python 2.7. I will output my
versions of the method:
Python 3.7:
def _dict_to_list(self, rowdict):
if self.extrasaction == "raise":
wrong_fields = rowdict.keys() - self.fieldnames
if wrong_fields:
raise ValueError("dict contains fields not in fieldnames: "
+ ", ".join([repr(x) for x in wrong_fields]))
return (rowdict.get(key, self.restval) for key in self.fieldnames)
Python 2.7:
def _dict_to_list(self, rowdict):
if self.extrasaction == "raise":
wrong_fields = [k for k in rowdict if k not in self.fieldnames]
if wrong_fields:
raise ValueError("dict contains fields not in fieldnames: "
+ ", ".join([repr(x) for x in wrong_fields]))
return [rowdict.get(key, self.restval) for key in self.fieldnames]
--
components: Library (Lib)
messages: 356110
nosy: afflictor
priority: normal
severity: normal
status: open
title: csv DictWriter's internal _dict_to_list raise error unsupported operand
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue38717>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38717] csv DictWriter's internal _dict_to_list raise error unsupported operand
Patrick Schneeweiß added the comment:
Hello all,
This is my dict:
{'rule': 'WAN-2-Web|unknown (Barracuda Networks CloudGen Firewall)', 'April
(2018)': '', 'May (2018)': '', 'June (2018)': '', 'July (2018)': '', 'August
(2018)': '', 'April (2019)': '', 'May (2019)': '14', 'June (2019)': '', 'July
(2019)': '', 'August (2019)': ''}
And this was my fieldnames list:
['rule', 'April (2018)', 'May (2018)', 'June (2018)', 'July (2018)', 'August
(2018)', 'April (2019)', 'May (2019)', 'June (2019)', 'July (2019)', 'August
(2019)']
when I call the keys Method on this dict, I receive this:
dict_keys(['rule', 'April (2018)', 'May (2018)', 'June (2018)', 'July (2018)',
'August (2018)', 'April (2019)', 'May (2019)', 'June (2019)', 'July (2019)',
'August (2019)'])
--
___
Python tracker
<https://bugs.python.org/issue38717>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38717] csv DictWriter's internal _dict_to_list raise error unsupported operand
Patrick Schneeweiß added the comment: Ok in a new sample Script it is working. As I used my normal script in a software called Splunk, I saw they are using a custom class OrderedDict. I will take a look on this first. -- ___ Python tracker <https://bugs.python.org/issue38717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38717] csv DictWriter's internal _dict_to_list raise error unsupported operand
Patrick Schneeweiß added the comment: Sorry guys, it was an issue with the cusotm Splunk Library. They treated the keys Method a little different. Thanks all for the hints. Will close this -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43480] Add .path method/property to tempfile.* for a pathlib.Path
New submission from Patrick Reader : It would be nice to have a `.path` method or property on `tempfile.NamedTemporaryFile`, `tempfile.TemporaryDirectory` which produces a `pathlib.Path` of their `.name` attribute, so one can use the modern interface directly. I think a method would be more appropriate than a property because you're explicitly allocating a new object (unless you use `@functools.cached_property` or similar to have a shared object between successive calls) I can do a PR. -- components: Library (Lib) messages: 388540 nosy: pxeger priority: normal severity: normal status: open title: Add .path method/property to tempfile.* for a pathlib.Path type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43649] time.strftime('%z') doesn't return UTC offset in the form ±HHMM
New submission from Patrick Storz :
This is a follow-up to https://bugs.python.org/issue20010
I'm seeing this very issue in a recent gcc build of Python 3.8
(mingw-w64-x86_64-python 3.8.8-2 from MSYS2 project):
Python 3.8.8 (default, Feb 20 2021, 07:16:03) [GCC 10.2.0 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%z', time.localtime(time.time()))
'Mitteleuropäische Sommerzeit'
>>> time.strftime('%Z', time.localtime(time.time()))
'Mitteleuropäische Sommerzeit'
If this is indeed fixed in MSVCRT, it seems behavior is still not guaranteed
when compiling with mingw-w64 gcc.
--
components: Library (Lib), Windows
messages: 389641
nosy: Aaron.Meurer, Ede123, Václav Dvořák, civalin, docs@python, eryksun,
ezio.melotti, kepkin, martin-t, paul.moore, r.david.murray, steve.dower,
tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: time.strftime('%z') doesn't return UTC offset in the form ±HHMM
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43649>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43649] time.strftime('%z') doesn't return UTC offset in the form ±HHMM
Change by Patrick Storz : ___ Python tracker <https://bugs.python.org/issue43649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
New submission from Patrick Melix :
While trying to fix window behaviour in a python project (ASE:
https://wiki.fysik.dtu.dk/ase/), I came across this problem:
Tkinter does not set the _NET_WM_WINDOW_TYPE when using the FileDialog class or
it's derivatives. I could not find a reason for this and it leads to my window
manager (i3) not automatically recognising the window as a dialogue (and thus
not enabling floating). I think the window types are there exactly for that
purpose, so I don't see why not to set this as the default for the FileDialog
class.
I was able to change this by adding the line
```self.top.wm_attributes('-type', 'dialog')```
to the initialization of the FileDialog class. See also MR on GitHub.
Since I am an absolute beginner at this please do forgive if I missed something.
--
components: Tkinter
messages: 389676
nosy: patrickmelix
priority: normal
severity: normal
status: open
title: Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43655>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
Change by Patrick Melix : -- keywords: +patch pull_requests: +23810 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25061 ___ Python tracker <https://bugs.python.org/issue43655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43655] Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
Patrick Melix added the comment: Thank you for your feedback Serhiy! I obviously totally forgot about compatibility issues with other OS... If you are already aware of this and working on a solution even better. Did I miss this during my search or is it not public anywhere yet? For now one can easily avoid the issue by always setting the type manually, will have to see how to avoid the OS issue you mention then. Perhaps you can point me to the place to watch for your progress on the matter so I can keep track of this? Thanks again! -- ___ Python tracker <https://bugs.python.org/issue43655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43726] regex module fails with a quantified backref but succeeds with repeated backref
Patrick Reader added the comment: The `regex` module is a third-party package, not part of the Python standard library. Please report issues here: https://bitbucket.org/mrabarnett/mrab-regex/issues -- nosy: +pxeger ___ Python tracker <https://bugs.python.org/issue43726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Patrick Reader added the comment: I would like to note that syntax like this is in heavy use in the Code Golf community (a sport in which the aim is to write the shortest code possible to complete a particular task). It will be disappointing if it becomes an error and break many past programs (you can search for phrases like `1and`, `0for` on https://codegolf.stackexchange.com/search?q=0for for examples). I could understand if this change remains because code golf is not exactly an important thing with serious ramifications, but I think it should be taken in to consideration as a use-case nonetheless. -- nosy: +pxeger ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
New submission from Patrick Reader :
When a frame's __builtins__ is a subclass of dict with an overridden
__getitem__ method, this overriden method is not used by the IMPORT_NAME
instruction to lookup __import__ in the dictionary; it uses the lookup function
of normal dictionaries (via _PyDict_GetItemIdWithError). This is contrary to
the behaviour of the similar LOAD_BUILD_CLASS, as well as the typical name
lookup semantics of LOAD_GLOBAL/LOAD_NAME, which all use PyDict_CheckExact for
a "fast path" before defaulting to PyObject_GetItem, which is not the behaviour
I expected.
Perhaps more seriously, if __builtins__ is not a dict at all, then it gets
erroneously passed to some internal dict functions resulting in a mysterious
SystemError ("Objects/dictobject.c:1440: bad argument to internal function")
which, to me, indicates fragile behaviour that isn't supposed to happen.
Could this be changed, so that __builtins__ is used dynamically? I understand
this is a highly specific use case and changing it would probably cause a bit
of a slow-down in module importing so is perhaps not worth doing, but I've
posted this issue to track it anyway.
I cannot find evidence that this behaviour has changed at all in recent history
and it seems to be the same on the main branch as in 3.9.6.
Per a brief discussion with Brett Cannon on python-dev
(https://mail.python.org/archives/list/python-...@python.org/thread/ZQMF6XC76J4APJPB3X6PGATG6CV5NN44/),
I have labelled this a feature request because it has never really been
expected behaviour.
A short demo of these things is attached.
Links to relevant CPython code in v3.9.6:
IMPORT_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L5179
BUILD_CLASS: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2316
LOAD_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2488
LOAD_GLOBAL: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2546
--
components: Interpreter Core
files: dict_lookup_demo.py
messages: 397531
nosy: brett.cannon, pxeger
priority: normal
severity: normal
status: open
title: importing does not dispatch to __builtins__.__getitem__ to lookup
__import__
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50151/dict_lookup_demo.py
___
Python tracker
<https://bugs.python.org/issue44643>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: It may be, but in that case, why do LOAD_BUILD_CLASS and things still use it? -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: Similarly, when passing a subclass of dict to exec or eval as the locals or globals, all other instructions dispatch to the correct __getitem__ method. I'm pretty sure that's not CPython-private -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: Ok what I meant was, why does constructing a class use it when it looks up __build_class__ then? -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42167] Documentation for SETUP_WITH opcode is wrong
Patrick Reader added the comment: It was, at least partially, replaced by BEGIN_WITH for bpo-40222: https://github.com/python/cpython/commit/adcd2205565f91c6719f4141ab4e1da6d7086126#diff-eaa488fc50d23b30ca8b24ab19e9c91c1c941339847af993e908f006eec0653bL741 -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue42167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44845] Allow keyword arguments in code.__new__
New submission from Patrick Reader : Per bpo-41263, code.__new__ now uses Argument Clinic. However, it still has a / marker which prevents the use of keyword arguments (https://github.com/python/cpython/pull/21426/files#diff-6f869eb8beb7cbe4bc6817584b99ad567f88962fa67f7beca25d009dc401234dR465). It seems entirely unnecessary to have this, so could it be removed to allow easier construction of code objects from user code, or is it there for some specific reason? I can do a PR - it's a 1 line change (+ clinic output changes) (+ tests?). I don't imagine backwards-compatibility is a concern here given it's implementation-specific and basically private. Note that prior to that fix, keyword arguments were allowed in the constructor but completely ignored. -- components: Interpreter Core messages: 399034 nosy: pxeger priority: normal severity: normal status: open title: Allow keyword arguments in code.__new__ type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29921] datetime validation is stricter in 3.6.1 than previous versions
Patrick Decat added the comment: pywin32 project has moved from sourceforge to github. https://sourceforge.net/p/pywin32/bugs/748/ is now at https://github.com/mhammond/pywin32/issues/748 pywin32 issue is supposed to be resolved since pywin32 b222 See: https://github.com/mhammond/pywin32/issues/748#issuecomment-359223029 https://github.com/mhammond/pywin32/commit/07202650d21e8fa7f3053ff1d4665363315cefce https://github.com/mhammond/pywin32/blob/b222/CHANGES.txt#L24-L26 -- nosy: +Patrick Decat ___ Python tracker <https://bugs.python.org/issue29921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45352] Move documentation for typed generic forms of standard collections to collections.abc
New submission from Patrick Reader : Currently the documentation for the generic forms (e.g. what the parameters in square brackets mean) of standard collections (e.g. collections.abc.Generator), is still on the typing page (https://docs.python.org/3.10/library/typing.html#typing.Generator). This is from before PEP 585 was implemented, which deprecated the ones in typing in favour of the aliases in collections.abc. The documentation for these should be moved, or at least linked to, in the collections.abc page. The same applies to builtin types like list which can now also be directly parameterised. In the case of Generator, for example, the text at https://docs.python.org/3.10/library/typing.html#typing.Generator, "A generator can be annotated...", should be moved to https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Generator. I chose Generator as an example, because it has three parameters YieldType, SendType, ReturnType whose order I can't remember and need to look up. For some types, such as Iterable, the meaning of the parameter is quite straightforward, so little documentation is needed (so https://docs.python.org/3.10/library/typing.html#typing.Iterable just says "A generic form of https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Iterable";), but there should still be a note on the collections.abc page that it can be parameterised. Perhaps there should also be a message saying "new in version 3.9: this can now be parameterised" on each ABC collection. I can see that it might not be desirable to have this information scattered across other pages, because it is fundamentally about typing and pretty unrelated to builtin documentation, so it may be preferable to just link to the typing page rather than move the text. But since the old generics are deprecated, if they are removed, the documentation must be preserved. -- assignee: docs@python components: Documentation messages: 403085 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Move documentation for typed generic forms of standard collections to collections.abc type: enhancement ___ Python tracker <https://bugs.python.org/issue45352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42066] CookieJar cookies should not be sorted
Change by Patrick Decat : -- nosy: +Patrick Decat ___ Python tracker <https://bugs.python.org/issue42066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45836] unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size (Python 3.9)
New submission from Patrick Bourke : Hi all, Forgive me if this is not the correct way to report this, but we have run into the issue from #29620 ( https://bugs.python.org/issue29620 ) on Python 3.9. The fix appears to be present in the tip of 3.8: https://github.com/python/cpython/blob/c37a0d9c0ae4aa0d9135fac9a58afc7b34ff71d6/Lib/unittest/case.py#L254 and 3.10: https://github.com/python/cpython/blob/0ef308a2890571c850c624fb99ac00f8951363c6/Lib/unittest/case.py#L255 but missing from 3.9: https://github.com/python/cpython/blob/0ef308a2890571c850c624fb99ac00f8951363c6/Lib/unittest/case.py#L255 Here is our test case: import unittest import graspologic class MyTestCase(unittest.TestCase): def test_something(self): with self.assertWarns(UserWarning): pass if __name__ == '__main__': unittest.main() fails with: == ERROR: test_something (__main__.MyTestCase) -- Traceback (most recent call last): File "C:\Users\pbourke\AppData\Roaming\JetBrains\PyCharm2021.2\scratches\test.py", line 7, in test_something with self.assertWarns(UserWarning): File "C:\Users\pbourke\.pyenv\pyenv-win\versions\3.9.7\lib\unittest\case.py", line 255, in __enter__ for v in sys.modules.values(): RuntimeError: dictionary changed size during iteration The module triggering the error appears to be IPython.utils.io, which is included somewhere in our dependencies. My CPython is: Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] -- components: Library (Lib) messages: 406516 nosy: pbourke priority: normal severity: normal status: open title: unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size (Python 3.9) type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not
Patrick Yang added the comment: I ended up in this issue after I learnt the following from the Python Library Reference Manual. float(..). For a general Python object x, float(x) delegates to x.__float__(). If __float__() is not defined then it falls back to __index__(). The discussion on __int__() and __index__() was very interesting but I still didn't get the answer I wanted. If __int__() is assumed to be a possibly approximate conversion and it's possible that __int__() may exist while __index__() doesn't, shouldn't __int__() be used as a fall back before __index__()? The downside would be that the resulting float may not be "very close" to the original object because __int__() is only an approximation while __index__() guarantees exact, but loss of precision is acceptable during type conversion, isn't it? (i.e. int(3.14) -> 3). Perhaps it's not acceptable if the conversion is a widening conversion and that's why __int__() is skipped? -- nosy: +patrick.yang.1248 ___ Python tracker <https://bugs.python.org/issue20092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44845] Allow keyword arguments in code.__new__
Change by Patrick Reader : -- nosy: -terry.reedy ___ Python tracker <https://bugs.python.org/issue44845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39098] OSError: handle is closed in ProcessPoolExecutor on shutdown(wait=False)
New submission from Patrick Buxton : When shutting down a ProcessPoolExecutor with wait=False, an `OSError: handle is closed` is raised. The error can be replicated with a script as simple as: ``` from concurrent.futures import ProcessPoolExecutor e = ProcessPoolExecutor() e.submit(id) e.shutdown(wait=False) -- components: Library (Lib) messages: 358679 nosy: patbuxton priority: normal severity: normal status: open title: OSError: handle is closed in ProcessPoolExecutor on shutdown(wait=False) type: crash versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39147] using zipfile with root privilege shows FileNotFoundError
New submission from Patrick Liu :
When I run the python script with root privilege, it can clone the repo
successfully but with the error message as follow.
However, it runs correctly with normal user.
Why it cannot find the html file? Thanks.
Python 3.7.4 (default, Aug 13 2019, 20:35:49)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from git_clone import git_clone
>>> git_clone('https://github.com/android9527/android9527.github.io')
13472.0 KB, 13574 KB/s, 0.99 seconds passed Traceback (most recent call
last):
File "", line 1, in
File "/root/anaconda3/lib/python3.7/site-packages/git_clone/git_clone.py",
line 53, in git_clone
f.extractall(path + '/.')
File "/root/anaconda3/lib/python3.7/zipfile.py", line 1619, in extractall
self._extract_member(zipinfo, path, pwd)
File "/root/anaconda3/lib/python3.7/zipfile.py", line 1673, in _extract_member
open(targetpath, "wb") as target:
FileNotFoundError: [Errno 2] No such file or directory:
'/mnt/fit-Knowledgezoo/test/android9527.github.io-master/2019/01/24/2019-01-24-Java
重入锁 synchronized /index.html'
>>> exit()
--
messages: 358937
nosy: Patrick Liu
priority: normal
severity: normal
status: open
title: using zipfile with root privilege shows FileNotFoundError
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39147>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39104] ProcessPoolExecutor hangs on shutdown nowait with pickling failure
Patrick Buxton added the comment: Added core developer to get some feedback -- nosy: +patbuxton, pitrou ___ Python tracker <https://bugs.python.org/issue39104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39104] ProcessPoolExecutor hangs on shutdown nowait with pickling failure
Change by Patrick Buxton : -- nosy: +bquinlan ___ Python tracker <https://bugs.python.org/issue39104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39098] OSError: handle closed, ProcessPoolExecutor shutdown(wait=False)
Patrick Buxton added the comment: This should be fixed with https://github.com/python/cpython/pull/17670 for https://bugs.python.org/issue39104, but only for version 3.9 as no backport!! -- ___ Python tracker <https://bugs.python.org/issue39098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40439] Error in an external reference
New submission from Patrick A. : This URL doesn't exist anymore. If you click on this URL you have a 404 not found. https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html The website was changed and Dr. Martin v. Löwis is not hosted on the new site. Regards -- assignee: docs@python components: Documentation messages: 367665 nosy: audpa31, docs@python priority: normal severity: normal status: open title: Error in an external reference versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)
Patrick Thizy added the comment: I use Apache + mod_wsgi on Windows When I update from Django 2.2.4 to Django 2.2.5, this fix has been apply With this fix my application is not running The navigator is lock and waiting Can you help me ? -- nosy: +Patrick Thizy ___ Python tracker <https://bugs.python.org/issue36284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41781] Typos in typing.py
Patrick Reader added the comment: Maybe I added myself by accident while reading the code. Anyway, thanks and you're welcome -- ___ Python tracker <https://bugs.python.org/issue41781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler
New submission from Patrick Reader :
When unpacking a collection or string literal inside another literal, the
compiler should optimise the unpacking away and store the resultant collection
simply as another constant tuple, so that `[*'123', '4', '5']` is the exact
same as `['1', '2', '3', '4', '5']`.
Compare:
```
>>> dis.dis("[*'123', '4', '5']")
1 0 BUILD_LIST 0
2 BUILD_LIST 0
4 LOAD_CONST 0 ('123')
6 LIST_EXTEND 1
8 LIST_EXTEND 1
10 LOAD_CONST 1 ('4')
12 LIST_APPEND 1
14 LOAD_CONST 2 ('5')
16 LIST_APPEND 1
```
vs.
```
>>> dis.dis("['1', '2', '3', '4', '5']")
1 0 BUILD_LIST 0
2 LOAD_CONST 0 (('1', '2', '3', '4', '5'))
4 LIST_EXTEND 1
```
and `timeit` shows the latter to be over 3 times as fast.
For example, when generating a list of characters, it is easier and more
readable to do `alphabet = [*"abcde"]` instead of `alphabet = ["a", "b", "c",
"d", "e"]`. The programmer can do what is most obvious without worrying about
performance, because the compiler can do it itself.
--
components: Interpreter Core
messages: 383837
nosy: pxeger
priority: normal
severity: normal
status: open
title: Unpacking of literals inside other literals should be optimised away by
the compiler
___
Python tracker
<https://bugs.python.org/issue42754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler
Change by Patrick Reader : -- type: -> performance ___ Python tracker <https://bugs.python.org/issue42754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42948] bytearray.copy is undocumented
Patrick Haller added the comment: You will see this on every bytes and bytearray type as the behaviour described is the same for both. -- nosy: +HallerPatrick ___ Python tracker <https://bugs.python.org/issue42948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42948] bytearray.copy is undocumented
Patrick Haller added the comment: Terry, I am sorry. You are of course right. I was somehow looking at count not copy. -- ___ Python tracker <https://bugs.python.org/issue42948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41010] email.message.EmailMessage.get_body
New submission from patrick totzke :
I am trying to use EmailMessage.get_body() on the attached spam email.
Although that message may be malformed, I believe that this method should fail
gracefully.
To reproduce
```
with open('msg', 'rb') as f:
m = email.message_from_binary_file(f, _class=email.message.EmailMessage)
m.get_body()
---
AttributeErrorTraceback (most recent call last)
in
> 1 m.get_body()
/usr/lib/python3.8/email/message.py in get_body(self, preferencelist)
1016 best_prio = len(preferencelist)
1017 body = None
-> 1018 for prio, part in self._find_body(self, preferencelist):
1019 if prio < best_prio:
1020 best_prio = prio
/usr/lib/python3.8/email/message.py in _find_body(self, part, preferencelist)
987 if subtype != 'related':
988 for subpart in part.iter_parts():
--> 989 yield from self._find_body(subpart, preferencelist)
990 return
991 if 'related' in preferencelist:
/usr/lib/python3.8/email/message.py in _find_body(self, part, preferencelist)
987 if subtype != 'related':
988 for subpart in part.iter_parts():
--> 989 yield from self._find_body(subpart, preferencelist)
990 return
991 if 'related' in preferencelist:
/usr/lib/python3.8/email/message.py in _find_body(self, part, preferencelist)
976
977 def _find_body(self, part, preferencelist):
--> 978 if part.is_attachment():
979 return
980 maintype, subtype = part.get_content_type().split('/')
AttributeError: 'str' object has no attribute 'is_attachment'
```
I am on Python 3.8.3 on debian testing.
--
components: Library (Lib)
files: msg
messages: 371755
nosy: patrick totzke
priority: normal
severity: normal
status: open
title: email.message.EmailMessage.get_body
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file49241/msg
___
Python tracker
<https://bugs.python.org/issue41010>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
New submission from Patrick Reader : Since 10.12 (Sierra, released in 2016), macOS is no longer called OS X. References to macOS in the documentation should be updated to reflect this. This is now especially important because macOS 11 (Big Sur) is now in preview, and the X meaning 10 in roman numerals is now completely incorrect (not just the wrong name). -- assignee: docs@python components: Documentation messages: 372951 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Replace references to OS X in documentation with macOS type: behavior ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Patrick Reader added the comment: I'm working on it -- ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Patrick Reader added the comment: While I'm at it, should I change "Macintosh" to "Mac"? -- ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Change by Patrick Reader : -- keywords: +patch pull_requests: +20468 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21316 ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41781] Typos in typing.py
New submission from Patrick Reader : In typing.py, the `_allow_reckless_class_cheks` function is spelt wrong, and there is also a typo `instnance` in its docstring. I can do a PR but I thought I'd open an issue since it might be considered a breaking change (although it is `_private` so maybe not?) https://github.com/python/cpython/blob/1b4552c5e8e925f24c15f707050f22c977171125/Lib/typing.py#L1037 -- components: Library (Lib) messages: 376877 nosy: pxeger priority: normal severity: normal status: open title: Typos in typing.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41792] No (public) way to dynamically introspect if an annotation is a TypedDict
New submission from Patrick Reader : See https://github.com/python/typing/issues/751 -- components: Library (Lib) messages: 376931 nosy: pxeger priority: normal severity: normal status: open title: No (public) way to dynamically introspect if an annotation is a TypedDict ___ Python tracker <https://bugs.python.org/issue41792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41792] No (public) way to dynamically introspect if an annotation is a TypedDict
Change by Patrick Reader : -- keywords: +patch pull_requests: +21309 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22254 ___ Python tracker <https://bugs.python.org/issue41792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41805] types.GenericAlias and types.Union have no documentation
New submission from Patrick Reader : See title. For reference: `GenericAlias` was added by Guido van Rossum in commit 48b069a003ba6c684a9ba78493fbbec5e89f10b8 "bpo-39481: Implementation for [PEP 585](https://www.python.org/dev/peps/pep-0585/) (#18239)" `Union` was added by Maggi Moss in commit 1b4552c5e8e925f24c15f707050f22c977171125 "bpo-41428: Implementation for [PEP 604](https://www.python.org/dev/peps/pep-0604/) (GH-21515)" I can do a PR which would need backporting (is that the right word?) to 3.9 at least for `GenericAlias`. -- assignee: docs@python components: Documentation messages: 377064 nosy: docs@python, pxeger priority: normal severity: normal status: open title: types.GenericAlias and types.Union have no documentation versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41805] types.GenericAlias and types.Union have no documentation
Patrick Reader added the comment: Sorry, I'd completely forgotten about doing a PR for this. Go ahead! -- ___ Python tracker <https://bugs.python.org/issue41805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41996] Should `make install` still install to /usr/bin/python3?
New submission from Patrick Reader : Since Python 2 is now finally gone, should the Python executable not be installed to simply `/usr/bin/python` rather than `/usr/bin/python3` when running `make install`? -- components: Installation messages: 378387 nosy: pxeger priority: normal severity: normal status: open title: Should `make install` still install to /usr/bin/python3? type: enhancement ___ Python tracker <https://bugs.python.org/issue41996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41997] Docs Standard Library index page has incorrect version in title
New submission from Patrick Reader : The documentation page for the Standard Library, https://docs.python.org/3/library/, still says "Python 3.8.6 documentation" in the title. When visiting https://docs.python.org/3.9/library/ (emphasis on the 3.9) explicitly, the correct title is shown. I suspect there are other pages like this, perhaps ones that have not been modified since Python 3.8.6? This is possibly in fact some sort of bug in Sphinx, but I don't think so. -- assignee: docs@python components: Documentation messages: 378394 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Docs Standard Library index page has incorrect version in title versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41997] Docs Standard Library index page has incorrect version in title
[issue42167] Documentation for SETUP_WITH opcode is wrong
New submission from Patrick Reader : bpo-33387 introduced two new opcodes, `RERAISE` and `WITH_EXCEPT_START` (previously called `WITH_EXCEPT_FINISH`), replacing the previous `WITH_CLEANUP_START`, `WITH_CLEANUP_FINISH`, `BEGIN_FINALLY`, `END_FINALLY`, `CALL_FINALLY` and `POP_FINALLY`. The [documentation](https://docs.python.org/3.9/library/dis.html#opcode-SETUP_WITH) for it references the since removed `WITH_CLEANUP_START`, which is definitely wrong. I don't know enough to be able to fix it though, sorry, so I've added the core team. -- assignee: docs@python components: Documentation, Interpreter Core messages: 379749 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Documentation for SETUP_WITH opcode is wrong versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
New submission from patrick vrijlandt :
PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> import os
>>> os.makedirs("g:/a/b/c")
>>> os.listdir("g:/a")
['b']
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... print(root, dirs, files, os.listdir(root))
... os.rmdir(root)
...
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] []
>>>
>From the documentation of os.walk:
If topdown is False, the triple for a directory is generated after the triples
for all of its subdirectories (directories are generated bottom-up).
As the above example shows, the directories are generated in the correct order,
"generated" referring to yield from generator os.walk. However, the generated
(files? and) dirs do not necessarily reflect the current situation as produced
by os.listdir.
Therefore, this does not clear the entire directory tree as I would expect.
>>> os.makedirs("g:/a/b/c")
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... print(root, dirs, files, os.listdir(root))
... if not (files + dirs):
... os.rmdir(root)
...
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] ['b']
I think that at least the documentation should be more clear on this issue. I
would like even better, if files + dirs would match os.listdir on the moment
they are generated (=yielded).
--
assignee: docs@python
components: Documentation
messages: 151169
nosy: docs@python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: os.walk: bottom-up
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13779>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13784] Documentation of xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber()
New submission from patrick vrijlandt :
Problem:
Locator methods return the location where the event starts, not where it ends.
Locator line numbers start at 1, Locator column numbers can be 0.
Proposal:
Adapt documentation.
>From the docs:
Instances of Locator provide these methods:
Locator.getColumnNumber()
Return the column number where the current event ends.
Locator.getLineNumber()
Return the line number where the current event ends
My Test:
import xml.sax
data = b"""
"""
class MyHandler(xml.sax.handler.ContentHandler):
def startElement(self, name, attrs):
if name == "sub":
print("open", name, self._locator.getLineNumber(),
self._locator.getColumnNumber())
def endElement(self, name):
if name == "sub":
print("close", name, self._locator.getLineNumber(),
self._locator.getColumnNumber())
xml.sax.parseString(data, MyHandler())
Output:
open sub 2 4
close sub 7 4
--
assignee: docs@python
components: Documentation, XML
messages: 151247
nosy: docs@python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: Documentation of xml.sax.xmlreader: Locator.getLineNumber() and
Locator.getColumnNumber()
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13784>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
