[issue38825] shutil.disk_usage - Lacking documentation
Tyler Crompton added the comment: Not even the kernel knows how much space is available on a nonmounted partition. It doesn't know much beyond the fact that it exists and where it exists. There exist tools that can analyze nonmounted partitions, but these will vary by filesystem and operating system. If someone wants to implement solutions for the most common filesystem-OS combinations, then that might be helpful. But considering that no one has done that or even asked for it yet, I'm not sure that doing so is worth the effort. So I agree that documenting it is the best approach. It should be documented such that the limitations are mentioned, not necessarily how it's implemented. If explaining which system calls are used helps explain the limitations, then so be it. Additionally, as far as I'm concerned, there's no reason to restrict other Python implementations from implementing functionality for nonmounted disks. So the limitations should be described as being CPython-specific, akin to what is done for `readline.set_auto_history`. -- nosy: +tylercrompton ___ Python tracker <https://bugs.python.org/issue38825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Tyler Crompton added the comment: I suppose the only thing that could be left is adding remarks in the documentations for previous versions. If I understand correctly, this would only be added to the documentations for Python 2.7 and 3.5. Is this correct? Since this is the first issue in which I've submitted a patch, I'm still quite new to the CPython development workflow; is there a special way to indicate that a patch should be applied to a branch other than default? Or is that done simply by informally indicating so in a message? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Tyler Crompton added the comment: I couldn't think of a way to test input() with the unittest module without bypassing readline or requesting the input from the user. With that said, this informal script verifies proper behavior. -- status: open -> pending Added file: http://bugs.python.org/file42749/test_set_auto_history.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Changes by Tyler Crompton <ty...@tylercrompton.com>: -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Changes by Tyler Crompton <ty...@tylercrompton.com>: -- keywords: +patch Added file: http://bugs.python.org/file42748/set_auto_history.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Tyler Crompton added the comment: I agree about the documentation. It would only take a few minutes to do. In regard to your inquiry about the second solution, more or less, yes. I left that one a bit ambiguous since there are many ways to skin that cat. But in retrospect, I probably shouldn't have included that potential solution since it'd be a bit goofy and wouldn't necessarily be much different (in terms of code conciseness) than the third workaround that I mentioned. As for your suggestion about the fourth solution, I like that idea. I feel that it's actually more similar to the fifth solution than the fourth, but I feel that we're getting close to coming up with something that should be easy and effective. Lastly, in regard to the fifth solution, yes. But I see what you're saying about the downside. Yeah, that would be rather annoying. For a moment, I thought that it could fall back to standard IO in the absence of Readline/libedit, but that would be a bit misleading for a function in the readline module. Besides, input already does that anyway. I would imagine that in the vast majority of cases of using such a new function, the developer would fallback to input, because they'd likely prioritize getting the content from the user over ensuring Readline/libedit functionality. Since we already have a function that automatically does that, I think your suggestion to add a function to the readline module to enable/disable automatic history addition would be ideal. I'd be reluctant to use a global Python variable since it would be out of uniform with the rest of the members (i.e., functions) of the module. I like the idea of adding a set_auto_history(flag=True|False) or something to that effect. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
Changes by Tyler Crompton <ty...@tylercrompton.com>: -- nosy: +twouters ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26870] Unexpected call to readline's add_history in call_readline
New submission from Tyler Crompton: I was implementing a REPL using the readline module and noticed that there are extraneous calls to readline's add_history function in call_readline[1]. This was a problem because there were some lines, that, based on their compositions, I might not want in the history. Figuring out why I was getting two entries for every The function call has been around ever since Python started supporting GNU Readline (first appeared in Python 1.4 or so, I believe)[2]. This behavior doesn't seem to be documented anywhere. I can't seem to find any code that depends on a line that is read in by call_readline to be added to the history. I guess the user might rely on the interactive interpreter to use the history feature. Beyond that, I can't think of any critical purpose for it. There are four potential workarounds: 1. Don't use the input function. Unfortunately, this is a non-solution as it prevents one from using Readline/libedit for input operations. 2. Don't use Readline/libedit. For the same reasons, this isn't a good solution. 3. Evaluate get_current_history_length() and store its result. Evaluate input(). Evaluate get_current_history_length() again. If the length changed, execute readline.remove_history_item(readline.get_current_history_length() - 1). Note that one can't assume that the length will change after a call to input, because blank lines aren't added to the history. This isn't an ideal solution for obvious reasons. It's a bit convoluted. 4. Use some clever combination of readline.get_line_buffer, tty.setcbreak, termios.tcgetattr, termios.tcsetattr, msvcrt.getwche, and try-except-finally blocks. Besides the obvious complexities in this solution, this isn't particularly platform-independent. I think that it's fair to say that none of the above options are desirable. So let's discuss potential solutions. 1. Remove this feature from call_readline. Not only will this cause a regression in the interactive interpreter, many people rely on this behavior when using the readline module. 2. Dynamically swap histories (or readline configurations in general) between readline-capable calls to input and prompts in the interactive interpreter. This would surely be too fragile and add unnecessary overhead. 3. Document this behavior and leave the code alone. I wouldn't say that this is a solution, but it would at least help other developers that would fall in the same trap that I did. 4. Add a keyword argument to input to instruct call_readline to not add the line to the history. Personally, this seems a bit dirty. 5. Add a readline function in the readline module that doesn't rely on call_readline. Admittedly, the implementation would have to look eerily similar to call_readline, so perhaps there could be a flag on call_readline. However, that would require touching a few files that don't seem to be particularly related. But a new function might be confusing since call_readline sounds like a name that you'd give such a function. I think that the last option would be a pretty clean change that would cause the least number of issues (if any) for existing code bases. Regardless of the implementation details, I think that this would be the best route—to add a Python function called readline to the readline module. I would imagine that this would be an easy change/addition. I'm attaching a sample script that demonstrates the described issue. [1]: https://github.com/python/cpython/blob/fa3fc6d78ee0ce899c9c828e796b66114400fbf0/Modules/readline.c#L1283 [2]: https://github.com/python/cpython/commit/e59c3ba80888034ef0e4341567702cd91e7ef70d -- components: Library (Lib) files: readline_history.py messages: 264360 nosy: Tyler Crompton priority: normal severity: normal status: open title: Unexpected call to readline's add_history in call_readline type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42626/readline_history.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
Tyler Crompton added the comment: I will gladly test the changes. Where would I find these to download? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17125] tokenizer.tokenize passes a bytes object to str.startswith
New submission from Tyler Crompton:
Line 402 in lib/python3.3/tokenize.py, contains the following line:
if first.startswith(BOM_UTF8):
BOM_UTF8 is a bytes object. str.startswith does not accept bytes objects. I was
able to use tokenize.tokenize only after making the following changes:
Change line 402 to the following:
if first.startswith(BOM_UTF8.decode()):
Add these two lines at line 374:
except AttributeError:
line_string = line
Change line 485 to the following:
try:
line = line.decode(encoding)
except AttributeError:
pass
I do not know if these changes are correct as I have not fully tested this
module after these changes, but it started working for me. This is the meat of
my invokation of tokenize.tokenize:
import tokenize
with open('example.py') as file: # opening a file encoded as UTF-8
for token in tokenize.tokenize(file.readline):
print(token)
I am not suggesting that these changes are correct, but I do believe that the
current implementation is incorrect. I am also unsure as to what other versions
of Python are affected by this.
--
components: Library (Lib)
messages: 181349
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: tokenizer.tokenize passes a bytes object to str.startswith
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17125
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
Tyler Crompton added the comment: I can confirm that this works. The underscore does not appear when using the default font settings (Courier, size 10). I changed it to Courier New and all is fine. One may also want to increase the font size to 12 as the font is difficult to read when the property list has been fixed. I have no idea where to begin on the patch, though. -- resolution: invalid - status: closed - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
New submission from Tyler Crompton: I think this is more of a Tkinter issue than IDLE but since IDLE uses Tkinter, it inherits this bug. Many programs that were not developed for the Macbook Pro with Retina Display still look great. Whereas others, look pixelated in some areas (i.e. the current stable release of Google Chrome IIRC (I installed the beta to get around that)), and some are just flat out pixelated everywhere. IDLE falls into the latter category. I know IDLE really has its issues and that few people use it, but it's a cosmetic change that I don't see being too difficult. Then again, I know hardly anything about how it is implemented. -- components: IDLE, Tkinter files: Screen Shot 2012-08-08 at 2.07.19 AM.png messages: 167671 nosy: Tyler.Crompton priority: normal severity: normal status: open title: IDLE is pixelated on the Macbook Pro with Retina Display type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26724/Screen Shot 2012-08-08 at 2.07.19 AM.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
Tyler Crompton gtr...@gmail.com added the comment:
As for the losing valuable debug information, much worse can be done:
import sys
try:
x
except NameError:
print('An error occurred.', file=sys.stderr)
sys.exit(1)
This is obviously not how one should handle errors in development, but it's
allowed. As Ethan pointed out, the initial proposal can be recreated by just
adding three words which is obviously also allowed.
Nick, I'm not saying you're opinions are wrong, I just wanted to point out how
easy it is to throw away valuable information. It's almost futile.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15209
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15383] Autocompletion crashes Python if the __builtins__ module cannot be found.
New submission from Tyler Crompton gtr...@gmail.com:
Doing one of the following crashes Python.
del __builtins__
a{Tab}
or
builtins = __builtins__
del __builtins__
a{Tab}
If you do a print screen, immediately, you will see the following error:
*** Internal Error: rpc.py:SocketIO.localcall()
Object: exec
Method: bound method Executive.get_the_completion_list of
idlelib.run.Executive object at 0x02DC2710
Args: ('', 1)
Traceback (most recent call last):
File C:\Python32\lib\idlelib\rpc.py, line 188, in localcall
ret = method(*args, **kwargs)
File C:\Python32\lib\idlelib\run.py, line 327, in
get_the_completion_list
return self.autocomplete.fetch_completions(what, mode)
File C:\Python32\lib\idlelib\AutoComplete.py, line 189, in
fetch_completions
namespace.update(__main__.__builtins__.__dict__)
AttributeError: 'module' object has no attribute '__builtins__'
Additionally, when __builtins__ is deleted (in IDLE), __builtins__ becomes a
dictionary. If one were to then do __builtins__.clear(), the interpreter stops
all interpreting. IDLE moreorless becomes a text editor with syntax
highlighting. If you try to use autocomplete, Python hangs before crashing.
I realize that doing such is pointless, but it behaves differently than
interactive console interpreters. Interactive console interpreters don't
convert __builtins__ to a dictionary upon its deletion. I feel that this error
can be handled to prevent crashing.
--
components: IDLE
messages: 165741
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: Autocompletion crashes Python if the __builtins__ module cannot be found.
type: crash
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15383
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
Tyler Crompton gtr...@gmail.com added the comment: I'm in a little over my head as I can't conceptualize __cause__, so I may be looking over things. First, you, Ethan, said the following: It's also not difficult to work around if you really want to toss the extra info: except NameError: try: fallback_module.getch() except Exception as exc: raise exc from None A total of three more words to get the desired behavior (and small ones at that). Counter-argument: if it's just three words, then why was the shorthand without the from clause implemented in the first place? My use case was primarily based on the idea that the unavailability of the windows module (from the example) is irrelevant information to, say, Unix users. When an exception is raised, the user shouldn't have to see any Windows-related exceptions (that is if there is an alternate solution). One could fix this with a little bit of refactoring, though: import sys as _sys def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') if 'windows_module' in _sys.modules: return windows_module.getch() else: try: return fallback_module.getch() except Exception: raise from None But it's EAFP. Heck, one could even do the following: def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') try: return windows_module.getch() except NameError: pass try: return fallback_module.getch() except Exception: raise But that's not really ideal. I've played around with the traceback module a little and (very) briefly played with the exceptions themselves. Is there not an easier way to suppress a portion of an exception? Like I said, such information is irrelevant to non-Windows users. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
New submission from Tyler Crompton gtr...@gmail.com: As you know, a caught exception can be re-raised with a simple `raise` statement. Plain and simple. However, one cannot re-raise an error with this new `from expression` clause. For example: def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') try: return windows_module.getch() except NameError: try: fallback_module.getch() except Exception: raise from None Output: File getch.py, line 11 raise from None ^ SyntaxError: invalid syntax A quick look at the documentation about [raise](http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement) confirms that this is the intended behavior. In my opinion, one should be able to still re-raise from an expression. -- components: Interpreter Core files: getch.py messages: 164184 nosy: Tyler.Crompton priority: normal severity: normal status: open title: Re-raising exceptions from an expression type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26183/getch.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
Tyler Crompton gtr...@gmail.com added the comment: Relevent PEP: http://www.python.org/dev/peps/pep-0409/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
Changes by Tyler Crompton gtr...@gmail.com: -- nosy: +ncoghlan, stoneleaf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15208] Uparrow doesn't show previously typed variable or character
Tyler Crompton gtr...@gmail.com added the comment: I recreated this issue on (mostly) fresh install of Ubuntu Server 12.04. I installed libreadline-dev and then removed and re-installed Python 3.3.0b1. This resolved the issue. -- nosy: +Tyler.Crompton status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
