[issue7443] test.support.unlink issue on Windows platform

Tim Golden added the comment: This has been covered off by work done with the test.support package including context managers for temporary files / directories, and a waitfor mechanism which waits some time if a file can't be accessed. -- resolution: - works for me status: open

[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly

Tim Golden added the comment: The Ctrl-C handling in Python on Windows is a bit strange in places. I'll add this to my list of things to look at. If you'd care to walk through the code to produce a patch or at least to point to suspect code, that would make it more likely that it be fixed

[issue9035] os.path.ismount on windows doesn't support windows mount points

Tim Golden added the comment: I put a bit of work in on this this morning, following Mark's suggestion (msg138197) since that's the canonical approach. Unfortunately, it completely fails to work for the most common case: the root folder of a drive! The documentation for FindFirstFile

[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly

Tim Golden added the comment: Thanks for doing the investigation. Yes, that comment was added by me as part of the fix for issue1677. I'll try to have a look at the codepath you describe to see if we can add a similar workaround. The Ctrl-C / SIGINT handling on Windows is less than ideal, I

[issue9035] os.path.ismount on windows doesn't support windows mount points

Tim Golden added the comment: issue9035.2.patch is an updated version of Atsuo's patch. Known issues: * I haven't reworked it for the new memory-management API * There's no test for a non-root mount point (which is really the basis for this issue). It's difficult to see how to do

[issue9035] os.path.ismount on windows doesn't support windows mount points

Tim Golden added the comment: issue9035.3.patch has switched to the new memory management API and has tweaked the tests slightly for robustness. This approach does introduce a behavioural change: the root of a SUBSTed drive (essentially a symlink into the Dos namespace) will raise an OSError

[issue18525] Shutil cannot import WindowsError on windows

Tim Golden added the comment: Really this should be a wont-fix: the fact that it's possible to import WindowsError from shutil (on Linux) is an accident of its internal implementation. It's certainly not documented as such. Saurabh: WindowsError is a builtin on Windows. If you want to mimic

[issue18491] Add exe wrapper functionality to Windows launcher

Tim Golden added the comment: Glancing back, it isn't perhaps clear to the casual reader what's being proposed here, and why. The idea is that a pip-style installer become part of core Python. For Windows users, any standalone scripts from an installed package would be placed in scripts

[issue18040] SIGINT catching regression on windows in 2.7

Tim Golden added the comment: Personally, I'm +0 at best on this change. It would achieve consistency with Linux but I'm not sure what you'd do with such functionality. Adding Richard Oudkerk who did the rework of the interrupt signal for 3.3. Richard, any opinion on this? -- nosy

[issue18040] SIGINT catching regression on windows in 2.7

Tim Golden added the comment: Thanks for the feedback, David. Closing as won't fix. -- resolution: - wont fix stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18040

[issue18040] SIGINT catching regression on windows in 2.7

Tim Golden added the comment: Correction: I see the desired behaviour in 3.3/3.4 which is where the overhaul to Ctrl-C handling on Windows was applied. I still can't see it in 2.6 or in 3.1/3.2 on Windows. The problem lies in the fact that PyOS_InterruptOccurred and PyErr_CheckSignals from

[issue18040] SIGINT catching regression on windows in 2.7

Tim Golden added the comment: My initial reaction is that, whether the 2.7 behaviour is faulty or not, I can't reproduce the correct behaviour on any version of Windows going back to 2.4. Take the attached Python file issue18040.py and run c:\pythonxx\python.exe -i issue18040.py for any

[issue17244] py_compile.compile() fails to raise exceptions when writing of target file fails

Tim Golden added the comment: Essentially: no. The permissions system in Windows is very different from that of Unix. The CRT attempts to mimic it, but for things like read-onlyness, it does so by setting the (old-style DOS) attributes. These are only just meaningful for files

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

Tim Golden added the comment: Attached is a qd script to produce the list of extension - mimetype maps for a version of the mimetypes module. -- Added file: http://bugs.python.org/file29900/mt.py ___ Python tracker rep...@bugs.python.org http

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

Tim Golden added the comment: Three outputs produced by mt.py: tip as-is; tip without registry; tip with new approach to registry. The results for 2.7 are near-enough identical. Likewise the results for an elevated prompt. -- Added file: http://bugs.python.org/file29901/mt-tip.txt Added

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

Tim Golden added the comment: There seems to be a consensus that the current behaviour is undesirable, indeed broken for any meaningful use. The critical argument against the current Registry approach is that it returns unexpected (or outright incorrect) mimetypes for very standard extensions

[issue17619] MS WINDOWS: input() swallows KeyboardInterrupt in Python 3.3

Tim Golden added the comment: That's because IDLE uses a completely different input loop from the console interpreter. I'll try to get to this but I'm chock-a-block with other work at the moment. If anyone else wants to dig, please do so. if the worst came to the worst we could back out my

[issue17619] MS WINDOWS: input() swallows KeyboardInterrupt in Python 3.3

Tim Golden added the comment: +1 Richard - are you in a position to commit / push? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17619

[issue17366] os.chdir win32

Tim Golden added the comment: Dave, you seem to misunderstand what's happening here: the os.chdir function doesn't have access to the characters which are typed in the script or in the interpreter. It receives a Python string object. The parser etc. which constructs the string object determines

[issue11406] There is no os.listdir() equivalent returning generator instead of list

Tim Golden added the comment: IIRC Nick Coghlan had put a bit of work into this a few months ago as an external module with a view to seeing if it got traction before putting anything into the stdlib. Might be worth pinging him, or looking to see what he'd done. Can't remember the keywords

[issue11406] There is no os.listdir() equivalent returning generator instead of list

Tim Golden added the comment: OK, sorry for the noise then; I had the idea that it was doing something with iterators/generators. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11406

[issue17290] pythonw - loading cursor bug when launching scripts

Tim Golden added the comment: netrick: can you confirm that the same thing occurs when you explicitly run your code via the pyw command. ie when you do this: pyw myprog.pyw Also, what happens when you run: py myprog.pyw ie when you use the Console launcher to launch the .pyw

[issue17290] pythonw - loading cursor bug when launching scripts

Tim Golden added the comment: I can't reproduce this running Python 3.3 on Win7. I'll try WinXP later. I'll also add Mark Hammond Vinay as they implemented the PEP397 loader. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue17290] pythonw - loading cursor bug when launching scripts

Changes by Tim Golden m...@timgolden.me.uk: -- nosy: +mhammond, vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17290 ___ ___ Python

[issue17290] pythonw - loading cursor bug when launching scripts

Tim Golden added the comment: Things may be a little more complicated, because one of two distinct mechanisms may be invoked to determine what to run when double-clicking: an Explorer-based mechanism, and a non-Explorer one. AFAICT, the former falls back to the latter. To check the latter

[issue17290] pythonw - loading cursor bug when launching scripts

Tim Golden added the comment: I can't reproduce this on XP either. I've tried various combinations of .py / .pyw, command line, double-click, etc. and I've not had a single problem. Let's hope someone else can suggest something -- ___ Python

[issue17208] add note/warning about daemon threads

Tim Golden added the comment: +1 This is essentially the answer to the naive user's question: Why would anyone *not* use daemon threads given that they're less hassle to manage? -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http

[issue14208] No way to recover original argv with python -m

Tim Golden added the comment: My use case is the reloader or restarter. I've initially fallen foul of this when using the cherrypy reloader (which does an execv by building from sys.executable + sys.argv) but I also have web services running which I'd like to restart remotely by forcing them

[issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong

Tim Golden added the comment: This code is no longer present in subprocess.py now that issue14470 has been applied. -- nosy: +brian.curtin, tim.golden resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker

[issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong

Tim Golden added the comment: Reopening because there is in fact a doc issue reamining. -- assignee: - tim.golden resolution: out of date - stage: committed/rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http

[issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong

Tim Golden added the comment: I can't push from work; the (trivial) doc patch is attached. If no-one gets to it, I'll push from home this evening. -- Added file: http://bugs.python.org/file28688/doc.diff ___ Python tracker rep...@bugs.python.org

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

Tim Golden added the comment: Sorry; late to the party. I'll try to take a look at the patches. Basically I'm sympathetic to the problem (which seems quite straightforwardly buggish) but I want to take a look around the issue first. TJG

[issue16633] os.environ updates only one copy of env vars under Windows (GetEnvironmentVariable vs. getenv)

Tim Golden added the comment: Does the same problem obtain if you use os.putenv (which calls the crt putenv under the covers)? -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16633

[issue16524] File access not always working with Python for Windows 32 bits on Windows 64 bits OS

Tim Golden added the comment: Not Python, but Windows. See here: http://msdn.microsoft.com/en-gb/library/windows/desktop/aa384187%28v=vs.85%29.aspx -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16524

[issue16458] subprocess.py throw The handle is invalid error on duplicating the STD_INPUT_HANDLE

Tim Golden added the comment: Karthk, if you can run up an up-to-date patch and a test I'm willing to review and commit it, otherwise this one will lie quiet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16458

[issue16458] subprocess.py throw The handle is invalid error on duplicating the STD_INPUT_HANDLE

Changes by Tim Golden m...@timgolden.me.uk: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16458 ___ ___ Python-bugs-list

[issue16458] subprocess.py throw The handle is invalid error on duplicating the STD_INPUT_HANDLE

Tim Golden added the comment: On 13/11/2012 20:57, Karthk Rajagopalan wrote: I added test case using perl and python since it was easy to reproduce using perl socket module and show the issue happening with python's subprocess.py. There is definitely an action required in subprocess.py

[issue16458] subprocess.py throw The handle is invalid error on duplicating the STD_INPUT_HANDLE

Tim Golden added the comment: Start here: http://docs.python.org/devguide/ In particular: http://docs.python.org/devguide/patch.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16458

[issue16458] subprocess.py throw The handle is invalid error on duplicating the STD_INPUT_HANDLE

Tim Golden added the comment: I'm sorry, but I genuinely can't see what you're trying to say here. If you believe that there's a bug in Python's standard library, can you show a reproducible *Python* testcase for it, please (using the pywin32 modules if that helps) and state clearly what you

[issue9584] Allow curly brace expansion

Changes by Tim Golden m...@timgolden.me.uk: Removed file: http://bugs.python.org/file27894/0003-reworked-issue9584.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9584

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Given that this isn't going to go ahead in its current form, and will need wider discussion on python-dev, I'm unassigning myself and I've removed the flawed version of the patch which I'd posted. -- assignee: tim.golden

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Must have been something I did. I'll revert the commit and re-test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9584

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Well even in the original [working] version, the scope of this change was limited to glob.glob. os.listdir doesn't currently support any form of expansion (at least not on Windows) and nor does os.makedirs. I don't see any problem in restricting this change

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Sorry, I misunderstood the point you were making with the os.listdir/makedirs examples. Fair point about backwards compatibility. This may make this change untenable as no-one will want a series of use_feature_xxx flags, one for each change we introduce to glob.glob

[issue9584] Allow curly brace expansion

Tim Golden added the comment: I've got a patch for this which applies cleanly to the 3.4 tip. I still need to sort out the Windows issues (which I don't think will be difficult; it looks like a test issue, not a code issue) -- assignee: - tim.golden

[issue9584] Allow curly brace expansion

Tim Golden added the comment: I'm planning to refactor the tests and the code very slightly. When I've got a reworked patch I'll ping it back to you to ensure it matches your intent. IIUC you're implementing comma-separated lists {abc,def} and nested braces {a{b,c}d,efg} but not ranges {a..z

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Attached is a refactored version of Mathieu's patch which, when applied to tip, passes all tests. -- Added file: http://bugs.python.org/file27894/0003-reworked-issue9584.patch ___ Python tracker rep...@bugs.python.org

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Something went wrong with that patch; it doesn't include all the changes to test_glob. I'll upload a newer patch later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9584

[issue9584] Allow curly brace expansion

Tim Golden added the comment: Scratch that last comment: the patch does apply. I've tested it against Windows Ubuntu. If no one comes in with any objections I'll commit it within the next day. -- ___ Python tracker rep...@bugs.python.org http

[issue16353] add function to os module for getting path to default shell

Tim Golden added the comment: On 02/11/2012 21:00, Andrew Svetlov wrote: I guess to return sh if supported, cmd.exe for Windows. FWIW the canonical approach on Windows is to return whatever %COMSPEC% points to. -- nosy: +tim.golden ___ Python

[issue16328] win_add2path.py sets wrong user path

Changes by Tim Golden m...@timgolden.me.uk: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16328 ___ ___ Python-bugs

[issue16328] win_add2path.py sets wrong user path

Tim Golden added the comment: [this response appears to have got lost in an email black hole somewhere] I assume that $PYTHONPATH is actually referring to sys.exec_prefix (and not the PYTHONPATH env var which has nothing to do with this). In any case c:\python27\scripts is still the place

Re: [issue16328] win_add2path.py sets wrong user path

I assume that $PYTHONPATH is actually referring to sys.exec_prefix (and not the PYTHONPATH env var which has nothing to do with this). In any case c:\python27\scripts is still the place for scripts. There is a c:\python27\tools\scripts (which you're welcome to add to your %PATH% if you find the

[issue16218] Python launcher does not support non ascii characters

Tim Golden added the comment: Confirming that this doesn't happen on 2.7 py -2 £.py succeeds py -3 £.py gives: python: failed to set __main__.__loader__ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218

[issue16246] Multiprocessing infinite loop on Windows

Tim Golden added the comment: The natural way to do this in windows is using the Job API: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161%28v=vs.85%29.aspx However I'm not sure where to apply this within the multiprocessing architecture (or if it's even a good idea

[issue16097] Minor fix in comment in codecs.py

Changes by Tim Golden m...@timgolden.me.uk: -- assignee: - tim.golden nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16097

[issue16097] Minor fix in comment in codecs.py

Tim Golden added the comment: Committed in bb77400af434. Thanks -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16097

[issue9035] os.path.ismount on windows doesn't support windows mount points

Tim Golden added the comment: Unfortunately this missed the boat for 3.3; I'll target 3.4 when we've got a branch to commit to. -- versions: +Python 3.4 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue6839] zipfile can't extract file

Changes by Tim Golden m...@timgolden.me.uk: -- assignee: tim.golden - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list

[issue15828] imp.load_module doesn't support C_EXTENSION type

Tim Golden added the comment: Paul, are you using the hg tip of pywin32? pywin32_postintall.py was patched a couple of months ago to use imp.load_dynamic (essentially to work around this issue). -- nosy: +tim.golden ___ Python tracker rep

[issue15496] harden directory removal for tests on Windows

Tim Golden added the comment: Fine with me -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496 ___ ___ Python-bugs-list mailing list

[issue15496] harden directory removal for tests on Windows

Tim Golden added the comment: I'm +1 on the approach in principle. I'm tentative about using ctypes for this just because I don't believe we use it anywhere else. But at the least I suggest applying the patch to see how Jeremy's buildbot behaves. If there are wider objections to ctypes we could

[issue15496] harden directory removal for tests on Windows

Tim Golden added the comment: This is a (near) duplicate of issue7443, I think. -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496

[issue15407] CSV parser fails to iterate properly on 2.6.6

Tim Golden m...@timgolden.me.uk added the comment: It already produces a TypeError with a specific message if the input is not iterable. You seem to be using a homegrown dialect; with the conventional list (csv.reader(the quick brown fox)) you very quickly see that you're iterating over a string

[issue15338] test_UNC_path failure in test_import

Tim Golden m...@timgolden.me.uk added the comment: Well os.listdir doesn't fail to access a UNC path on Windows x64 in general. So presumably this particular path is not accessible by the buildbot process owner? -- ___ Python tracker rep

[issue15338] test_UNC_path failure in test_import

Tim Golden m...@timgolden.me.uk added the comment: It's using an administrative share (\\server\d$) and those are usually restricted with share permissions -- different from NTFS permissions. That the process runs as a service is likely to have an effect since services are conventionally run

[issue15338] test_UNC_path failure in test_import

Tim Golden m...@timgolden.me.uk added the comment: For this particular buildbot setup, maybe yes. But it would be possible in principle to have a buildbot configuration which could allow the test to execute. (eg one running under a user account which can access the path via an admin share). Does

[issue15338] test_UNC_path failure in test_import

Tim Golden m...@timgolden.me.uk added the comment: My guess is that it's to do with Service Hardening. I did a quick dump of my token in an interactive session and as the owner of a service. Quite a few differences. I haven't read up on this area yet so I'm not sure what options there are / how

[issue15338] test_UNC_path failure in test_import

Tim Golden m...@timgolden.me.uk added the comment: Simplest solution might be to catch PermissionError and call skipTest from within. This would allow buildbots to run the test which had access through the relevant share. -- ___ Python tracker rep

[issue15334] access denied for HKEY_PERFORMANCE_DATA

Tim Golden m...@timgolden.me.uk added the comment: Take the other approach and catch ACCESS_DENIED and skip? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15334

[issue15334] access denied for HKEY_PERFORMANCE_DATA

Tim Golden m...@timgolden.me.uk added the comment: (I just ran up a service and its environ does include PROMPT, at least on an XP machine) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15334

[issue15267] tempfile.TemporaryFile and httplib incompatibility

Tim Golden m...@timgolden.me.uk added the comment: I can confirm that this isn't a problem for 3.x. No-one's listed in the experts list for the httplib module but Senthil appears to be the de factor maintainer so I've added him to the call for his opinion. My feeling would be to do

[issue15267] tempfile.TemporaryFile and httplib incompatibility

Tim Golden m...@timgolden.me.uk added the comment: Could you create a failing test, please, Tim S? -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15267

[issue15254] 08 is invalid token in lists.

Tim Golden m...@timgolden.me.uk added the comment: A 0 prefix to a number is taken by Python 2.x to introduce a series of octal (base 8) digits. You can't have 8 in base 8 so the number (and anything higher) is rejected. -- nosy: +tim.golden resolution: - rejected stage: - committed

[issue15254] 08 is invalid token in lists.

Changes by Tim Golden m...@timgolden.me.uk: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15254 ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: On 30/06/2012 06:45, Daniel Lenski wrote: My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options: delete=False # don't delete delete

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: On 01/07/2012 21:37, Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: And here's the patch against 3.2 (essentially the 2.7 patch but allowing for the removal of RISCOS support) -- Added file: http://bugs.python.org/file26207/issue1677-python32.patch ___ Python

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Changes by Tim Golden m...@timgolden.me.uk: Removed file: http://bugs.python.org/file26207/issue1677-python32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Changes by Tim Golden m...@timgolden.me.uk: Added file: http://bugs.python.org/file26208/issue1677-python32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: Tim, you've got tabs in your 3.3 patch. Thanks, Antoine. I'll sort that out. (Goodness know how; none of my editors use tabs). Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the other versions? Ummm. Because

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Changes by Tim Golden m...@timgolden.me.uk: -- resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677

[issue798876] windows sys.path contains nonexistant directory

Tim Golden m...@timgolden.me.uk added the comment: THis was fixed almost two years ago in Py3K. Won't fix for 2.7 -- resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: Daniel. If you have any interest in this issue, would you mind summarising the state of affairs, please? I have no direct interest in the result but I'm happy to commit a patch or even to work one up if somone can come up with a single

[issue4485] fast swap of default Windows python versions

Tim Golden m...@timgolden.me.uk added the comment: Effectively made redundant by PEP 397, implemented in 3.3 -- resolution: - wont fix stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue13792] The os.execl call doesn't give programs exit code

Tim Golden m...@timgolden.me.uk added the comment: Closing as it's been pending for six months and I see nothing further to add -- stage: - committed/rejected status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: Attached is a patch against Python 2.7. It checks in a loop for SIGINT and, if it still hasn't fired, assumed Ctrl-Z was pressed which generates the same error. -- assignee: - tim.golden keywords: +patch Added file: http

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: Yep. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677 ___ ___ Python-bugs-list mailing

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: To be clear: ERROR_OPERATION_ABORTED is set when Ctrl-Z is hit as the only thing on a line. If it's just an extra character then it operates like any other keypress. -- ___ Python tracker rep

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: This patch is for 2.7 and does enough to solve the issue without a major rework. The signal module onthe default branch has had a lot of love recently and I'll definitely make use of that for a 3.x patch

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: Nope. Ctrl-C also sets EOF -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677 ___ ___ Python

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: And here's a patch for the default branch, using the new sigint event as Kristan suggested. -- Added file: http://bugs.python.org/file26202/issue1677-python3x.patch ___ Python tracker rep

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: Just to confirm: I can reproduce this more or less consistently on all versions of Python 2.2 - 3.2 on Windows 7. Those are distribution builds -- ie not debug builds I've made myself. But it certainly does occur on a debug build of 2.7. I'm

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: OK, I've run out of time to look, but the culprit looks like it's an odd interaction between my_fgets in myreadline.c and the interrupt handler in signal. There's a section of code which is conditional on ERROR_OPERATION_ABORTED being

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: That'll be my next move when I get some more time. I've got someone coming over to see me (about real work!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Tim Golden m...@timgolden.me.uk added the comment: OK, it is a race condition between the code in myreadline.c and the signal_handler in signalmodule.c. It can take between 0 and 3 sleeps for the myreadline code to see the signal tripped. Patch on its way for 2.7; VS 2010 downloading so

[issue14452] SysLogHandler sends invalid messages when using unicode

Tim Golden m...@timgolden.me.uk added the comment: It's used by some systems (Windows Notepad does this if you save as UTF8) to indicate that the byte stream *is* UTF8-encoded. It's not so much a BOM as a magic cookie. I can't speak for syslog, I'm afraid TJG -- nosy: +tim.golden

[issue14420] winreg SetValueEx DWord type incompatible with value argument

Tim Golden m...@timgolden.me.uk added the comment: Brian - I think this is your area -- nosy: +brian.curtin, tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14420

[issue14112] tutorial intro talks of shallow copy concept without explanation

Tim Golden m...@timgolden.me.uk added the comment: On 25/02/2012 08:09, Ezio Melotti wrote: Even if they know the meaning of shallow (which is not a really common word AFAICT) FWIW it's pretty much the only way of saying what it means. I've no idea how many people used it last year

[issue13931] os.path.exists inconsistent between 32 bit and 64 bit

Tim Golden m...@timgolden.me.uk added the comment: This is the Windows x64 file system redirector at work. I can't get through to msdn at the moment to get a link, but Google for those terms. -- nosy: +tim.golden ___ Python tracker rep

<    1   2   3   4   5   6   7   >