[issue43805] multiprocessing.Queue hangs when process on other side dies

Thomas Kluyver added the comment: It's not my decision, so I can't really say. But the Queue API is pretty stable, and exists 3 times over in Python (the queue module for use with threads, in multiprocessing and in asyncio). So I'd guess that anyone wanting to add to that API would need

[issue43805] multiprocessing.Queue hangs when process on other side dies

Thomas Kluyver added the comment: I think this is expected. The queue itself doesn't know that one particular process is meant to put data into it. It just knows that there's no data to get, so .get() blocks as the docs say it should. This doesn't apply to issue22393, because the pool knows

[issue43806] asyncio.StreamReader hangs when reading from pipe and other process exits unexpectedly

Thomas Kluyver added the comment: In the example script, I believe you need to close the write end of the pipe in the parent after forking: cpid = os.fork() if cpid == 0: # Write to pipe (child) else: # Parent os.close(ctx) # Read from pipe This is the same with synchronous

[issue37612] os.link(..., follow_symlinks=True) broken on Linux

Change by Thomas Kluyver : -- nosy: +takluyver nosy_count: 4.0 -> 5.0 pull_requests: +23755 pull_request: https://github.com/python/cpython/pull/24997 ___ Python tracker <https://bugs.python.org/issu

[issue24916] In sysconfig, don't rely on sys.version format

Thomas Kluyver added the comment: Serhiy, I think you fixed the part that was actually likely to cause problems a few years ago in issue #25985 & commit 885bdc4946890f4bb80557fab80c3874b2cc4d39 . Using sys.version[:3] to get a short version like 3.8 was what I wanted to fix. Pe

[issue36695] Change (regression?) in v3.8.0a3 doctest output after capturing the stderr output from a raised warning

Thomas Kluyver added the comment: D'oh, yes. I missed that the failing example was displaying the captured string through displayhook. It makes sense now. Thanks for patiently explaining. :-) -- ___ Python tracker <https://bugs.python.

[issue36695] Change (regression?) in v3.8.0a3 doctest output after capturing the stderr output from a raised warning

Thomas Kluyver added the comment: The 'single' option to compile() means it's run like at a REPL, calling displayhook if it's an expression returning a value. But warnings shouldn't go through the displayhook, as far as I know: >>> from contextlib import redirect_stdout, redire

[issue36695] Change (regression?) in v3.8.0a3 doctest output after capturing the stderr output from a raised warning

Thomas Kluyver added the comment: I'm still a bit confused why it gets escaped - as far as I know, the escaping only happens when you repr() a string, as the displayhook does automatically: >>> a = """ a ' single and " double quote """ >>>

[issue36695] Change (regression?) in v3.8.0a3 doctest output after capturing the stderr output from a raised warning

Thomas Kluyver added the comment: It's not obvious to me why that change to finding the source file related to the warning should affect the format of the warning message printed. It might be something that could be fixed in the warning module. But I don't understand where it's going wrong

[issue36691] SystemExit & sys.exit : Allow both exit status and message

New submission from Thomas Kluyver : The SystemExit exception, and consequently the sys.exit() function, take a single parameter which is either an integer exit status for the process, or a message to print to stderr before exiting - in which case the exit status is implicitly 1

[issue33944] Deprecate and remove pth files

Thomas Kluyver added the comment: As a lurker on this issue: I think a lot of energy is being expended arguing about what is and isn't legitimate use cases, when there's actually more stuff that people agree about than not. I think this issue should be broken down into two, neither of which

[issue28418] Raise Deprecation warning for tokenize.generate_tokens

Thomas Kluyver added the comment: Yes, I think this can be closed now. -- ___ Python tracker <https://bugs.python.org/issue28418> ___ ___ Python-bugs-list mailin

[issue33944] Deprecate and remove pth files

Thomas Kluyver added the comment: I don't want to use the execution features of .pth files, just their original functionality of adding extra directories to sys.path. I'd be very happy to see the arbitrary code execution 'feature' of .pth files go away. Windows supports symlinks

[issue33944] Deprecate and remove pth files

Thomas Kluyver added the comment: I'm generally in favour of getting rid of .pth files. But I did accept a PR adding support for them in Flit to act as a substitute for symlinks on Windows, to achieve something like a 'development install'. I'm not sure what the alternative is if they go

