[issue13099] Sqlite3 & turkish locale
New submission from Thomas Kluyver : When using sqlite3 with the Turkish locale, cursor.lastrowid is not accessible after an insert statement if "INSERT" is upper case. I believe that the cause is that the detect_statement_kind function [1] calls the locale-dependent C function tolower(). The Turkish locale specifies a different case mapping for I (to a dotless lowercase i: ı), so it's not recognised as an insert statement, which looks like it will cause the transaction to be committed immediately. See also the discussion on issue 1813 [2], and a Redhat bug with a test case for this [3]. [1] http://hg.python.org/cpython/file/c4b6d9312da1/Modules/_sqlite/cursor.c#l41 [2] http://bugs.python.org/issue1813 [3] https://bugzilla.redhat.com/show_bug.cgi?id=720209 -- components: Extension Modules messages: 144873 nosy: takluyver priority: normal severity: normal status: open title: Sqlite3 & turkish locale versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13099] Sqlite3 & turkish locale
Thomas Kluyver added the comment: What form does the test need to be in? There's a script at the redhat bug I linked that demonstrates the issue. Do I need to turn it into a function? A patch for the existing test suite? -- type: behavior -> ___ Python tracker <http://bugs.python.org/issue13099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13099] Sqlite3 & turkish locale
Thomas Kluyver added the comment: Thanks, Antoine. Should I still try to write a regression test for it? -- ___ Python tracker <http://bugs.python.org/issue13099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13692] 2to3 mangles from . import frobnitz
Thomas Kluyver added the comment: A couple of things to note: - This was with the Python 3.1 implementation of 2to3 - the problem doesn't appear with the Python 3.2 version. - The import statement in question was inside a method definition. I wonder if the extra two dots correspond to the class and method scopes. -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue13692> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9969] tokenize: add support for tokenizing 'str' objects
Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue9969> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11679] readline interferes with characters beginning with byte \xe9
New submission from Thomas Kluyver :
To replicate, in Python 3.1 on Linux (utf-8 console):
>>> print(chr(0x9000))
退
Copy and paste this character into the prompt. It appears correctly (as a
Chinese character). Then:
>>> import readline
>>> readline.parse_and_bind('"\M-i":""')
Now try to paste the character again: it appears as "��"
(four spaces, two unknown character symbols), and if you press return, you get
a SyntaxError.
This happens with all characters beginning with \xe9: In UTF-8, that's
0x9000-0x9fff. If the terminal encoding is changed to cp1252, I'm told that the
same thing can be achieved with é, which is \xe9 there.
--
components: Unicode
messages: 132192
nosy: takluyver
priority: normal
severity: normal
status: open
title: readline interferes with characters beginning with byte \xe9
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue11679>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue37612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 code: os.read(prx, 1) also hangs. You only get EOF when nothing has the write end open any more. All the asyncio machinery doesn't really make any difference to this. For a similar reason, the code writing (the child, in this case) should close the read end of the pipe after forking. If the parent goes away but the child still has the read end open, then trying to write to the pipe can hang (if the buffer is already full). If the child has closed the read end, trying to write will give you a BrokenPipeError. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue43806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 about its worker processes, so if one dies before completing a task, it can know something is wrong. You could add a method to 'half close' a queue, so it can only be used for receiving, but not sending. If you called this in the parent process after starting the child, then if the child died, the queue would know that nothing could ever put data into it, and .get() could error. The channels API in Trio allows this, and it's the same idea I've just described at the OS level in issue43806. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue43805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to make a compelling case for why it's important, and be prepared for a lot of wrangling over API details (like method names and exceptions). If you want to push that idea, you could try the ideas board on the Python discourse forum: https://discuss.python.org/c/ideas/6 . You might also want to look at previous discussions about adding a Queue.close() method: issue29701 and issue40888. -- ___ Python tracker <https://bugs.python.org/issue43805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. People are presumably still trying to change the other bits because there's still a FIXME comment. If we're happy with the current code, I think we can remove that comment and close the issue. -- ___ Python tracker <https://bugs.python.org/issue24916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Changes by Thomas Kluyver : -- pull_requests: +1806 ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. But it may also be somewhat surprising if someone sets a really high recursion limit and suddenly it behaves oddly. I've made the PR with getrecursionlimit() for now, but I'm happy to change it if people prefer it the other way. -- ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for us because for some objects the repr may be expensive to calculate (e.g. data tables where the repr forms primary output, not just debugging information). In some cases, it could also throw another error. I plan to make a PR for this, but I'm opening an issue so I've got a bpo number. https://github.com/ipython/ipython/issues/10493 https://github.com/davidhalter/jedi/issues/919 -- components: Library (Lib) messages: 295782 nosy: takluyver priority: normal severity: normal status: open title: inspect.getfile(obj) calls object repr on failure type: behavior ___ Python tracker <http://bugs.python.org/issue30639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 modules, because by design, we're often calling inspect functions on arbitrary objects which we can make few guarantees about. -- ___ Python tracker <http://bugs.python.org/issue30639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30639] inspect.getfile(obj) calls object repr on failure
Changes by Thomas Kluyver : -- pull_requests: +2186 ___ Python tracker <http://bugs.python.org/issue30639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue30639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue30639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 will actually result in removing pth files: 1. Better ways to inspect and control the sys.path extension feature (as per Barry's message https://bugs.python.org/issue33944#msg337417 ). 2. Designing a replacement for the arbitrary-code-at-startup feature (or even several replacements to meet different needs), leading to its eventual deprecation. If you like the ability for packages to install interpreter-startup hooks, then pth files are an ugly way to do it. If you don't, then you want better ways to control it. So let's see what we can come up with. At least several important use cases (coverage and debugging) would probably work with an environment variable to specify startup code. The coverage hooks already check an environment variable themselves, so it's clearly a control mechanism that works. It's also familiar from things like LD_PRELOAD that environment variables can affect code in powerful ways. But the PYTHONSTARTUP variable is not suitable for this, because it only affects interactive shell sessions. So maybe one useful step would be to specify a new environment variable, maybe PYTHONPRELOAD, and figure out how it will interact with all the other options. Then we can re-evaluate the use cases Anthony described (https://bugs.python.org/issue33944#msg337406 ) and debate the need for other startup-code mechanisms to go along with that. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. In certain situations, it would be useful to pass both an exit status and a message. E.g. when argparse handles '--help', it wants to display a message and exit successfully (status 0). You may also use specific exit codes to indicate different kinds of failure. Printing the message separately before raising SystemExit is not an entirely satisfactory subsitute, because the message attached to the exception is only printed if it is unhandled. E.g. for testing code that may raise SystemExit, it's useful to have the message as part of the exception. I imagine that the trickiest bit of changing this would be ensuring as much backwards compatibility as possible. In particular, SystemExit exceptions have a 'code' attribute which can be either the exit status or the message. -- messages: 340607 nosy: takluyver priority: normal severity: normal status: open title: SystemExit & sys.exit : Allow both exit status and message type: enhancement ___ Python tracker <https://bugs.python.org/issue36691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 at present. -- ___ Python tracker <https://bugs.python.org/issue36695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 """
>>> a
' a \' single and " double quote '
>>> print(repr(a))
' a \' single and " double quote '
>>> print("%r" % a)
' a \' single and " double quote '
>>> print(a)
a ' single and " double quote
The warnings code doesn't appear to ever repr() the message. So I guess it's
some further bit of interaction with doctest. But unfortunately I don't have
time to dig through doctest to try and understand it.
--
___
Python tracker
<https://bugs.python.org/issue36695>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, redirect_stderr
>>> from io import StringIO
>>> sio = StringIO()
>>> with redirect_stderr(sio):
... exec(compile('import warnings; warnings.warn(""" \' " """)', 'dummyfile',
'single'))
...
>>> print(sio.getvalue())
__main__:1: UserWarning: ' "
--
___
Python tracker
<https://bugs.python.org/issue36695>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue36695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32699] pythonXY._pth : unclear how .pth files are handled
New submission from Thomas Kluyver : 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#finding-modules ) appear to contradict themselves: > site is not imported unless one line in the file specifies import site > ... > Note that .pth files (without leading underscore) will be processed normally > by the site module. I can see two possibilities: 1. .pth files are processed normally if and only if the ._pth file specifies 'import site'. If it doesn't, they are ignored. 2. If a .pth file is encountered, site is imported to process it, but with sys.flags.nosite set, so that site doesn't do the normal stuff on import. Some packages unfortunately seem to depend on .pth files getting processed, so if 1. is the case, Pynsist needs to ensure site is loaded. Thanks :-) -- messages: 310980 nosy: steve.dower, takluyver priority: normal severity: normal status: open title: pythonXY._pth : unclear how .pth files are handled ___ Python tracker <https://bugs.python.org/issue32699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32699] pythonXY._pth : unclear how .pth files are handled
Thomas Kluyver 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 that .pth files will still be handled, despite the other things that this mechanism switches off. -- ___ Python tracker <https://bugs.python.org/issue32699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32699] pythonXY._pth : unclear how .pth files are handled
Thomas Kluyver added the comment: Thanks Steve, that looks good. -- ___ Python tracker <https://bugs.python.org/issue32699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
Thomas Kluyver 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 a number of releases and does what we want. So +1 to promoting it to a public API. In fact, at the moment, IPython has its own copy of tokenize to fix one or two old issues. I'm trying to get rid of that and use the stdlib module again, which is how I came to notice that we're using an undocumented API. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator
Thomas Kluyver 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: +takluyver ___ Python tracker <https://bugs.python.org/issue22102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator
Thomas Kluyver 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/archive/zip/reader.go#L536-L538
- A C contrib file with zlib:
https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624
- Code from Info-ZIP, which is used by many Linux distros, is a bit less clear,
but it has an illuminating comment:
if ((G.ecrec.number_this_disk != 0x) &&
(G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
/* Note: For some unknown reason, the developers at PKWARE decided to
store the "zip64 total disks" value as a counter starting from 1,
whereas all other "split/span volume" related fields use 0-based
volume numbers. Sigh... */
So I think you've got an invalid zip file. If it's otherwise valid, there might
be a case for Python tolerating that particular mistake. But it's probably
better to fix whatever is making the incorrect zip file, because other tools
are also going to reject it.
--
___
Python tracker
<https://bugs.python.org/issue22102>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22102] Zipfile generates Zipfile error in zip with 0 total number of disk in Zip64 end of central directory locator
Thomas Kluyver 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 many more issues about it. Are the files you're compressing large (multi-GB)? Python only uses the zip64 format when the files are too big for the older zip format; maybe Windows is doing the same. Even in that case, I'm still surprised that more people don't hit it. -- ___ Python tracker <https://bugs.python.org/issue22102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692664] warnings.py gets filename wrong for eval/exec
Thomas Kluyver 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 pointer zseil), so I'd like this idea to be reconsidered. Python uses frame.f_code.co_filename for tracebacks and in pdb, so it's counterintuitive that the warnings module works differently. They are all trying to do the same thing: find and show the bit of code that you're interested in. This causes problems in IPython with warnings attributed to interactive code: warnings sees it all as part of the __main__ module, so we can't distinguish which input it's pointing to (it's usually obvious, but still...). We have integrated with linecache to make tracebacks work, and I think that if warnings used code.co_filename, it would also work as expected. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue1692664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33375] warnings: get filename from frame.f_code.co_filename
New submission from Thomas Kluyver :
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.
Native tracebacks, the traceback module and pdb all do something like this:
frame.f_code.co_filename
But warnings does something like this (paraphrasing C code in _warnings.c):
frame.f_globals.get('__file__', sys.argv[0])
This causes problems for interactive interpreters like IPython, because there
are multiple pieces of entered code which have to share the same global
namespace. E.g. https://github.com/ipython/ipython/issues/11080
This was raised a long time ago in #1692664. Back then, the answer was that
co_filename could be wrong if the path of a pyc file changed. However, that
issue was fixed in #1180193. And it seems that the co_filename approach must
largely work today, because tracebacks and pdb rely on it.
So I'm proposing to make warnings match how those other tools find filenames. I
think this should also be a minor simplification of the code.
--
components: Library (Lib)
messages: 315848
nosy: takluyver
priority: normal
severity: normal
status: open
title: warnings: get filename from frame.f_code.co_filename
___
Python tracker
<https://bugs.python.org/issue33375>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692664] warnings.py gets filename wrong for eval/exec
Thomas Kluyver added the comment: Thanks Guido, the new issue is #33375. -- ___ Python tracker <https://bugs.python.org/issue1692664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33375] warnings: get filename from frame.f_code.co_filename
Change by Thomas Kluyver : -- keywords: +patch pull_requests: +6318 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33375] warnings: get filename from frame.f_code.co_filename
Thomas Kluyver 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 <https://bugs.python.org/issue33375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33375] warnings: get filename from frame.f_code.co_filename
Thomas Kluyver added the comment: Thanks! No rush, I just thought I'd take the opportunity when you added yourself to the nosy list. -- ___ Python tracker <https://bugs.python.org/issue33375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32247] shutil-copytree: Create dst folder only if it doesn't exist
Thomas Kluyver 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 directory. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue32247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
Change by Thomas Kluyver : -- pull_requests: +6616 ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9969] tokenize: add support for tokenizing 'str' objects
Thomas Kluyver 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 nicer API for this, but the perfect shouldn't be the enemy of the good. -- ___ Python tracker <https://bugs.python.org/issue9969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28418] Raise Deprecation warning for tokenize.generate_tokens
Thomas Kluyver 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 tracker <https://bugs.python.org/issue28418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
Thomas Kluyver 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 Python 3.8 comes out. And we usually don't require a new Python version until a couple of years after it is released. If we want to add better names or clearer APIs on top of this, great. But I don't want that discussion to hold up the simple step of committing to keep the existing API. -- ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
Thomas Kluyver 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 9969 have both been around for several years. A new tokenize API is clearly not at the top of anyone's priority list - and that's fine. I'd rather have *some* unicode API today than a promise of a nice unicode API in the future. And it doesn't preclude adding a better API later, it just means that the existing API would have to have a deprecation cycle. -- ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
Thomas Kluyver added the comment: Thanks - I had forgotten it, just fixed it now. -- ___ Python tracker <https://bugs.python.org/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue12486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://docs.python.org/3/library/warnings.html#testing-warnings -- ___ Python tracker <https://bugs.python.org/issue33912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 away. -- nosy: +takluyver ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, but the last I heard was that creating them requires some obscure permission bit. It seems to be awkward enough that Windows users aren't happy with the "just use symlinks" approach, which was what I was originally trying. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
New submission from Thomas Kluyver :
With the text 'abc€' copied to the clipboard, on Linux, where UTF-8 is the
default encoding:
Python 3.2.3 (default, Apr 12 2012, 21:55:50)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> root = tkinter.Tk()
>>> root.clipboard_get()
'abcâ\x82¬'
>>> 'abc€'.encode('utf-8').decode('latin-1')
'abcâ\x82¬'
I see the same behaviour in 2.7.3 as well (it returns a unicode string
u'abc\xe2\x82\xac').
If the clipboard is only accessible at a bytes level, I think clipboard_get
should return a bytes object. But I can reliably copy and paste non-ascii
characters between programs, so it looks like it's possible to return unicode.
--
components: Tkinter
messages: 160378
nosy: takluyver
priority: normal
severity: normal
status: open
title: Tkinter clipboard_get() decodes characters incorrectly
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue14777>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: On this computer, I see this from Tcl: $ wish % clipboard get abc\u20ac But here Python's following suit: >>> root.clipboard_get() 'abc\\u20ac' Which is odd, because as far as I know, my two computers run the same OS (Ubuntu 12.04) in the same configuration. I briefly thought the presence of xsel might be affecting it, but uninstalling it doesn't seem to make any difference. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: OK, after a quick bit of reading, I see why I'm confused: the clipboard actually works by requesting the text from the source program, so where you copy it from makes a difference. In my case, copying from firefox gives 'abc\\u20ac', and copying from Geany gives u'abc\xe2\x82\xac'. However, I still think there's something that can be improved in Python. As Serhiy points out, specifying type='UTF8_STRING' makes it work properly from both programs. The Tcl documentation recommends this as the best option for "modern X11 systems"[1]. >From what Ned says, we can't make UTF8_STRING the default everywhere, but is >there a way to detect if we're inside X11, and use UTF8_STRING by default >there? [1] http://www.tcl.tk/man/tcl/TkCmd/clipboard.htm -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: Thanks, Ned. Does it seem like a good idea to test the windowing system like that, and default to UTF8_STRING if it's x11? So far, I've not found any case on X where STRING works but UTF8_STRING doesn't. If it seems reasonable, I'm happy to have a go at making a patch. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: Here's a patch that makes UTF8_STRING the default type for clipboard_get and selection_get when running in X11. -- keywords: +patch Added file: http://bugs.python.org/file25552/x11-clipboard-utf8.patch ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: Indeed, and there don't seem to be any other tests for the clipboard functionality. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: But the encoding used seemingly depends on the source application - Geany (GTK 2, I think) seemingly sends UTF8 text anyway, whereas Firefox escapes the unicode character. So I don't think we can correctly decode the STRING value in all cases. The Tk documentation describes UTF8_STRING as being the "most useful" type on modern X11. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: OK, I'll produce an updated patch. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: As requested, the second version of the patch (x11-clipboard-try-utf8): - Caches the windowing system per object. The tk call to find the windowing system is made the first time clipboard_get or selection_get are called without specifying `type=`. - If using UTF8_STRING throws an error, it falls back to the default call with no type specified (i.e. STRING). -- Added file: http://bugs.python.org/file25566/x11-clipboard-try-utf8.patch ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: I'm happy to put the cache at the module level, but I'll give other people a chance to express their views before I dive into the code again. I imagine most applications would only call clipboard_get() on one item, so it wouldn't matter. However, my own interest in this is from IPython, where we create a Tk object just to call clipboard_get() once, so a module level cache would be quicker, albeit only a tiny bit. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment:
The 3rd revision of the patch has the cache at the module level. It's a bit
awkward, because there's no module level function to call to retrieve it (as
far as I know), so it's exposed by objects which can call Tk.
Also, serhiy pointed out a mistake in the 2nd revision, which is fixed
('selection' instead of 'clipboard').
--
Added file: http://bugs.python.org/file25567/x11-clipboard-try-utf8-3.patch
___
Python tracker
<http://bugs.python.org/issue14777>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: I've submitted the contributor agreement, though I've not yet heard anything back about it. -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14777] Tkinter clipboard_get() decodes characters incorrectly
Thomas Kluyver added the comment: ...And mere minutes after I said I hadn't heard anything, I've got the confirmation email. :-) -- ___ Python tracker <http://bugs.python.org/issue14777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14846] Change in error when sys.path contains a nonexistent folder (importlib)
New submission from Thomas Kluyver :
I've come across a difference from 3.2 to 3.3 while running the IPython test
suite. It occurs when a directory on sys.path has been used for an import, then
deleted without being removed from sys.path. Previous versions of Python ignore
the nonexistent folder, but in 3.3 a FileNotFound error appears.
This might be by design (errors should never pass silently), but I haven't
found it mentioned in the What's New for 3.3.
$ cat import.py
import sys, os, shutil
os.mkdir('foo')
with open('foo/bar.py', 'w'):
pass
sys.path.insert(0, 'foo/')
import bar # Caches a FileFinder for foo/
shutil.rmtree('foo')
import random # Comes later on sys.path
$ python3.2 import.py
$ python3.3 import.py
Traceback (most recent call last):
File "import.py", line 8, in
import random
File "", line 1162, in _find_and_load
File "", line 1124, in _find_and_load_unlocked
File "", line 1078, in _find_module
File "", line 927, in find_module
File "", line 973, in find_module
File "", line 1005, in _fill_cache
FileNotFoundError: [Errno 2] No such file or directory: 'foo/'
The last entry in that traceback is calling "_os.listdir(path)".
--
components: Interpreter Core
messages: 161025
nosy: takluyver
priority: normal
severity: normal
status: open
title: Change in error when sys.path contains a nonexistent folder (importlib)
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue14846>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15856] inspect.getsource(SomeClass) doesn't show @decorators
New submission from Thomas Kluyver: Since bug #1006219 was fixed, inspect.getsource(func) has returned the source of a function including any decorators on the function. But doing the same with a class, the returned source doesn't include decorators. With functions, the co_firstlineno attribute of the code object points to the start of the decorators. With classes, that's not possible, so it's likely that a bit more regex trickery will be needed to scan back to decorators. I've confirmed the same thing happens in 3.2 and 2.7, and looking at the code of inspect.py in trunk, it looks like it will do the same thing. -- components: Library (Lib) messages: 169767 nosy: takluyver priority: normal severity: normal status: open title: inspect.getsource(SomeClass) doesn't show @decorators type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15856> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16349] Document whether it's safe to use bytes for struct format string
New submission from Thomas Kluyver: At least in CPython, format strings can be given as bytes, as an alternative to str. E.g. >>> struct.unpack(b'>hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03') (1, 2, 3) Looking at the source code [1], this appears to be consciously accounted for. But it doesn't seem to be mentioned in the documentation. I think the docs should either say it's a possibility, or warn that it's an implementation detail. [1] http://hg.python.org/cpython/file/cde4b66699fe/Modules/_struct.c#l1340 -- components: Library (Lib) messages: 174042 nosy: takluyver priority: normal severity: normal status: open title: Document whether it's safe to use bytes for struct format string ___ Python tracker <http://bugs.python.org/issue16349> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20778] ModuleFinder.load_module skips incorrect number of bytes in pyc files
Thomas Kluyver added the comment: For future reference, cx_Freeze ships its own copy of ModuleFinder, so it doesn't depend on the stdlib copy. This issue was fixed there some time around the release of Python 3.3. I realised recently that this is based on code in the stdlib, and I've been meaning to work out whether cx_Freeze can use any of the stdlib code and lose parts of its own implementation. I guess it's been diverging for quite some time, though. -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue20778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
New submission from Thomas Kluyver:
The compileall module's command line interface has a -q (quiet) flag which
suppresses most of the output, but it still prints error messages. I'd like an
entirely silent mode with no output.
My use case is byte-compiling Python files as part of a graphical installer. I
do this by running:
py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs"
I'd like to be able to use pyw so a terminal doesn't pop up, but if I do that,
it exits early. I think this is due to the issue with stdout/stderr buffers
filling up on pythonw.
--
components: Library (Lib)
messages: 217100
nosy: takluyver
priority: normal
severity: normal
status: open
title: Silent mode for compileall
___
Python tracker
<http://bugs.python.org/issue21338>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Thomas Kluyver added the comment: Patch attached. This works by making the -q flag countable, so you pass -qq to suppress all output. In the Python API, the quiet parameter has become an integer, so passing 2 is equivalent to -qq. This should be fully backwards compatible with passing True and False, which are equivalent to 1 and 0. -- keywords: +patch type: enhancement -> Added file: http://bugs.python.org/file35012/compileall_silent.patch ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Changes by Thomas Kluyver : Removed file: http://bugs.python.org/file35012/compileall_silent.patch ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Thomas Kluyver added the comment: Sorry, I somehow attached an old version of the patch. This one should be correct. Steven: Redirection relies on a shell - the native 'run a process' interface that the installer uses can't do that. There are ways to work around this, but I think this approach makes sense. It exits early because stdout and stderr don't go anywhere, so once either of them has filled up a fairly small buffer, attempts to write to it throw an error. I'd love to see that fixed, but it's been known about for years (see issue 706263), and it seems unlikely to change any time soon. -- Added file: http://bugs.python.org/file35013/compileall_silent.patch ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Changes by Thomas Kluyver : Removed file: http://bugs.python.org/file35013/compileall_silent.patch ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Thomas Kluyver added the comment: Gah, still wrong. Trying again. -- Added file: http://bugs.python.org/file35014/compileall_silent.patch ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21338] Silent mode for compileall
Thomas Kluyver added the comment: In fact, I will probably end up working around this anyway, because I'll have to support versions of Python without this fix for some time. So I don't feel strongly that it needs to go in, but I will do any revisions or changes requested if people think it would be useful. -- ___ Python tracker <http://bugs.python.org/issue21338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16467] frozen importlib required for extending Python interpreter not public
Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue16467> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute
Thomas Kluyver added the comment: It seems pretty arbitrary and newcomer-unfriendly to decide that Python doesn't support running setup.py inside IDLE. Exhibit A: confused newcomer trying to install distribute, getting unhelpful error message. http://stackoverflow.com/questions/13368040/ipython-installation-on-3-3-x64-errors -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue12967> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11679] readline interferes with characters beginning with byte \xe9
Thomas Kluyver added the comment: OK, thanks, and sorry for the noise. I've closed this issue. Looking at the readline manual, it looks like this is tied up with the options input-meta, output-meta and convert-meta. Fiddling around with .inputrc hasn't clarified exactly what they do, but it seems that the terminal can either handle unicode, or shortcuts involving meta (alt), but not both. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue11679> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16544] Add external link to ast docs
Thomas Kluyver added the comment: Thanks, I'm really glad to see that it's useful to others. I don't mind contributing it to Python, but I wonder if it's better to let it develop separately for a few months first - it's still very new, and I can improve it faster in a repository where I can commit to it myself. I'm open to other opinions on that, though. In the meantime, let me know if there are any specific formats/styles/etc. that I should work towards, to make a later move into the official docs simpler. I have a couple of particular questions: - The repository includes some utility code for exploring ASTs, as well as longer, runnable versions of the examples in the docs. What would be the best way to preserve these? - There are some nodes (like AugLoad) that I've yet to find what they actually do, while I've only seen Param in Python 2. Is this an issue? Of course, you're more than welcome to give a 'see also' link to GTS if we decide not to move it for now. -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue16544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16544] Add external link to ast docs
Thomas Kluyver added the comment: I think that putting the full content of GTS into the ast module docs would make it awkwardly long. Perhaps the bulk of it could become a howto, and GTS could be maintained separately as a showcase of examples. -- ___ Python tracker <http://bugs.python.org/issue16544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16349] Document whether it's safe to use bytes for struct format string
Thomas Kluyver added the comment: I'm happy to put together a docs patch, but I don't have any indication of the right answer (is it a safe feature to use, or an implementation detail?) Is there another venue where I should raise the question? -- ___ Python tracker <http://bugs.python.org/issue16349> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, adding shutil.which
Thomas Kluyver added the comment:
The 'short circuit' appears to do what I'd consider the wrong thing when an
executable file of the same name exists in the working directory. i.e.
which('setup.py') can return 'setup.py', even though running 'setup.py' in a
shell doesn't work (you need ./setup.py).
This is on UNIX-y systems, I see from the comments that the cwd is implicitly
on the path in Windows.
Is this in scope for which() to deal with? Should I open a bug for it?
Apologies if it's been discussed already.
--
nosy: +takluyver
___
Python tracker
<http://bugs.python.org/issue444582>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16957] shutil.which() shouldn't look in working directory on unix-y systems
New submission from Thomas Kluyver: There's a 'short circuit' in shutil.which(), described as 'If we're given a full path which matches the mode and it exists, we're done here.' It also matches if an executable file of the same name is present in the working directory, although on most Unix-y systems you need ./ to execute such files in a shell (i.e. ./foo, not just foo). This could fool code calling which() into thinking that a program is installed, when it is not. If we consider this a bug, one simple fix would be to only allow the short circuit with an absolute path, so the line if _access_check(cmd, mode): would become if os.path.isabs(cmd) and _access_check(cmd, mode): -- components: Library (Lib) messages: 179897 nosy: takluyver priority: normal severity: normal status: open title: shutil.which() shouldn't look in working directory on unix-y systems type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16957] shutil.which() shouldn't look in working directory on unix-y systems
Thomas Kluyver added the comment: I've added a patch with my suggested fix, as well as a test for this. test_shutil all passes on Linux - I haven't run the tests on Windows. -- keywords: +patch Added file: http://bugs.python.org/file28761/shutil_which_cwd.patch ___ Python tracker <http://bugs.python.org/issue16957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16957] shutil.which() shouldn't look in working directory on unix-y systems
Thomas Kluyver added the comment: That makes sense - foo/setup.py can be run from the working directory, but you can't refer to subdirectories on $PATH like that. I've added a revised version of the patch. -- Added file: http://bugs.python.org/file28763/shutil_which_cwd2.patch ___ Python tracker <http://bugs.python.org/issue16957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16957] shutil.which() shouldn't look in working directory on unix-y systems
Thomas Kluyver added the comment:
Yes, as far as I know, ./script works in the same way as dir/script - from the
current directory, but not from $PATH.
The first test added is for the case I reported - which('script') shouldn't
look in the current directory on Unix. The second test would have failed
without Serhiy's correction.
Serhiy, I agree that the comment wasn't quite right. I've uploaded a new
version of the patch with a modified comment.
--
versions: -Python 3.4
Added file: http://bugs.python.org/file28777/shutil_which_cwd3.patch
___
Python tracker
<http://bugs.python.org/issue16957>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8478] tokenize.untokenize first token missing failure case
Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue8478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16224] tokenize.untokenize() misbehaves when moved to "compatiblity mode"
Thomas Kluyver added the comment: I think this is a duplicate of #8478. -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue16224> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8478] tokenize.untokenize first token missing failure case
Thomas Kluyver added the comment: #16224 appears to be a duplicate. There seem to be several quite major issues with untokenize - see also #12691 - with patches made to fix them. Is there anything I can do to help push these forwards? -- ___ Python tracker <http://bugs.python.org/issue8478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12691] tokenize.untokenize is broken
Thomas Kluyver added the comment: Is there anything I can do to push this forwards? I'm trying to use tokenize and untokenize in IPython, and for now I'm going to have to maintain our own copies of it (for Python 2 and 3), because I keep running into problems with the standard library module. -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue12691> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17061] tokenize unconditionally emits NL after comment lines & blank lines
New submission from Thomas Kluyver:
The docs describe the NL token as "Token value used to indicate a
non-terminating newline. The NEWLINE token indicates the end of a logical line
of Python code; NL tokens are generated when a logical line of code is
continued over multiple physical lines."
However, after a comment or a blank line, tokenize emits NL, even when it's not
inside a multi-line statement. For example:
In [15]: for tok in tokenize.generate_tokens(StringIO('#comment\n').readline):
print(tok)
TokenInfo(type=54 (COMMENT), string='#comment', start=(1, 0), end=(1, 8),
line='#comment\n')
TokenInfo(type=55 (NL), string='\n', start=(1, 8), end=(1, 9),
line='#comment\n')
TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')
This makes it difficult to use tokenize to detect multi-line statements, as we
want to do in IPython.
In my tests so far, changing two instances of NL to NEWLINE in this block
(lines 530 & 533) makes it behave as I expect:
http://hg.python.org/cpython/file/a375c3d88c7e/Lib/tokenize.py#l524
--
messages: 180846
nosy: takluyver
priority: normal
severity: normal
status: open
title: tokenize unconditionally emits NL after comment lines & blank lines
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue17061>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16509] sqlite3 docs do not explain check_same_thread
Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue16509> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Thomas Kluyver added the comment: I've updated Nick's patch so that test_dis and test_peephole pass again, and added a prototype ByteCode class (without any docs or tests for now, to allow for API discussion). The prototype ByteCode is instantiated with any of the objects that get_instructions already accepts (functions, methods, code strings & code objects). Iterating over it yields Instruction objects. It has info(), show_info() and display_code() methods, which correspond to the code_info(), show_code() and disassemble() functions. I've tried to go for names that make sense, rather than names that fit the existing pattern, because the existing pattern feels a bit messy. E.g. the show_code() function doesn't actually show the code, so I've called its method equivalent show_info(). -- nosy: +takluyver Added file: http://bugs.python.org/file29051/dis_api.diff ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16509] sqlite3 docs do not explain check_same_thread
Thomas Kluyver added the comment: The module docs do mention "Older SQLite versions had issues with sharing connections between threads." Presumably that means that sharing the connection between threads is safe so long as you're not using 'older versions', but it would be nice to have some more clarity about how old those versions are. -- ___ Python tracker <http://bugs.python.org/issue16509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16509] sqlite3 docs do not explain check_same_thread
Thomas Kluyver added the comment: This page also looks relevant: sqlite can be compiled or used in three different threading modes. Presumably Python compiles/initialises it in the serialised mode, which makes it safe to use a connection from different threads. http://www.sqlite.org/threadsafe.html -- ___ Python tracker <http://bugs.python.org/issue16509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18395] Make _Py_char2wchar() and _Py_wchar2char() public
Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker <http://bugs.python.org/issue18395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18395] Make _Py_char2wchar() and _Py_wchar2char() public
Thomas Kluyver added the comment: You seem to need wchar_t to call Py_Main and Py_SetProgramName. I think there's an example in the docs which is wrong, because it appears to pass a char* to Py_SetProgramName: https://docs.python.org/3.4/extending/embedding.html#very-high-level-embedding -- ___ Python tracker <http://bugs.python.org/issue18395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22200] Remove distutils checks for Python version
New submission from Thomas Kluyver: We noticed the other day that distutils, despite being part of the standard library, checks the version of Python it's running under and has some different code paths - one of which is only taken for Python < 2.2. We haven't managed to figure out why this is necessary. So this issue is partly a patch and partly a question: is there a reason that distutils can't assume it's run on the version of Python it came with? If so, I'm happy to make a new patch adding a comment to explain that. If not, I'll go looking for other places where it has unnecessary checks, and we can clean up one little corner of wtf. -- components: Distutils files: rm-distutils-version-check.patch keywords: patch messages: 225320 nosy: dstufft, eric.araujo, takluyver priority: normal severity: normal status: open title: Remove distutils checks for Python version Added file: http://bugs.python.org/file36372/rm-distutils-version-check.patch ___ Python tracker <http://bugs.python.org/issue22200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22200] Remove distutils checks for Python version
Thomas Kluyver added the comment: I spotted a few others as well. When I get a bit less busy in a couple of weeks time, I intend to go through and make a bigger patch to clean things up. -- ___ Python tracker <http://bugs.python.org/issue22200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22346] asyncio documentation does not mention provisional status
New submission from Thomas Kluyver: >From PEP 411: """ A package will be marked provisional by a notice in its documentation page and its docstring. The following paragraph will be added as a note at the top of the documentation page: The package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the package) may occur if deemed necessary by the core developers. """ PEP 3156 says that asyncio is in provisional status until Python 3.5, but the main asyncio page in the docs does not even mention this, let alone having the new warning: https://docs.python.org/3/library/asyncio.html I freely admit this is nitpicking, but if the idea of provisional status is to be taken seriously, I think asyncio, as a very high profile new package, should set a good example of it. -- assignee: docs@python components: Documentation, asyncio messages: 226463 nosy: docs@python, gvanrossum, haypo, takluyver, yselivanov priority: normal severity: normal status: open title: asyncio documentation does not mention provisional status versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
