[issue29659] Expose the `length` arg from shutil.copyfileobj for public use
New submission from tyler: It would be handy to be able to pass the `length` default argument defined by `shutil.copyfileobj()` to other public functions througout the module. When copying very large files (1GB +), increasing the memory buffer can divide the copy time in half and currently the only way to accomplish this is by overriding the needed function(s) which call `shutil.copyfileobj()`. I propose a simple non-invasive change where the following functions will also expose the `length` kwarg and pass it downwards to `copyfileobj`: - copyfile - copy - copy2 -- messages: 288616 nosy: goodboy priority: normal severity: normal status: open title: Expose the `length` arg from shutil.copyfileobj for public use versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13460] urllib methods should demand unicode, instead demand str
New submission from Tyler Starke : It seems bad practice for urllib methods to demand a str instance and they should demand a unicode instance. By demanding a str instance the default behavior is too demanding, for the web space it is being used, for the English language. We would want Python to extend beyond English when it uses urllib Currently I am encoding the unicode passed with 'utf-8' and that works. -- components: Library (Lib), Unicode messages: 148165 nosy: Tyler.Starke, ezio.melotti priority: normal severity: normal status: open title: urllib methods should demand unicode, instead demand str type: behavior ___ Python tracker <http://bugs.python.org/issue13460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13460] urllib methods should demand unicode, instead demand str
Tyler Starke added the comment: well that was closed fast. I noticed in the docs that Python 3 demands a str type also. -- ___ Python tracker <http://bugs.python.org/issue13460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13460] urllib methods should demand unicode, instead demand str
Tyler Starke added the comment: Nevermind. I had to download the source to see that it encodes to 'utf-8', or a passed encoding method, in the methods that are causing problems in 2.6.5. -- ___ Python tracker <http://bugs.python.org/issue13460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] Improvement of textwrap module
New submission from Tyler Romeo : Python's textwrap module can be helpful at times, but personally I think there are a couple of things that could be added. First, when it comes to text wrapping, usually you're not dealing with a monospace font where each letter is the same size. If you're working with the Python Imaging Library for example, there is a function that you pass the text to in order to determine how wide (or tall) a font is. Therefore, it would be useful to have a parameter where the user can pass a function that gives a custom width for a set of text. The default for this parameter, of course, would be len. Also, this module uses a rough and efficient algorithm for wrapping text, but the results are not always aesthetically pleasing (one word hanging off on a line). Sometimes the user may want something that is wrapped more beautifully, so to say, such as is found in TeX. So there should also be a beautiful option that goes back and redistributes the text so that it is more aesthetically pleasing. This isn't exactly that important (minor improvements to a module that is probably not used much), but I figured I'd get it out there as I run into the problem all the time when trying to wrap text to be put in images of a set size. -- components: Extension Modules files: textwrap.py-improvement.diff keywords: patch messages: 139731 nosy: parent5446 priority: normal severity: normal status: open title: Improvement of textwrap module type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file22561/textwrap.py-improvement.diff ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] textwrap.wrap: add control for custom length and orphans
Tyler Romeo added the comment: Nah, they're both unrelated. I'll separate the changes and remake the patches. (I'll keep this entry for the beautification part.) -- ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] textwrap.wrap: add control for custom length and orphans
Tyler Romeo added the comment: OK, so here is the patch for just the new algorithm. -- Added file: http://bugs.python.org/file22573/textwrap.py-new-algorithm-2011-07-04_22-45-53_r71219+.diff ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12499] textwrap.wrap: add control for fonts with different character widths
New submission from Tyler Romeo : Originally from http://bugs.python.org/issue12485 but separated. The textwrap modules uses len to determine the length of text, but in many (if not most) fonts, the width of a character differs depending on the letter, so it would be useful to have an option to pass a custom function that returns the width of a given string of text. -- components: Library (Lib) files: textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff keywords: patch messages: 139828 nosy: parent5446 priority: normal severity: normal status: open title: textwrap.wrap: add control for fonts with different character widths type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file22574/textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff ___ Python tracker <http://bugs.python.org/issue12499> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] textwrap.wrap: add control for custom length and orphans
Changes by Tyler Romeo : Removed file: http://bugs.python.org/file22561/textwrap.py-improvement.diff ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12499] textwrap.wrap: add control for fonts with different character widths
Tyler Romeo added the comment: Normally I would have just added it as a function to be overloaded, but because of the nature of the textwrap.wrap function (all kwargs are passed to the TextWrapper constructor) I thought it made a lot more sense to keep it as an argument to __init__. -- ___ Python tracker <http://bugs.python.org/issue12499> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] textwrap.wrap: new argument for more pleasing output
Tyler Romeo added the comment: OK, sorry to get back so late, but here's the updated patch without xrange. I saw the version change but forgot that I used xrange in the function (old habits I guess). -- Added file: http://bugs.python.org/file22626/textwrap.py-beautiful-2011-07-11_22-01-31_r71296+.diff ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12485] textwrap.wrap: new argument for more pleasing output
Changes by Tyler Romeo : Removed file: http://bugs.python.org/file22573/textwrap.py-new-algorithm-2011-07-04_22-45-53_r71219+.diff ___ Python tracker <http://bugs.python.org/issue12485> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3043] Recursion bug in deepcopy
New submission from Tyler Laing <[EMAIL PROTECTED]>: With the following code: class Vertex: def __init__(self, type): self.type = type self.color=-1 self.edges=[] class Edge: def __init__(self, V1, V2): self.vertexes=[V1, V2] V1.edges.append(self) V2.edges.append(self) Where the references are cyclic(this is for a research project into graph algorithms), and using deepcopy, even on a tiny graph of five vertexes and 25 edges causes deepcopy to run into the recursion limit. At the very least, it should warn it can't copy the indicated object, as the references are cyclic. At the very most, it should be able to handle complex cyclic references like this properly. -- components: Library (Lib) messages: 67728 nosy: Zeroth severity: normal status: open title: Recursion bug in deepcopy type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3043] Recursion bug in deepcopy
Tyler Laing <[EMAIL PROTECTED]> added the comment: Whoops, sorry, correction, when there are 100 vertexes and 500 edges. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3043] Recursion bug in deepcopy
Tyler Laing <[EMAIL PROTECTED]> added the comment:
Same problem, even with new-style classes. Here, I'll show the function
I use to generate the graph as well.
class Vertex(object):
def __init__(self, type):
self.type = type
self.color=-1
self.edges=[]
class Edge(object):
def __init__(self, V1, V2):
self.vertexes=[V1, V2]
V1.edges.append(self)
V2.edges.append(self)
def generate(graph={'V':[], 'E':[]}, seed=777, vertexes=5, edges=25):
#generates a graph similar to the KEGG pathway database format.
# Purpose is for testing algorithms on a smaller scale "predicatible"
graph
# For that reason, the "random" selections are seeded with a known
number. This is to be able
# to measure efficacy, in that on the same graph, if algorithm A
performs in half the time, its
# not a characteristic of the graph, but the algorithm.
r=random.Random(seed)
p=[0, 0, 0, 0]
c=0
#generate vertices, with a regularly incremented set of numbers, to
appear like the KEGG pathway database does.
while c!=vertexes:
#This is ugly, could be done easier in a loop. Fix later.
p[3]+=1
if p[3]>9:
p[3]=0
p[2]+=1
if p[2]>9:
p[2]=0
p[1]+=1
if p[1]>9:
p[1]=0
p[0]+=1
#we copy the set of numbers, due to the way python passes lists
by
reference, instead of by copy.
v=Vertex(p[:])
graph['V'].append(v)
c+=1
v=graph['V']
if len(v)!=vertexes:
print "Not enough vertices, aborting."
return graph
c=0
#randomly choose two vertices. Could even, randomly, be the same vertex.
# Then, connect an edge between them. Just creating the edge by
implication,
# with the vertices passed, connects them all together.
while c!=edges:
v1=r.choice(v)
v2=r.choice(v)
graph['E'].append(Edge(v1, v2))
c+=1
if len(graph['E']) !=edges:
print "Not enough edges, aborting."
return graph
And here is how I use it:
>>>import graph, copy
>>>g=graph.generate(vertexes=100, edges=500)
>>>g2=copy.deepcopy(g)
Thanks for the prompt response, this isn't critical in nature, just
playing around with the graph, and wanted to alter a copy of it. Ran
into this bug, thought I should report it. :)
-Zeroth
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3043>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38303] Make audioop PEP-384 compatible
Change by Tyler Kieft : -- components: Extension Modules nosy: Tyler Kieft priority: normal severity: normal status: open title: Make audioop PEP-384 compatible versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38303] Make audioop PEP-384 compatible
New submission from Tyler Kieft : Working on a patch for this, will have it up in a couple days -- ___ Python tracker <https://bugs.python.org/issue38303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38303] Make audioop PEP-384 compatible
Change by Tyler Kieft : -- keywords: +patch pull_requests: +16085 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16497 ___ Python tracker <https://bugs.python.org/issue38303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38303] Make audioop PEP-384 compatible
Change by Tyler Kieft : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
[issue43004] No type variables left in collections.abc.Callable
New submission from Tyler Yep :
The following code crashes when I try to run it, even though it passes when I
use `from typing import Callable` instead.
```
from collections.abc import Callable
from typing import Any, TypeVar
V = TypeVar("V")
Function = Callable[[list[V], V, V], float]
def random_fn(fn: Function[Any]) -> Function[Any]:
return fn
```
--
messages: 385511
nosy: tyler.yep
priority: normal
severity: normal
status: open
title: No type variables left in collections.abc.Callable
type: crash
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43004>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43004] No type variables left in collections.abc.Callable
Tyler Yep added the comment: Got it, thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43201] sqlite3 import * ImportError: DLL load failed while importing _sqlite3: The specified module could not be found.
New submission from Tyler Reed : Running on a new, updated Windows 10 machine with no virtual environment. After removing all previous Python installations, rebooting and performing a fresh install if Python 3.9.1. I run the python console and type: import sqlite3 I receive the following error: Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec 7 2020, 17:08:21) [MSC v.1927 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python39\lib\sqlite3\__init__.py", line 23, in from sqlite3.dbapi2 import * File "C:\Program Files\Python39\lib\sqlite3\dbapi2.py", line 27, in from _sqlite3 import * ImportError: DLL load failed while importing _sqlite3: The specified module could not be found. I verified that the sqlite3.dll file does exist in C:\Program Files\Python39\DLLs -- messages: 386832 nosy: ZenSkunkworx priority: normal severity: normal status: open title: sqlite3 import * ImportError: DLL load failed while importing _sqlite3: The specified module could not be found. type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43201] sqlite3 import * ImportError: DLL load failed while importing _sqlite3: The specified module could not be found.
Tyler Reed added the comment: It was an environment issue. There were pre-existing files (pyd and pyc) in the application folder (from builds done with Kivy) and apparently python was loading those instead of the libraries in the python39 folder. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34215] streams.py:IncompleteReadError is message is unclear when expected is None
Tyler Bell added the comment: I've updated my PR to reflect a better message for the IncompleteReadError exception. When expected is None, the error reads, "IncompleteReadError: 1 bytes read on a total of None expected bytes" which is confusing. My PR changes this to "IncompleteReadError: 1 bytes read on a total of unknown expected bytes". Otherwise, it is required that whoever views the exception text(possibly through layers of abstraction), to know that None(a "low level" programmers decision) is equal to unknown. -- nosy: +Tyler Bell title: streams.py:readuntil IncompleteReadError is message is incorrect -> streams.py:IncompleteReadError is message is unclear when expected is None ___ Python tracker <https://bugs.python.org/issue34215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36917] ast.NodeVisitor no longer calls visit_Str
Tyler Wince added the comment: Another example of the breaking change here is in the security linter `PyCQA/bandit`. It may be a simple addition of a check in the meta parser for the ast but I would tend to agree with Anthony around whether or not it is worth it. Anyone else have any thoughts on this since the conversation ended last month? -- nosy: +Tyler Wince ___ Python tracker <https://bugs.python.org/issue36917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34215] streams.py:readuntil IncompleteReadError is message is incorrect
New submission from Tyler Bell : This may have already been cleared as I opened the PR months ago But the gist is that the Exception is misleading and the test is incorrect. -- components: Library (Lib) messages: 322329 nosy: mrbell...@gmail.com priority: normal pull_requests: 7975 severity: normal status: open title: streams.py:readuntil IncompleteReadError is message is incorrect type: enhancement versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue34215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34494] simple "sequence" class ignoring __len__
New submission from Tyler Reddy : Downstream in NumPy we've noticed that a "sequence" object defined as below will hang (infinite __getitem__ calls) if we try to turn it into an array. The same holds in CPython for converting it to a list: class OneList: def __len__(self): # this won't be checked by # PySequence_Fast and several # over C API calls return 1 def __getitem__(self, x): # called indefinitely by # i.e., PySequence_Fast return 1 Just to confirm -- this is intentional / desired behavior: list(OneList()) should hang in CPython? related: https://github.com/numpy/numpy/issues/8912 https://github.com/numpy/numpy/pull/11815 https://stackoverflow.com/a/43566241/2942522 -- messages: 324037 nosy: treddy priority: normal severity: normal status: open title: simple "sequence" class ignoring __len__ type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
New submission from Tyler Crompton : 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 <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 added the comment: Relevent PEP: http://www.python.org/dev/peps/pep-0409/ -- ___ Python tracker <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 : -- nosy: +ncoghlan, stoneleaf ___ Python tracker <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 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 <http://bugs.python.org/issue15208> ___ ___ 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 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 <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 :
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: >
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
<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 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
<http://bugs.python.org/issue15209>
___
___
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 <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
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 <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
<http://bugs.python.org/issue17125>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Tyler B added the comment: Looked at the code and found differences between 3.4 and 2.7. 2.7 has 3 exceptions that can be raised while 3.4 has 4 exceptions. I propose removing the "list of parameters" from the documenation to keep things simple and not repeat the code. # 2.7 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The parameters consist of the traceback as TOS1, the value as TOS2, the exception as TOS3, and None as TOS4." # 3.4 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 2. The parameters consist of the cause as TOS1, the exception as TOS2, and None as TOS3." How does this sound? -- nosy: +Tyler.B ___ Python tracker <http://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Tyler B added the comment: I wanted to make an edit so here's my revised comment: Looked at the code and found differences between 3.4 and 2.7. 2.7 has 4 exceptions that can be raised while 3.4 has 3 exceptions. I propose removing the "list of parameters" from the documenation to keep things simple and not repeat the code. # 2.7 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The parameters consist of the traceback as TOS1, the value as TOS2, the exception as TOS3, and None as TOS4." # 3.4 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 2. The parameters consist of the cause as TOS1, the exception as TOS2, and None as TOS3." How does this sound? -- ___ Python tracker <http://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Tyler B added the comment: One last edit: Looked at the code and found differences between 3.4 and 2.7. 2.7 has 4 exceptions that can be raised while 3.4 has 3 exceptions. I propose including the full list of parameters but describing the exceptions in a way that's less specific about the TOS order to keep the documentation as simple as possible. # 2.7 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The parameters can consist of the traceback as TOS1, the value as TOS2, the exception as TOS3, and None as TOS4." # 3.4 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 2. The parameters can consist of the cause as TOS1, the exception as TOS2, and None as TOS3." How does this sound? -- ___ Python tracker <http://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Tyler B added the comment: Here's a revised suggestion that has the order changed. I have additional concerns but please provide comment on this revision. Thanks # 2.7 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The parameters can consist of None as TOS1, the exception as TOS2, the value as TOS3, and the traceback as TOS4." # 3.4 "Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 2. The parameters can consist of None as TOS1, the exception as TOS2, and the cause as TOS3." -- ___ Python tracker <http://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX
New submission from Tyler Wade:
On Mac OSX, struct.unpack incorrectly handles bools.
Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.unpack('', b'\x00\x01\x02\x03')
(False, True, False, True)
--
assignee: ronaldoussoren
components: Macintosh
messages: 223470
nosy: ronaldoussoren, wayedt
priority: normal
severity: normal
status: open
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue22012>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29659] Expose the `length` arg from shutil.copyfileobj for public use
Changes by Tyler Goodlet : -- pull_requests: +288 ___ Python tracker <http://bugs.python.org/issue29659> ___ ___ 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 <http://bugs.python.org/issue15587> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Tyler Doyle added the comment:
It looks like file is getting set to '' and then indexed on line 553 below,
hitting the IndexError before we ever get to IOError.
--550---
file = getfile(object) <-- file = ''
sourcefile = getsourcefile(object)
if not sourcefile and file[0] + file[-1] != '<>': <-- ''[0]
raise IOError('source code not available')
file = sourcefile if sourcefile else file
--556---
Confirmed in 3.3
--
nosy: +T8y8
___
Python tracker
<http://bugs.python.org/issue17526>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Changes by Tyler Doyle : -- keywords: +patch Added file: http://bugs.python.org/file29576/inspect.patch ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Tyler Doyle added the comment: Patch and test to accompany. -- Added file: http://bugs.python.org/file29577/test_inspect.patch ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Changes by Tyler Doyle : Removed file: http://bugs.python.org/file29576/inspect.patch ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Changes by Tyler Doyle : Removed file: http://bugs.python.org/file29577/test_inspect.patch ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Changes by Tyler Doyle : Added file: http://bugs.python.org/file29591/17526_getsource.patch ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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 <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 : -- nosy: +twouters ___ Python tracker <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 <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 : -- keywords: +patch Added file: http://bugs.python.org/file42748/set_auto_history.patch ___ Python tracker <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 : -- status: pending -> open ___ Python tracker <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 <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 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 <http://bugs.python.org/issue26870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28352] winfo_pathname(..) | window id "xyz" doesn't exist in this application. | Python 3.4.4
New submission from Tyler Sweeden: This issue presents itself in 3.4.4.. Reverted back to 3.4.1 and the issue was gone. -- components: Tkinter messages: 278004 nosy: Tyler Sweeden priority: normal severity: normal status: open title: winfo_pathname(..) | window id "xyz" doesn't exist in this application. | Python 3.4.4 versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue28352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7336] threading module not properly handling shutdown
New submission from R. Tyler Ballance : Receiving a traceback when shutting down an interpreter with threads spawned inside of it: Traceback (most recent call last): File "/usr/lib/python2.6/threading.py", line 497, in __bootstrap self.__bootstrap_inner() File "/usr/lib/python2.6/threading.py", line 538, in __bootstrap_inner (self.name, _format_exc())) File "/usr/lib/python2.6/traceback.py", line 235, in format_exc etype, value, tb = sys.exc_info() AttributeError: 'NoneType' object has no attribute 'exc_info' According to mzz on #Python: 17:29 < mzz> rtyler: I think this is worth a bug report. If you look up threading.py:538 you'll find (assuming our line numbers match) that bit of code actually goes out of its way to deal with the shutdown problem I mentioned, but then it calls into the traceback module, which doesn't. -- components: Interpreter Core messages: 95361 nosy: rtyler severity: normal status: open title: threading module not properly handling shutdown type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7336> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