[issue33912] [EASY] test_warnings: test_exec_filename() fails when run with -Werror

Thomas Kluyver added the comment: Yes, this should be easy. I misunderstood how to use the catch_warnings context manager. I thought that catch_warnings itself set up the warnings filters you need. You actually need to do that with a separate call inside the with block, as shown here

[issue12486] tokenize module should have a unicode API

Thomas Kluyver added the comment: Thanks Carol :-) -- ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12486] tokenize module should have a unicode API

Thomas Kluyver added the comment: The tests on PR #6957 are passing now, if anyone has time to have a look. :-) -- ___ Python tracker <https://bugs.python.org/issue12

[issue12486] tokenize module should have a unicode API

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Thanks - I had forgotten it, just fixed it now. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue12486] tokenize module should have a unicode API

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I agree, it's not a good design, but it's what's already there; I just want to ensure that it won't be removed without a deprecation cycle. My PR makes no changes to behaviour, only to documentation and tests. This and issue 996

[issue12486] tokenize module should have a unicode API

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I wouldn't say it's a good name, but I think the advantage of documenting an existing name outweighs that. We can start (or continue) using generate_tokens() right away, whereas a new name presumably wouldn't be available until

[issue28418] Raise Deprecation warning for tokenize.generate_tokens

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I've opened a PR moving in the other direction (making this public rather than deprecating it): https://github.com/python/cpython/pull/6957 -- nosy: +takluyver ___ Python tracke

[issue9969] tokenize: add support for tokenizing 'str' objects

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I've opened a PR for issue #12486, which would make the existing but undocumented 'generate_tokens' function public: https://github.com/python/cpython/pull/6957 I agree that it would be good to design a nic

[issue12486] tokenize module should have a unicode API

Change by Thomas Kluyver <tho...@kluyver.me.uk>: -- pull_requests: +6616 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue12486> ___

[issue33375] warnings: get filename from frame.f_code.co_filename

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Thanks! No rush, I just thought I'd take the opportunity when you added yourself to the nosy list. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33375] warnings: get filename from frame.f_code.co_filename

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Hi Brett! If you get a moment, any review of the linked PR would be welcome. :-) https://github.com/python/cpython/pull/6622 -- ___ Python tracker <rep...@bugs.python.or

[issue33375] warnings: get filename from frame.f_code.co_filename

Change by Thomas Kluyver <tho...@kluyver.me.uk>: -- keywords: +patch pull_requests: +6318 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue1692664] warnings.py gets filename wrong for eval/exec

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Thanks Guido, the new issue is #33375. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.o

[issue33375] warnings: get filename from frame.f_code.co_filename

New submission from Thomas Kluyver <tho...@kluyver.me.uk>: The warnings module tries to find and show the line of code which is responsible for a warning, for the same reasons that tracebacks show a line of code from each stack frame. However, they work in quite different ways.

[issue1692664] warnings.py gets filename wrong for eval/exec

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Time for some bug archaeology! The reason given for not using frame.f_code.co_filename for warnings was that it can be wrong when the path of .pyc files changes. However, it looks like that was fixed in #1180193 (thanks for the p

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: If every Windows 7 computer is generating zipfiles which are invalid in this way, that would be a pretty strong argument for Python (and other tools) to accept it. But if that was the case, I would also expect that there would be

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I found source code for some other projects handling the same data. They all seem to agree that it should be 1: - Golang's zip reading code: https://github.com/golang/go/blob/f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archi

[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Do you know what tool created the zip file? I can't find anything in the spec (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT ) to say whether 0 is a valid value for the number of disks. -- nosy: +tak

[issue12486] tokenize module should have a unicode API

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: > Why not just bless the existing generate_tokens() function as a public API We're actually using generate_tokens() from IPython - we wanted a way to tokenize unicode strings, and although it's undocumented, it's been there for

[issue32699] pythonXY._pth : unclear how .pth files are handled

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: Thanks Steve, that looks good. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32699] pythonXY._pth : unclear how .pth files are handled

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I'd reword the second sentence like this: > Note that .pth files (without leading underscore) will be processed only if > this file specifies ``import site``. The current wording sounds (to me) like a guarantee tha

