[issue1136] Bdb documentation
Tim Golden added the comment: I've reviewed the docs for English and general readability. As mentioned, I've no idea of the tech involved. I did look through the bdb.py source and the existing docs for pdb to get some idea of the terminology used. Ultimately I've changed very little; in a couple of places the English was just wrong and in a couple of others I felt a small change improved things. One thing I couldn't work out is that arklad, the author, used "canonic" throughout which I've never seen used. I would simply have changed it to "canonical" except that the code itself uses "canonic" as a function name! In addition, there's no explanation of what canonic(al) means in the context. I've left ?TJG? marks around all the instances. -- nosy: +tim.golden __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1136> __ bdb.rst Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1255] Strange Python hangup
Tim Golden added the comment: Do you realise that the code at the bottom of bb.py is executed when you import it from aa.py? In other words, when you run aa.py, the whole of your significant code is running within an import statement. I don't know if it's the cause of the problem (although I remember past strictures on the messiness of threads and imports) but I doubt if it's a fantastic design choice. -- nosy: +tim.golden __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1255> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1279] os.system() oddity under Windows XP SP2
Tim Golden added the comment:
Not, apparently, on my (XP SP2) box:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system ("""python -c "f=open
('temp.txt','w');f.write('hello');f.close ()"""); print open
("temp.txt").read ()
0
hello
>>>
Perhaps you could provide a runnable piece of code which demonstrates
the problem?
--
nosy: +tim.golden
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1279>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13419] import does not recognise SYMLINKDs on Windows 7
Changes by Tim Golden : -- nosy: +brian.curtin, jason.coombs, tim.golden ___ Python tracker <http://bugs.python.org/issue13419> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13210] Support Visual Studio 2010
Tim Golden added the comment: Thanks. I was going to ask about this to see if anyone had already done the legwork. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue13210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
Tim Golden added the comment: 'fraid not. I've never had to dig into the allocation stuff at this level. -- ___ Python tracker <http://bugs.python.org/issue13483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Tim Golden added the comment: The environment passed to a Windows process must contain certain things. (I don't at this moment remember exactly what). You can't just pass the one thing you're adding. Change your "e = ..." line to something like: e = os.environ e['PATH_TO_MY_CODE'] = '/x/y/z' and then try the code. Obviously the subprocess module doesn't have enough checks in place for this -- it actually segfaults on my WinXP machine. But can you confirm that this is indeed your issue? -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue13524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Tim Golden added the comment:
Re-opening because there's a real problem here which can crash Python hard.
Simplest reproduction:
import sys
import subprocess
subprocess.Popen (sys.executable, env={})
Affects 2.x and 3.x tip (haven't tried others yet but I don't imagine it's
different)
--
assignee: -> tim.golden
components: +Library (Lib), Windows
stage: -> test needed
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue13524>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Tim Golden added the comment: Yes. I've added the "Windows" component on the tracker. (At least I think I have). It's to do with CreateProcess needing at least certain items in the environment passed. I'm trying to track down some docs on MSDN which specify which must be there. -- ___ Python tracker <http://bugs.python.org/issue13524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Tim Golden added the comment:
OK, the long and short is that spwaning a process without passing
in SystemRoot is asking for trouble. There's a blog post here
which gives an example:
http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/
And, certainly this works:
import os
import subprocess
subprocess.Popen(
"notepad.exe",
env={"SystemRoot" : os.environ['SystemRoot']}
)
I'm not quite sure what approach we should take in the subprocess
module. Is it a docs warning? Should we refuse to proceed if there's
no SystemRoot? Is it the caller's responsibility?
I'll ask on python-dev to gather opinions.
--
___
Python tracker
<http://bugs.python.org/issue13524>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Tim Golden added the comment: After a discussion on python-dev: http://mail.python.org/pipermail/python-dev/2011-December/114733.html I propose to close this call tomorrow as wontfix -- ___ Python tracker <http://bugs.python.org/issue13524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13524] critical error with import tempfile
Changes by Tim Golden : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue13524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
Tim Golden added the comment: Yes, but the MS crt strftime *for %y* requires a year >= 1900 (ie tm_year >= 0). Looks like we need a special check. -- ___ 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
Tim Golden added the comment:
This is happening on Windows x86 against the current tip. The MS C runtime can
handle older dates; it's just that we're taking 1900 off the year at some
point. (At least, I think that's what's happening). FWIW you only need
time.strftime to reproduce the error:
import time
time.strftime("%y", (1899, 1, 1, 0, 0, 0, 0, 0, 0))
If no-one gets there first I'll dig into the timemodule strftime wrapper.
--
nosy: +tim.golden
___
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
Tim Golden added the comment: ... and that's because the tm struct defines the tm_year field as an offset from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead -- ___ 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
Tim Golden added the comment: Well, the code in 2.x is quite different from that in 3.x. Specifically, the 2.x code assumes that, for Windows, no year before 1900 is valid for any of the formats. So a simple check throws a ValueError for tm_year < 0. For 3.x the assumption was that Windows can handle any year as far back as 0; in fact that's not true for the %y format. I'll propose a patch to timemodule.c but I'll have to take it to python-dev as I'm not 100% sure of the best place for it. -- ___ 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
Tim Golden added the comment: Yes, sorry. I wasn't clear enough. There *are* still checks in the 3.x code (for the kind of thing you're showing). But the checks assume 1000 <= year <= maxint is ok for all format parameters on Windows. In fact, for %y, only 1900 <= year is ok. -- ___ 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
[issue12140] Crash upon start up
Tim Golden added the comment: What happens if you try "python -S" (capital S)? In principle this should bypass the need to load site.py. Even if that works we still have a problem to solve, but at least it might narrow things down. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue12140> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11583] os.path.isdir() is slow on windows
Tim Golden added the comment:
One (presumably unintended) side-effect is that you can now do os.path.isdir on
a wildcard and the first returned entry will be tested for directoryness:
import os
os.path.isdir ("c:/tem*")
# => True where c:/temp exists
--
___
Python tracker
<http://bugs.python.org/issue11583>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11583] os.path.isdir() is slow on windows
Tim Golden added the comment: Code looks good and tests pass. Only one thing: the code in the patched lib\ntpath.py still refers to FindFirstFile -- ___ Python tracker <http://bugs.python.org/issue11583> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12084] os.stat() on windows doesn't consider relative symlink
Tim Golden added the comment: I'm just patching a clone now. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue12084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12084] os.stat() on windows doesn't consider relative symlink
Tim Golden added the comment: All expected tests pass on 3.2 branch (Win7 32-bit). The patch doesn't apply cleanly to trunk; not sure if it's expected to or not. The code looks ok on paper. I'll leave Victor to quibble over the Unicode stuff... -- ___ Python tracker <http://bugs.python.org/issue12084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database
Changes by Tim Golden : -- nosy: +markmcmahon, tim.golden ___ Python tracker <http://bugs.python.org/issue12382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] Packaging should provide better support for executable scripts on Windows
Tim Golden added the comment: Are you aware of PEP 397? http://www.python.org/dev/peps/pep-0397/ -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] Packaging should provide better support for executable scripts on Windows
Tim Golden added the comment: Adding Mark H as the author of PEP 397 -- nosy: +mhammond ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Tim Golden added the comment: Obviously someone's code would break if it were relying on the Unix errno only in a Windows-only situation to determine the situation of opening a directory which isn't one. But that combination of events doesn't seem terribly likely. Speaking for myself, since the exception is a WindowsError with the winerror attribute prominent, [Error 267] I'd be far more likely to be trapping that. I say go ahead -- ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Tim Golden added the comment: In the interests of moving this forward, I've committed the one-line removal of the assertion in r83948. Hopefully that will bring this buildbot back to life. -- ___ Python tracker <http://bugs.python.org/issue9055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9575] os.listdir() crashes on some long and deep paths in Windows 7
Changes by Tim Golden : -- assignee: -> tim.golden nosy: +tim.golden versions: -Python 2.5 ___ Python tracker <http://bugs.python.org/issue9575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Tim Golden added the comment: Fudge-fix committed as r83948, r83958. Not sure what status to set -- status: open -> pending ___ Python tracker <http://bugs.python.org/issue9055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2304] subprocess under windows fails to quote properly when shell=True
Tim Golden added the comment: ReComitted as r83947, r83956, r83957 and this time the buildbots look happy. (At least as regards this change). -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue2304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9575] os.listdir() crashes on some long and deep paths in Windows 7
Tim Golden added the comment: I can't get it crash on a path that short. I can produce an error message if I push it beyond the 254 limit, but you can work around that by applying the filesystem namespace prefix: import os path = "c:\\" + "\\".join (130 * ['xx']) os.makedirs (path) # # will fail more or less violently # path = "?\\" + path os.makedirs (path) os.listdir (path) Probably related issues: http://bugs.python.org/issue9246 http://bugs.python.org/issue4071 -- ___ Python tracker <http://bugs.python.org/issue9575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9575] os.listdir() crashes on some long and deep paths in Windows 7
Tim Golden added the comment: See: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx I tried first with your exact path and it caused no issues on my Win7 box. FWIW you could easily roll your own os.walk (starting by copying the code that's there) if you needed to roll in special-cases. Could you provide a batch file / Python script which exactly reproduces the issue and a cut-and-paste of the resulting traceback. (Unless "crash" really does mean "crash"). Would you be able to narrow the issue down any further: see if any other paths cause the same issue, or if a longer or a shorter version of the path is problematic. TJG -- title: os.listdir() crashes on some long and deep paths in Windows 7 -> os.listdir() crashes on some long and deep paths in Windows 7 ___ Python tracker <http://bugs.python.org/issue9575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1475] test_popen fails when the directory contains a space
Tim Golden added the comment: Fixed by issue2304 -- components: -Library (Lib), Tests, Windows nosy: +tim.golden resolution: -> duplicate stage: -> committed/rejected status: open -> closed type: -> behavior ___ Python tracker <http://bugs.python.org/issue1475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Tim Golden added the comment: OK; issue2304 is now fixed and closed. But it doesn't seem to make any difference to this behaviour. I've just retested and I see on py3k the behaviour the OP saw. CreateProcess does the same thing and I couldn't even get it to work with multiply-nested quotes. So I would maintain it's not a Python issue as such. I'm closing as won't fix and leave it to the OP to reopen if he feels there's something which could be done. -- assignee: -> tim.golden resolution: -> wont fix stage: unit test needed -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue5484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9575] os.listdir() crashes on some long and deep paths in Windows 7
Tim Golden added the comment: Thanks for the feedback. I'll close this for now as "works for me". Feel free to reopen if you can come up with anything fresh. -- resolution: -> works for me stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue9575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6609] zipfile: WindowsError [267] The directory name is invalid
Tim Golden added the comment:
Closing as "won't fix": this would be the same if you had any code which tried
to do os.mkdir ("aux"). By way of comparison, Info-ZIP's UnZip returns
"checkdir error: aux exists but is not directory" which actually seems less
useful!
I don't believe it's the responsibility of the zipfile module (or tarfile or
bz2 or any other) to silently reinterpret the names of files -- how would any
code in the package expecting "aux/code.c" cope with the name change?
--
assignee: -> tim.golden
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue6609>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3099] On windows, "import nul" always succeed
Changes by Tim Golden : -- assignee: -> tim.golden nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue3099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly braces in fnmatch
Tim Golden added the comment: I don't see any reason to turn this down except, perhaps, for keeping something simple. Certainly I don't believe that Windows users will be confused by the fact that there are wildcards other than "*" and "?". fnmatch already implements [] and [!] which are not supported on Windows. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue9584> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9588] Skip subprocess shell tests on Windows per file association setup
Tim Golden added the comment: Assuming I understand you correctly, could I propose this rather less involved patch which simply specifies the sys.executable as part of the command line. The test doesn't propose to test file associations and indeed two of the test already fill in the executable -- Added file: http://bugs.python.org/file18511/9588.exec.patch ___ Python tracker <http://bugs.python.org/issue9588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger()
Changes by Tim Golden : -- components: +Windows nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue1102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9627] Regrtest failed to clean up temporary directory
Tim Golden added the comment: This is usually because the bug mentioned in issue7443 (although it could be something else, obviously). It should sort itself out on the next run. I'll rerun on my local checkout to see if there real WinXP issues. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue9627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9433] regrtest.py -j 2 doesn't work on Windows: remove close_fds=True on Windows
Tim Golden added the comment: I can confirm that the patched regrtest runs ok on WinXP. -- ___ Python tracker <http://bugs.python.org/issue9433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1005895] curses for win32
Tim Golden added the comment: It looks as though issue2889 has a better chance of getting into the VS build than this one, which appears to be MingW-based (at a quick glance). I'm loosely keen to see it in, although I have no knowledge of curses as such. I'll assign it to myself so it appears on my to-do queue but I'm not promising to do anything with it immediately. Anyone who feels up to the task, feel free to take it off me. Mark: why do you consider issue1005895 the master, so to speak? I can see more mileage in pursuing the other? -- ___ Python tracker <http://bugs.python.org/issue1005895> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Tim Golden added the comment: I'll pick it up for the moment to shepherd it along because I'm reasonably keen to see a Windows curses in the stdlib. However, I'm no expert in curses and I don't promise to do anything immediate with it. -- assignee: -> tim.golden ___ Python tracker <http://bugs.python.org/issue2889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue798876] windows sys.path contains nonexistant directory
Changes by Tim Golden : -- assignee: -> tim.golden components: -Interpreter Core nosy: +tim.golden versions: +Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue798876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9654] merge PC/getpathp.c into Modules/getpath.c
Tim Golden added the comment: +1 in principle -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue9654> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Tim Golden added the comment: I have no strong opinion, Roumen, (and no experience with the package) but why -1 from you? -- ___ Python tracker <http://bugs.python.org/issue2889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1559298] test_popen fails on Windows if installed to "Program Files"
Changes by Tim Golden : -- assignee: -> tim.golden nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue1559298> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2528] Change os.access to check ACLs under Windows
Changes by Tim Golden : -- assignee: -> tim.golden ___ Python tracker <http://bugs.python.org/issue2528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9699] invalid call of Windows API _popen() generating The input line is too long error message
Changes by Tim Golden : -- assignee: -> tim.golden ___ Python tracker <http://bugs.python.org/issue9699> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9699] invalid call of Windows API _popen() generating The input line is too long error message
Tim Golden added the comment: I'll pick this up and try to decide what's best to do. I'm away from home for a few weeks and have only intermittent internet access. Thanks, Sorin, for a reproducible test case. -- title: invalid call of Windows API _popen() generating The input line is too long error message -> invalid call of Windows API _popen() generating The input line is too long error message ___ Python tracker <http://bugs.python.org/issue9699> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Tim Golden added the comment: +1 on the idea in general; I'm away at the moment and not in a position to review the patch. Hopefully Brian can review/commit -- ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Tim Golden added the comment: Merely from a Windows point-of-view, you could get the full command line fairly easily: import ctypes pstring = ctypes.windll.kernel32.GetCommandLineW () print (ctypes.c_wchar_p (pstring).value) TJG -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue2972> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Tim Golden added the comment: I'm afraid I don't know; might be worth asking that on the main python mailing list. -- ___ Python tracker <http://bugs.python.org/issue2972> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Tim Golden added the comment: Suggest you raise a separate feature-request issue for that, Geoff, perhaps offering the two implementations described. Perhaps raise it it on python-ideas first to gauge reactions. I'm +0 myself since it's so easy to do anyway and I don't know how common a requirement it would be. -- ___ Python tracker <http://bugs.python.org/issue2972> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Tim Golden added the comment: Boštjan, the code segment you quote is the *fallback* if the C module hasn't been built for some reason. The module simply calls through to the underlying C Library. I notice you're running on Windows, so this is a useful MS page: http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx and you can see there that a call of setlocale (LC_ALL, "English") is valid (of "French" if you prefer): Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale (locale.LC_ALL, "French") 'French_France.1252' >>> -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue10092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10162] mimetypes read_windows_registry should tolerate permissions errors
Tim Golden added the comment: I've only read the patch and not applied it, yet. But in principle I'm +1 on this. If Brian doesn't get there first, I'll try to apply later. -- ___ Python tracker <http://bugs.python.org/issue10162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Tim Golden added the comment: I'm afraid this falls outside my particular area of knowledge, and also outside the remit of the bug tracker. Perhaps you could post to python-list to see if anyone there can help? -- ___ Python tracker <http://bugs.python.org/issue10092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10165] char overwrite mode is by default on in Python console under Vista
Tim Golden added the comment: If you don't often use the console, then I expect your console settings have Insert mode off. (Alt-Space > Properties > Options > Insert Mode [x]) -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue10165> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10165] char overwrite mode is by default on in Python console under Vista
Agree that it's not really up to us; and that it's trivial to change once for all future python processes. As to the left-click blocking, I think that's "Quick Edit" mode you're thinking of, not "Insert" TJG ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10190] Can argparse._AttributeHolder._get_kwargs become a public API?
Tim Golden added the comment: Removing docs unless this actually becomes a doc issue -- nosy: +tim.golden -d...@python ___ Python tracker <http://bugs.python.org/issue10190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10190] Can argparse._AttributeHolder._get_kwargs become a public API?
Changes by Tim Golden : -- assignee: d...@python -> bethard ___ Python tracker <http://bugs.python.org/issue10190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10684] Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
Tim Golden added the comment: Patch fixes the issue and tests run ok on 3.3 Win7; just building a 2.7 branch to test -- ___ Python tracker <http://bugs.python.org/issue10684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: For clarity, while making unlink more robust is no bad thing, the error occurs when the unlink *succeeds* but a subsequent create of the same name fails. This happens when an indexer, Virus scanner or TortoiseSvn etc. has opened the file with SHARE_DELETE. This allows a DeleteFile to succeed but continues to hold an open handle on the file. A following test which uses an identically named file (such as the global TESTFN) will fail if not enough time has elapsed for the background process to release its handle. A good candidate to see this in action is the test for tarfile. I did start to undertake a conversion of TESTFN to a named temporary, but it started to sprawl all over the place and came up against a number of corner cases (eg where tests deliberately wanted two filenames to be the same) so I gave up. -- ___ Python tracker <http://bugs.python.org/issue7443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: Well http://bugs.python.org/issue7443#msg102833 outlines the problems I encountered while trying to do essentially that. Nothing insurmountable, but definitely bigger than simply adding one line of code. Looks to me like there are two avenues of approach (and, given the chatter on this issue, several people willing to address them): * Patch Py_DeleteFileW in posixmodule.c so that it renames before deleting: should solve the problem overall but obviously has a possible wider impact, in general and on performance in particular. This rename might be a simple rename-to-guid or something more sophisticated such as the rename-to-recycler which cygwin uses. * Patch support.unlink in the test package to do the rename dance on the basis that it'll fix at least some of the problems with less impact overall. Opinions? I'm willing to do either. -- ___ Python tracker <http://bugs.python.org/issue7443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11750] Mutualize win32 functions
Tim Golden added the comment: +1 -- ___ Python tracker <http://bugs.python.org/issue11750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10888] os.stat(filepath).st_mode gives wrong 'executable permission' result
Tim Golden added the comment: FWIW I agree with MvL: os.stat is one of those awkward customers left over from the idea that Windows could be posix-compliant, even though the relevant concepts don't actually map particularly well. ISTM that anyone seriously wanting to determine whether something's executable or not on Windows is going to have in mind the precise semantics of a particular use-case and will employ whatever API calls meet that need. I genuinely don't believe there's any mileage in shoehorning more and more corner-cases into os.stat on Windows. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue10888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11922] Add General Index to Windows .chm help file Contents
Tim Golden added the comment: I can't say I'd object as such, but the [Index] tab already contains the items in the General Index and is arguably the killer feature of the CHM in any case. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue11922> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly brace expansion
Tim Golden added the comment:
I've just rebuilt on Windows against tip. test_glob is failing:
test test_glob failed -- Traceback (most recent call last):
File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line
135, in test_glob_curly_braces
os.path.join('a', 'bcd', 'efg')]))
File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line
53, in assertSequencesEqual_noorder
self.assertEqual(set(l1), set(l2))
AssertionError: Items in the first set but not the second:
'@test_2788_tmp_dir\\a/bcd\\efg'
'@test_2788_tmp_dir\\a/bcd\\EF'
Items in the second set but not the first:
'@test_2788_tmp_dir\\a\\bcd\\EF'
'@test_2788_tmp_dir\\a\\bcd\\efg'
--
___
Python tracker
<http://bugs.python.org/issue9584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12086] Tutorial doesn't discourage name mangling
Tim Golden added the comment: But at the least, the start of the para might be slightly reworded to something like: "If you specifically need to avoid name clashes with subclasses, there is limited support..." which avoids the phrase "Since there is a valid use-case for class-private members". -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue12086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10452] Unhelpful diagnostic 'cannot find the path specified'
Tim Golden added the comment: It's almost certainly coming straight back from the O/S, where Python is doing its usual thing of channelling an O/S error directly. Obviously we could special-case this or any other specific error; but we usually don't -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue10452> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10618] regression in subprocess.call() command quoting
Tim Golden added the comment: I'm not quite sure how anyone's supposed to determine which bugs are likely to have been worked around and which haven't :) I'm also unsure why a clear bugfix shouldn't make it into a minor version release. Surely this isn't the only one to do so... I'm happy to repatch/test to strip quotes before adding, but I see that Benjamin prefers to leave it alone. -- ___ Python tracker <http://bugs.python.org/issue10618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print utf8 (Py30a2)
Tim Golden added the comment: Reopening as there seems to be some possibility of progress -- nosy: -BreamoreBoy resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print utf8 (Py30a2)
Changes by Tim Golden : -- versions: +Python 3.3 -Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3050] Implement PEP 371: multiprocessing module
Tim Golden <[EMAIL PROTECTED]> added the comment: The _multiprocessing module is not building under Windows at the moment. Attempting to import multiprocessing (from an .exe build from the current svn) gives "ImportError: No module named _multiprocessing" and the test suite skips the test for the same reason. -- nosy: +tim.golden ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3050] Implement PEP 371: multiprocessing module
Tim Golden <[EMAIL PROTECTED]> added the comment: Benjamin Peterson wrote: > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > On Wed, Jun 11, 2008 at 9:20 AM, Tim Golden <[EMAIL PROTECTED]> wrote: >> Tim Golden <[EMAIL PROTECTED]> added the comment: >> >> The _multiprocessing module is not building under Windows at the moment. >> Attempting to import multiprocessing (from an .exe build from the >> current svn) gives "ImportError: No module named _multiprocessing" and >> the test suite skips the test for the same reason. > > Can you tell why it's not building? I was hoping you wouldn't ask :) I can't run VS visually at the moment so I'm down to inspecting the .sln file by hand which I have no experience of. I suspect that someone better versed in VS solution files than I needs to add the module in. I'll try to get to it unless someone else chips in. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3050] Implement PEP 371: multiprocessing module
Tim Golden <[EMAIL PROTECTED]> added the comment: I'm sorry; I've had a look and there's no chance of my updating the solution and project files by hand; and I can't run Visual Studio at the moment. I'll try emailing Trent or Christian in the hope that one of them's available to do it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3050] Implement PEP 371: multiprocessing module
Tim Golden <[EMAIL PROTECTED]> added the comment: Trent's supplied me with enough info to patch the project files manually. The attached patch against r64120 results in the _multiprocessing module building. I'm running the tests now but I'll upload the patch in any case. Added file: http://bugs.python.org/file10588/pcbuild.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3086] sys.maxsize not available by using the latest Win32 build
Tim Golden <[EMAIL PROTECTED]> added the comment: Giampaolo Rodola' wrote: > New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>: > > By using: > http://www.python.org/dev/daily-msi/python-2.6.14041.msi > > > C:\>C:\python26\python > Python 2.6a3 (r26a3:62864, May 9 2008, 14:16:26) [MSC v.1500 32 bit > (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> sys.maxsize > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'maxsize' It's there in a trunk build Python 2.6a3+ (trunk:64120:64164M, Jun 12 2008, 08:49:20) Type "help", "copyright", "credits" or "license" for more >>> import sys [34171 refs] >>> sys.maxsize 2147483647 [34173 refs] >>> -- nosy: +tim.golden ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3210] subprocess.Popen does not release process handles if process cannot be started
Tim Golden <[EMAIL PROTECTED]> added the comment: The attached file sp-3.py simulates what I think is happening within the subprocess module. Note that the OS handle is duplicated to allow inheritance and then left unclosed on failure. If it is explicitly closed, the file can be removed. There is no hope of closing the file handle since it was local to the __init__ method which failed but was not closed before exit and is now inaccessible. On the surface, the obvious fix would be a try/except block around the CreateProcess call (or its caller) which would then release whatever handles were needed. I'll try to get the time to put a patch together, but it would be useful to have confirmation of my theory. -- nosy: +tim.golden Added file: http://bugs.python.org/file10744/sp-3.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3258] ctypes assertion failure in trunk
New submission from Tim Golden <[EMAIL PROTECTED]>: The following code raises an Assertion Failure under debug in r64518 running on Windows XP SP2: import ctypes class X (ctypes.Structure): pass ctypes.POINTER (X) Assertion failed: PyErr_Occurred(), file ..\Modules\_ctypes\_ctypes.c, line 309 -- assignee: theller components: ctypes messages: 69102 nosy: theller, tim.golden severity: normal status: open title: ctypes assertion failure in trunk type: crash versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3258> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3258] ctypes assertion failure in trunk
Tim Golden <[EMAIL PROTECTED]> added the comment: The comment just before _ctypes.c:309 indicates that when a NULL is returned at that point, an error condition should already obtain. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3258> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7877] Iterators over _winreg EnumKey and EnumValue results
Tim Golden added the comment: Traceback (most recent call last): File "", line 1, in WindowsError: [Error 6] The handle is invalid I suspect that .iterkeys / .itervalues would be more acceptable spellings as those mirror the dict methods. Whether the idea of extending _winreg beyond the absolute basics will fly I'm not sure. I don't often use it, but this would be useful if I did... # On 07/02/2010 21:31, Brian Curtin wrote: > > New submission from Brian Curtin: > > While EnumKey and EnumValue directly implement the underlying Windows calls > of the same name, they don't feel very Pythonic. The user has to create their > own loop and increment a counter to get all of the keys or values, stopping > the loop when WindowsError is raised. > > I created IterKey and IterValue, iterators over RegEnumKeyEx and > RegEnumValueEx respectively. This mainly began as playing around with writing > Python iterators in C, but has proven to work pretty nicely so I figured I'd > put it out there. > > Patch includes docs and tests. Comments/suggestions welcome and appreciated. > > -- > components: Library (Lib), Windows > files: keyvalue_iterators.diff > keywords: needs review, patch, patch > messages: 99020 > nosy: brian.curtin > priority: normal > severity: normal > stage: patch review > status: open > title: Iterators over _winreg EnumKey and EnumValue results > type: feature request > versions: Python 2.7, Python 3.2 > Added file: http://bugs.python.org/file16170/keyvalue_iterators.diff > > ___ > Python tracker > <http://bugs.python.org/issue7877> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue7877> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7877] Iterators over _winreg EnumKey and EnumValue results
Tim Golden added the comment: Sorry; the email interface messed that up. The code which triggered the error was: import _winreg list ( _winreg.IterValue ( _winreg.OpenKey (_winreg.HKEY_CURRENT_USER, "Console") ) ) -- ___ Python tracker <http://bugs.python.org/issue7877> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7910] immutability w/r to tuple.__add__
Tim Golden added the comment: Just think about it for a minute: t = (1, 2) print id (t), t t += (1, 2, 3) print id (t), t Not mutating, merely creating a new new object and giving it the same name -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue7910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8273] move test_support into the unittest package
Tim Golden added the comment: On 31/03/2010 14:20, Michael Foord wrote: > - TESTFN > > This is a global for setting the directory temporary files are created in? > Don't think I like the global approach. Which functions is it used by? It's used *all over the place*. I started trying to rip it out ages ago but it call got far too intrusive and I just backed away. ISTR that more recent tests have used NamedTemporaryFile or something similar, which makes much more sense. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue8273> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8333] test_multiprocessing: pickling failures
Tim Golden added the comment: Seeing the same thing on 32-bit WinXP on x86 On 07/04/2010 14:34, Stefan Krah wrote: > > New submission from Stefan Krah: > > On Windows/amd64, I get loads of pickling errors in test_multiprocessing. > > Type 1 error: > > Traceback (most recent call last): >File "", line 1, in >File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, > in main > self = load(from_parent) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 1378, in load > return Unpickler(file).load() >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 858, in load > dispatch[key](self) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 880, in load_eof > raise EOFError > EOFError > > > Type 2 error: > > == > ERROR: test_fork (__main__.WithManagerTestQueue) > -- > Traceback (most recent call last): >File "..\..\Lib\test\test_multiprocessing.py", line 485, in test_fork > p.start() >File "C:\Users\stefan\svn\trunk\lib\multiprocessing\process.py", line 104, > in start > self._popen = Popen(self) >File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 244, > in __init__ > dump(process_obj, to_child, HIGHEST_PROTOCOL) >File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 167, > in dump > ForkingPickler(file, protocol).dump(obj) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 224, in dump > self.save(obj) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save > self.save_reduce(obj=obj, *rv) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce > save(state) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict > self._batch_setitems(obj.iteritems()) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in > _batch_setitems > save(v) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 40, > in dispatcher > self.save_reduce(obj=obj, *rv) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 401, in save_reduce > save(args) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 548, in save_tuple > save(element) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save > self.save_reduce(obj=obj, *rv) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce > save(state) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict > self._batch_setitems(obj.iteritems()) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in > _batch_setitems > save(v) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save > self.save_reduce(obj=obj, *rv) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce > save(state) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict > self._batch_setitems(obj.iteritems()) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in > _batch_setitems > save(v) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save > self.save_reduce(obj=obj, *rv) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 396, in save_reduce > save(cls) >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save > f(self, obj) # Call unbound method with explicit self >File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 748, in save_global > (obj, module, name)) > PicklingError: Can't pickle:
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: This is basically a rerun of this discussion a couple of years ago: http://mail.python.org/pipermail/python-dev/2008-April/078333.html The problem certainly still happens against trunk -- I have a semi-aggressive test-harness which can cause it to reproduce pretty much on-demand. I proposed an approach here: http://mail.python.org/pipermail/python-dev/2008-April/078339.html but when I started digging into test_support it all got a bit hairy because -- naturally -- test.support.unlink is used in a *lot* of places. In short, there's still a problem to be fixed. I believe that a rename-unlink dance would solve it, but only at the cost of affecting a lot of tests. -- nosy: +tim.golden ___ Python tracker <http://bugs.python.org/issue7443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: In one window run the attached script (assumes you have pywin32 installed) with a parameter of the directory the TESTFN file will end up in. Then run, eg, test_zipfile in another window. For me: c:\temp> watch_dir.py C:\work_in_progress\make-snapshots\trunk\python\Lib C:\work_in_progress\make-snapshots\trunk\python\Lib> ..\pcbuild\python.exe -m test.test_zipfile Obviously, you'd have to change the path to be wherever you're running the test suite from. The watch_dir script sits there looking for file activity, then takes and releases a delete-share handle on the file. It's enough to disrupt certain tests (such as test_zipfile) pretty much every time. Other tests are affected less, or only the first few times. Not sure why, but it's certainly enough to reproduce the general effect of TortoiseSVN or indexer or virus checker. -- Added file: http://bugs.python.org/file16839/watch_dir.py ___ Python tracker <http://bugs.python.org/issue7443> ___import os, sys import winerror import win32file import win32con if __name__ == '__main__': path_to_watch = sys.argv[1] hDir = win32file.CreateFile ( path_to_watch, 1, # FILE_LIST_DIRECTORY win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE, None, win32con.OPEN_EXISTING, win32con.FILE_FLAG_BACKUP_SEMANTICS, None ) print "=> Watching", path_to_watch watching = set () handles = [] try: while 1: results = win32file.ReadDirectoryChangesW ( hDir, 1024, True, win32con.FILE_NOTIFY_CHANGE_FILE_NAME, None, None ) for action, filename in results: filename = os.path.join (path_to_watch, filename) if action == 1 and filename not in watching: try: handle = win32file.CreateFile ( filename, 0, win32file.FILE_SHARE_DELETE, None, win32file.OPEN_EXISTING, 0, 0 ) handles.append (handle) except win32file.error, (errno, module, message): if errno == winerror.ERROR_SHARING_VIOLATION: print ".. Can't hold", repr (filename) else: print ".. Problem with %r: %s" % (filename, message) else: watching.add (filename) print ".. Holding", repr (filename) handle.Close () handles.remove (handle) watching.discard (filename) print ".. Released", repr (filename) finally: for handle in handles: handle.Close () hDir.Close () ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: I put together a trivial patch against the 2.7 trunk (basically: I added a os.rename before the os.remove in test_support.unlink) and reran my test harness with test_zipfile... and it still failed because, of course, test_zipfile calls shutil.rmtree which bypasses the test_support.unlink altogether etc. etc. At this point several things occur to me: 1) There's little point in targetting the 2.x tree since 2.7 is due out any time now and is effectively end-of-line for 2.x and this isn't a release-blocker. Therefore whatever effort is brought to bear should be against the 3.x latest 2) This is a repeatable but relatively minority case: it only applies to Windows boxes and only to those where some behind-the-scenes process is holding this kind of lock on files for long enough to affect the tests. I'd certainly like to nail it but... 3) The amount of work -- and intrusion in the tests -- is quite substantial. Just looking [*] for straight os.unlink instances, without even considering shutil use gives 71 instances; os.remove gives another 90. That's even without the issues of the tests for shutil and os in any case. I'm willing to do the legwork of moving all the tests use, eg, support.unlink, support.rmtree and so on, but quis custodiet? who'll test the tests? grep "os\.unlink" *.py | wc -l grep "os\.remove" *.py | wc -l 4) All that said, the result should be a cleaner, more controllable test environment, at least for temp files. Another solution would be to rework the use of TESTFN on Windows to use a new temporary file every time. But that would be as much work and more than the unlink / rmtree work above. I'd like to hear opinions before I move forward with a non-trivial patch for this. For the sake of completeness, I attach a tiny test case which shows that the rename/remove approach should in fact work for the symptom we're seeing. -- Added file: http://bugs.python.org/file16869/test-case.py ___ Python tracker <http://bugs.python.org/issue7443> ___import os, sys import traceback import win32file FILENAME = "test" def rename_and_remove (filename): os.rename (filename, filename + ".deleted") os.remove (filename + ".deleted") def remove_only (filename): os.remove (filename) def test (remove): open (FILENAME, "w").close () hFile = win32file.CreateFile ( FILENAME, win32file.GENERIC_READ, win32file.FILE_SHARE_DELETE, None, win32file.OPEN_EXISTING, 0, 0 ) try: remove (FILENAME) try: open (FILENAME, "w").close () except IOError: print "FAIL" else: print "PASS" finally: hFile.Close () try: open (FILENAME, "w").close () except IOError: print "FAIL" else: print "PASS" if __name__ =='__main__': print print "Should see FAIL-PASS" test (remove_only) print print "Should see PASS-PASS" test (rename_and_remove) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: I'm afraid that the problem doesn't lie in the unlink: DeleteFile succeeds. The problem is that the file is only marked for delete until such time as the last SHARE_DELETE handle on it is closed. Until that time, an attempt to (re)create the file for anything other than SHARE_DELETE will fail. As you say, it's a timing issue. Making os.unlink on Windows more robust may be a good idea, but it's not going to help this issue. See my test-case.py on an earlier message for reproduction: http://bugs.python.org/file16869 TJG -- ___ Python tracker <http://bugs.python.org/issue7443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Tim Golden added the comment: > Then we shouldn't use DeleteFile in the first place to delete the file, > but instead CreateFile, with DELETE access (and FILE_SHARE_DELETE > sharing). If that fails, we need to move the file to the bin > (see unlink_nt for details). I see what you're getting at. I'm getting to the end of my day here, but I'll try to put a patch together for posixmodule.c when I can, if no-one else gets there first. Would you agree that py3k is the only target branch worth aiming for? -- ___ Python tracker <http://bugs.python.org/issue7443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8385] _winreg remaining in test_winsound
New submission from Tim Golden : There is a reference to _winreg left in test_winsound. Trivial patch attached renames this to winreg. -- components: Tests files: test_winsound.patch keywords: patch messages: 103042 nosy: tim.golden severity: normal status: open title: _winreg remaining in test_winsound type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file16908/test_winsound.patch ___ Python tracker <http://bugs.python.org/issue8385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8385] _winreg remaining in test_winsound
Changes by Tim Golden : -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/issue8385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8386] test_pickle failing
New submission from Tim Golden : test_pickle failing on WinXP http://svn.python.org/projects/python/branches/py3k/Lib r80044 == ERROR: test_unicode (__main__.CPicklerTests) -- Traceback (most recent call last): File "test\pickletester.py", line 523, in test_unicode p = self.dumps(u, proto) File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps p.dump(arg) UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed == ERROR: test_unicode (__main__.CDumpPickle_LoadPickle) -- Traceback (most recent call last): File "test\pickletester.py", line 523, in test_unicode p = self.dumps(u, proto) File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps p.dump(arg) UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed == ERROR: test_unicode (__main__.DumpPickle_CLoadPickle) -- Traceback (most recent call last): File "test\pickletester.py", line 524, in test_unicode u2 = self.loads(p) File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 37, in loads return u.load() UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3: illegal encoding -- -- messages: 103045 nosy: tim.golden severity: normal status: open title: test_pickle failing ___ Python tracker <http://bugs.python.org/issue8386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8386] test_pickle failing
Tim Golden added the comment:
Yes:
C:\temp>\work_in_progress\make-snapshots\branches
Python 3.2a0 (py3k:80030, Apr 13 2010, 11:13:13)
Type "help", "copyright", "credits" or "license"
>>> '\uDC80'.encode("utf8", "surrogatepass")
b'\xed\xb2\x80'
>>>
--
___
Python tracker
<http://bugs.python.org/issue8386>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8386] test_pickle failing
Tim Golden added the comment: Well that's embarrassing: I updated but didn't rebuild. Sorry for the noise; all tests passing now. Please close the call. -- ___ Python tracker <http://bugs.python.org/issue8386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8439] test_linecache failing in py3k r80169
New submission from Tim Golden : test_linecache in the current py3k branch is failing on my WinXP machine with ERROR_SHARING_VIOLATION. The attached trivial patch appears to fix the problem, altho' I'm unfamiliar with the module in question so it may be that there's more to be done. -- files: test_linecache.py.patch keywords: patch messages: 103475 nosy: tim.golden severity: normal status: open title: test_linecache failing in py3k r80169 Added file: http://bugs.python.org/file16970/test_linecache.py.patch ___ Python tracker <http://bugs.python.org/issue8439> ___Index: test_linecache.py === --- test_linecache.py (revision 80169) +++ test_linecache.py (working copy) @@ -114,6 +114,7 @@ for index, line in enumerate(source): self.assertEquals(line, getline(source_name, index + 1)) source_list.append(line) +source.close () finally: support.unlink(source_name) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8440] test_heapq interfering with test_import on py3k
New submission from Tim Golden :
If test_heapq is run before test_import on the current py3k head,
test_import will fail as per the attached traceback.
python -m test.regrtest -W test_heapq test_import > test_import.log
At a glance I can't see any obvious reason why test_heapq should have
any effect on test_import. Raising this bug while I try to narrow down.
An extra assert inside support.make_legacy_pyc confirms that
the .pyc being renamed into does in fact already exist.
Running test_import on its own or via regrtest when not preceded
by test_heapq runs with error.
--
files: test_import.log
messages: 103488
nosy: tim.golden
severity: normal
status: open
title: test_heapq interfering with test_import on py3k
Added file: http://bugs.python.org/file16972/test_import.log
___
Python tracker
<http://bugs.python.org/issue8440>
___test_heapq
test_import
compiled to __pycache__\longlist.cpython-32.pyc
test test_import failed -- Traceback (most recent call last):
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py",
line 167, in test_module_with_large_stack
exec('import ' + module)
File "", line 1, in
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py",
line 151, in decorated
return fxn(self, module)
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py",
line 320, in load_module
code_object = self.get_code(module.__name__)
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py",
line 429, in get_code
"object for {0!r}".format(fullname))
ImportError: no source or bytecode available to create code object for
'longlist'
Re-running test test_import in verbose mode
test_case_sensitivity (test.test_import.ImportTests) ... ok
test_double_const (test.test_import.ImportTests) ... ok
test_execute_bit_not_copied (test.test_import.ImportTests) ... skipped 'test
meaningful only on posix systems'
test_failing_import_sticks (test.test_import.ImportTests) ... ok
test_failing_reload (test.test_import.ImportTests) ... ok
test_file_to_source (test.test_import.ImportTests) ... ok
test_imp_module (test.test_import.ImportTests) ... ok
test_import (test.test_import.ImportTests) ... ok
test_import_by_filename (test.test_import.ImportTests) ... ok
test_import_initless_directory_warning (test.test_import.ImportTests) ... ok
test_import_name_binding (test.test_import.ImportTests) ... ok
test_module_with_large_stack (test.test_import.ImportTests) ... compiled to
__pycache__\longlist.cpython-32.pyc
ERROR
test___cached__ (test.test_import.PycacheTests) ... ok
test___cached___legacy_pyc (test.test_import.PycacheTests) ... ok
test_import_pyc_path (test.test_import.PycacheTests) ... ok
test_missing_source (test.test_import.PycacheTests) ... ok
test_missing_source_legacy (test.test_import.PycacheTests) ... ok
test_package___cached__ (test.test_import.PycacheTests) ... ok
test_package___cached___from_pyc (test.test_import.PycacheTests) ... ok
test_unwritable_directory (test.test_import.PycacheTests) ... skipped 'test
meaningful only on posix systems'
test_basics (test.test_import.PycRewritingTests) ... ok
test_foreign_code (test.test_import.PycRewritingTests) ... ok
test_incorrect_code_name (test.test_import.PycRewritingTests) ... ok
test_module_without_source (test.test_import.PycRewritingTests) ... ok
test_UNC_path (test.test_import.PathsTests) ... ok
test_trailing_slash (test.test_import.PathsTests) ... ok
test_issue3221 (test.test_import.RelativeImportTests) ... ok
test_relimport_star (test.test_import.RelativeImportTests) ... ok
test_override_builtin (test.test_import.OverridingImportBuiltinTests) ... ok
==
ERROR: test_module_with_large_stack (test.test_import.ImportTests)
--
Traceback (most recent call last):
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py",
line 161, in test_module_with_large_stack
make_legacy_pyc(filename)
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\support.py",
line 209, in make_legacy_pyc
os.rename(pyc_file, legacy_pyc)
WindowsError: [Error 183] Cannot create a file when that file already exists
--
Ran 29 tests in 1.672s
FAILED (errors=1, skipped=2)
test test_import failed -- Traceback (most recent call last):
File
"C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py",
line 161, in test_module_with_large_stack
make_legacy_pyc(filename)
File
"C:\work-in-progress\make-snapshots\branch
[issue8273] move generally useful test_support functions into the unittest package
Changes by Tim Golden : -- nosy: -tim.golden ___ Python tracker <http://bugs.python.org/issue8273> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