[issue32699] pythonXY._pth : unclear how .pth files are handled

New submission from Thomas Kluyver <tho...@kluyver.me.uk>: Nicholas Tollervey has been getting Pynsist to use the new pythonXY._pth file to assemble sys.path. However, I'm not clear on how this behaves with .pth files. The docs on this (https://docs.python.org/3/using/windows.html#f

[issue32247] shutil-copytree: Create dst folder only if it doesn't exist

Thomas Kluyver <tho...@kluyver.me.uk> added the comment: This is documented: > The destination directory, named by dst, must not already exist https://docs.python.org/3/library/shutil.html#shutil.copytree I guess that avoids complications that might arise from merging a

[issue30639] inspect.getfile(obj) calls object repr on failure

Thomas Kluyver added the comment: OK, I've updated the PR to do that. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30639> ___ __

[issue30639] inspect.getfile(obj) calls object repr on failure

Thomas Kluyver added the comment: Sure, I can do that if you want. The other thing I thought of was using object.__repr__, so the repr always shows like . -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue30639] inspect.getfile(obj) calls object repr on failure

Changes by Thomas Kluyver <tho...@kluyver.me.uk>: -- pull_requests: +2186 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30639> ___

[issue30639] inspect.getfile(obj) calls object repr on failure

Thomas Kluyver added the comment: Not exactly a bug, but I think that an improvement is possible. My plan is to delay computing the repr until the error is formatted, so that code which catches the TypeError can carry on safely. I think this is more relevant for inspect than for many other

[issue30639] inspect.getfile(obj) calls object repr on failure

New submission from Thomas Kluyver: This came up in IPython & Jedi: several functions in inspect end up calling getfile(). If the object is something for which it can't find the source file, it throws an error, the message for which contains the object's repr. This is problematic fo

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Thomas Kluyver added the comment: I could go either way on that. It's not hard to imagine it as a recursive algorithm, and using the recursion limit provides a simple configuration escape hatch if someone has a desperate need for something wrapped 3000 times for some strange reason

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Thomas Kluyver added the comment: This was just reported in IPython as well (https://github.com/ipython/ipython/issues/10578 ). I've prepared a pull request based on Nick's proposal: https://github.com/python/cpython/pull/1717 -- nosy: +takluyver

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Changes by Thomas Kluyver <tho...@kluyver.me.uk>: -- pull_requests: +1806 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25532> ___

[issue29622] ast module doesn't support optional fields of Parser/Python.asdl

Changes by Thomas Kluyver <tho...@kluyver.me.uk>: -- nosy: +takluyver ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29622> ___ _

[issue13285] signal module ignores external signal changes

Thomas Kluyver added the comment: I pitched both the opaque handle and the context manager to python-ideas, but didn't get any responses, positive or negative. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue13285] signal module ignores external signal changes

Thomas Kluyver added the comment: I'd like to make the case for a fix in the code again. Our use case is, I believe, the same as Vilya's. We want to temporarily set a signal handler from Python and then restore the previous handler. This is fairly straightforward for Python handler functions

[issue27050] Demote run() below the high level APIs in subprocess docs

Thomas Kluyver added the comment: I still feel that having one function with various options is easier to explain than three separate functions with awkward names and limited use cases (e.g. no capturing output without checking the exit code). The tweeter you replied to said he didn't like

[issue28528] Pdb.checkline()

New submission from Thomas Kluyver: Pdb.checkline() does a hasattr() check to protect against self.curframe not existing. self.curframe can also be None (if self.forget() or self.reset() was called), but checkline() does not handle this. The attached patch treats self.curframe == None

[issue28384] hmac cannot be used with shake algorithms

Changes by Thomas Kluyver <tho...@kluyver.me.uk>: -- nosy: +takluyver ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28384> ___ _

[issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

Thomas Kluyver added the comment: Does Py_DECREF(arglist); need to be called in all cases? I'm genuinely unsure, as I don't usually work on C code, but my guess would be that it does. I'm not sure whether review is now done on Github. -- ___ Python

[issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

Thomas Kluyver added the comment: It's waiting for someone to make a patch - I'm no longer running into it, so it's not high on my priority list. Given that it's been over a year since I created this issue, it's probably not about to get fixed unless you've got some time to work

[issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

Thomas Kluyver added the comment: As far as I know it has not been fixed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue27113] sqlite3 connect parameter "check_same_thread" not documented

Thomas Kluyver added the comment: Congrats! :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list

[issue27113] sqlite3 connect parameter "check_same_thread" not documented

Thomas Kluyver added the comment: That comment contained far too much 'probably'. Time for me to sleep... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue27113] sqlite3 connect parameter "check_same_thread" not documented

Thomas Kluyver added the comment: Having watched the video of Dave's PyCon talk (thanks Dave), I think he's talking about using locking to control transactions, which presumably the sqlite bindings don't handle by themselves. But I don't *think* you need manual locking just to maintain

[issue27113] sqlite3 connect parameter "check_same_thread" not documented

Changes by Thomas Kluyver <tho...@kluyver.me.uk>: -- nosy: +takluyver ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27113> ___ _

[issue27050] Demote run() below the high level APIs in subprocess docs

Thomas Kluyver added the comment: I'm obviously biased, but I find the 'high level convenience API' less convenient than the run() function: there are three different functions for the same basic operation, they're not clearly named (check_output is nothing to do with checking output

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: The backported package now exists on PyPI as zipfile36. It's passing the tests on 3.4 - I haven't tested further back. I'm trying out Gitlab for hosting it: https://gitlab.com/takluyver/zipfile36 -- ___ Python

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Updated version of the patch with the detail moved to rst. -- Added file: http://bugs.python.org/file42855/zipfile-flex-bonus2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Patch attached for points 2 and 3 -- Added file: http://bugs.python.org/file42851/zipfile-flex-bonus.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: 1. For the cases like read/write handles conflicting, ValueError doesn't seem quite right to me - I take ValueError to mean that you have passed an invalid value to a function. RuntimeError feels like the closest fit for 'the current state does not allow

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Thanks Serhiy! I am marking this as fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Thanks Serhiy. I'm quite happy with that set of constraints. I had a look over your patch set, and just spotted one thing in writestr that I have overlooked all along. -- ___ Python tracker <rep...@bugs.python.

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Ping? Once this is landed, I intend to make a backport package of it so I can start using it before Python 3.6 comes out. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Any further review comments on this? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26039> ___ __

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: zipfile-open-w8 removes the concurrent read-write check for non-seekable files. As Martin points out, reading currently requires seeking, and a streaming read API would look very different from the current API. -- Added file: http://bugs.python.org

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: zipfile-open-w7 adds a test that Martin requested -- Added file: http://bugs.python.org/file42597/zipfile-open-w7.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: It wasn't as bad as I thought (hopefully that doesn't mean I've missed something). zipfile-open-w6.patch allows interleaved reads and writes so long as the underlying file object is seekable. You still can't have multiple write handles open (it wouldn't know

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Martin, Serhiy: Am I right that it would be unacceptable to change the test, and I therefore need to find a way to allow writestr while a reading-mode handle is open? -- ___ Python tracker <rep...@bugs.python.

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Sorry for the delay, this fell off my radar because emails from both the bug tracker and Rietveld tend to fall foul of my spam filters, so I have to go and check. I have implemented Serhiy's suggestions, but there turns out to be a test

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Serhiy, have you had a chance to look at what the zf.open(mode='w') patch does with the lock? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Oh, I see test_interleaved now, which does test overlapping reads of two files from the same zip file. Do you want that clarified in the docs - which don't currently mention the lock at all - or in a comment in the module

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: My initial patch would have allowed passing a readable file-like object into zipfile. I was persuaded that allowing ZipFile.open() to return a writable object was a more intuitive and flexible API. Concurrent writes with zf.open(mode='w') should be impossible

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Ping! ;-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26039> ___ ___ Python-bugs-list

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Hi Serhiy, any more comments on the zf.open() patch? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Thanks Serhiy! I'll keep an eye out for comments on the other patch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Is there anything more I should be doing with either of these patches? I think I've incorporated all review comments I've seen. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue22107] tempfile module misinterprets access denied error on Windows

Thomas Kluyver added the comment: This issue was closed, but I believe the original bug reported was not fixed: trying to create a temporary file in a directory where you don't have write permissions hangs for a long time before failing with a misleading FileExistsError, rather than failing

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Updated version of the ZipInfo.from_file() patch attached. -- Added file: http://bugs.python.org/file41758/zipinfo-from-file5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Here's a new version of the zf.open() patch following Martin's review (thanks Martin!). I agree that it feels a bit awkward having two completely different actions for zf.open(), but it is a familiar interface, and since the mode parameter is already

[issue26039] More flexibility in zipfile interface

Changes by Thomas Kluyver <tak...@gmail.com>: Added file: http://bugs.python.org/file41753/zipinfo-from-file3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Thanks Serhiy for review comments. -- Added file: http://bugs.python.org/file41754/zipinfo-from-file4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: The '2' versions of the two different patches include some docs and tests for these new features. -- Added file: http://bugs.python.org/file41726/zipfile-open-w2.patch ___ Python tracker <rep...@bugs.python.

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Serhiy, any chance you'd have some time to review my patch(es)? Or is there someone else interested in zipfile I might interest? Thanks :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Thanks! I will work on docs and tests. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26039> ___ __

[issue26039] More flexibility in zipfile interface

Changes by Thomas Kluyver <tak...@gmail.com>: Added file: http://bugs.python.org/file41722/zipinfo-from-file2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue8604] Adding an atomic FS write API

Thomas Kluyver added the comment: For reference, we added our own atomic_writing() context manager in Jupyter/IPython, after someone lost work when save failed on a full disk. We initially went for the same approach - write to a temporary file, fsync, rename over the original file

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: zipinfo-from-file.patch has an orthogonal but related change: the code in ZipFile.write() to construct a ZipInfo object from a filesystem file is pulled out to a classmethod ZipInfo.from_file(). Together, these changes make it much easier to control how

[issue18595] zipfile: symlinks etc.

Changes by Thomas Kluyver <tak...@gmail.com>: -- nosy: +takluyver ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18595> ___ __

[issue26039] More flexibility in zipfile interface

Thomas Kluyver added the comment: Attached is a first go at a patch enabling zipfile.open(blah, mode='w') Files must be written sequentially, so you have to close one writing handle before opening another. If you try to open a second one before closing the first, it will raise RuntimeError. I

[issue23936] Wrong references to deprecated find_module instead of find_spec

Thomas Kluyver added the comment: Updated patch attached, responding to Martin's suggestions. I'm not quite sure what to do about the 'finder' glossary entry. 'Finder' now seems to be a more abstract classification covering two distinct kinds of thing: *meta path finders* and *path entry

[issue23936] Wrong references to deprecated find_module instead of find_spec

Thomas Kluyver added the comment: That's basically what I was aiming for. Should the description be briefer and more generic? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue23936] Wrong references to deprecated find_module instead of find_spec

Thomas Kluyver added the comment: Thanks Brett :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23936> ___ ___ Python-bugs-

[issue23936] Wrong references to deprecated find_module instead of find_spec

Thomas Kluyver added the comment: Third revision of patch responding to Brett's suggestions. -- Added file: http://bugs.python.org/file41240/finders_and_specs3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue23936] Wrong references to deprecated find_module instead of find_spec

Thomas Kluyver added the comment: I also ran into confusion with this while trying to write an import hook. Attached is my shot at a docs patch. I've done a slightly larger rewording, trying to make it easier to understand, and added more links between parts of the docs. I left mentions

[issue25078] Document InstallAllUsers installer parameter default 0

New submission from Thomas Kluyver: In testing the 3.5.0rc4 default installer, I found that the default for InstallAllUsers appears to be 0, whereas it's currently documented as 1. -- assignee: docs@python components: Documentation files: installallusers-default.patch keywords: patch

[issue24916] In sysconfig, don't rely on sys.version format

New submission from Thomas Kluyver: sysconfig currently calculates various formats of the Python version number by chopping up the sys.version string. This has a FIXME by it in the code, because the the format of sys.version is not guaranteed. With this patch, the config variables 'py_version

[issue24609] shutil.copytree fails with symlinks to directories when symlink=False

New submission from Thomas Kluyver: shutil.copytree behaves differently with symlinks depending on the 'symlinks' parameter. If this is True, symlinks are replicated in the destination. If False, the contents of the targets are copied to the destination. With symlinks=False, it currently

  1   2   3   >