[issue1207589] IDLE: Right Click Context Menu
Ned Deily added the comment: Andrew, this is clearly a new feature, not a bug. What is your rationale for adding it to the maintenance branches (2.7, 3.2, and 3.3)? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Changes by Georg Brandl ge...@python.org: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Hynek Schlawack added the comment: Éric, what’s your take on this approach (not code)? We have time enough till 3.4 but it seems this doesn't really move forward. Any thoughts how to get this moving? Unfortunately I'm not invested enough in this to make a educated decision. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Changes by Hynek Schlawack h...@ox.cx: -- nosy: +hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Changes by Hynek Schlawack h...@ox.cx: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15001] segmentation fault with del sys.module['__main__']
Hynek Schlawack added the comment: Fun fact, on 2.7 3.2 I get infinite loops @ 100% CPU. 3.3 default crash. Unless someone yells, I'll polish this up and commit next week. -- stage: - commit review versions: +Python 3.4 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15148] shutil.which() docstring could be clearer
Hynek Schlawack added the comment: Any reason why this is still open? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15148 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15104] Unclear language in __main__ description
Changes by Hynek Schlawack h...@ox.cx: -- nosy: -hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Changes by Hynek Schlawack h...@ox.cx: -- nosy: -hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16099] robotparser doesn't support request rate and crawl delay parameters
Changes by Hynek Schlawack h...@ox.cx: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)
Fergus Noble added the comment: Digging up an old issue but I am also interested in seeing this enhancement. Specifically to represent GPS time which is (currently) 16 seconds ahead of UTC. -- nosy: +Fergus.Noble ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Christian Theune added the comment: I pondered PyErr_NoMemory as well. However, I noticed not all locations in Python use PyErr_NoMemory to raise a MemoryError, and I'm also afraid that external libraries will have the same problem. Can you explain why you consider PyErr_NoMemory to be the better option? (I can think of performance but I wouldn't want to trade it in against reliability.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Serhiy Storchaka added the comment: This should be an issue on 64-bit too. slice(0,1,None).indices(sys.maxsize+1) -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16304] re: Match Objects always have a boolean value of True
Jan Duzinkiewicz added the comment: I agree this is unclear - If Match object always have a boolean value of True, it actually prevents me from using simple if statement - what's the point of if True: statement? - so the remark that matching functions do not always return match objects has some value. I've submitted a patch. -- keywords: +patch nosy: +dhgmgn Added file: http://bugs.python.org/file27838/16304.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16304 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16374] ConfigParser: Passing a semicolon as a value
Łukasz Langa added the comment: Well, the inline comment syntax was awkward to start with, that's why inline comments are now disabled by default since Python 3.2. For a more predictable situation with regard to comment handling, consider using the configparser 3.2+ backport for Python 2.6 and 2.7: http://pypi.python.org/pypi/configparser As for the original report, Michael is on the right track. Semicolon gets treated as a beginning of an inline comment if it's preceeded by a space, unless it's right after the key-value delimiter. In other words, these are inline comments: key1 = value ;inline comment! key2 =value ;inline comment! key3= value ;inline comment! key4=value ;inline comment! key5 : value ;inline comment! key6 :value ;inline comment! key7: value ;inline comment! key8:value ;inline comment! while these are not: key10 = value;value;value key11 = value; key12=; key13:; key14= ; key15: ; key16 = ; key17 : ; key18 : ; ;gotcha! Yes, key18's value is ; ;gotcha! which is also a quirk of the old ConfigParser. Moreover, # can be used for full-line comments but not for inline comments. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15962] Windows STDIN/STDOUT Redirection is actually FIXED
Jan Duzinkiewicz added the comment: I've referenced the kb article in the docs. Please let me know if the fix is ok - maybe the whole registry change process should be included in the docs directly? -- keywords: +patch nosy: +dhgmgn Added file: http://bugs.python.org/file27839/15962.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15962 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Serhiy Storchaka added the comment: Patch updated. Added tests for onerror. -- Added file: http://bugs.python.org/file27840/shutil_rmtree_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Serhiy Storchaka added the comment: Here are backported tests for 3.2 (they are passed). -- Added file: http://bugs.python.org/file27841/shutil_rmtree_tests-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Andrew Svetlov added the comment: I thought it's desirable feature which cannot produce backward incompatibility problems. Can revert commits for 2.7-3.3 if needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14878] Improve documentation for generator.send method
Jan Duzinkiewicz added the comment: The latest docs have a crossrefence at the end of the section: http://docs.python.org/3/reference/simple_stmts.html#grammar-token-yield_stmt I copied the reference to 2.7 docs -- keywords: +patch nosy: +dhgmgn Added file: http://bugs.python.org/file27842/14878.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Todd Rovito added the comment: Ned, I respectfully disagree that this is not a new feature. IDLE could always copy/cut/paste from the edit menu and it had a right click menu. All this patch does is add options to right click menu and call the same functions as the edit menu does. I could be biased because I worked on the patch and I am a new contributor but I think Andrew's logic of commenting the patch makes sense. Python is a great scripting language but IDLE is really falling behind and it is often the first thing a user sees. Thanks for your attention in this matter and I will respect any solution you and Amdrew come up with. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15148] shutil.which() docstring could be clearer
R. David Murray added the comment: Doesn't look like it. -- stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15148 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
R. David Murray added the comment: The reason for our no new features policy is that if a program works with version x.y, it should work for all x versions (modulo failing on an earlier version because of a bug...and conversely if it works on x.y, it should work on all later versions of x, which is why we also sometimes don't fix certain bugs in maintenance releases). In this case, if I understand correctly, there are no *programs* that can depend on the feature, just humans. So I think putting this in to bugfix releases is more analogous to the fixes-that-look-like-enhancements we occasionally put into the build infrastructure for Python itself (as opposed to distutils, which is governed by the normal backward compatibility rules). So, it's a judgment call and other developers might not agree with me, but I think it is OK. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no error/warnings
New submission from Albert Ferras:
I normally use dictionaries for configuration purposes in python, but there's a
problem where I have a dictionary with many key-values and one of the keys is
repeated.
For example:
lives_in = { 'lion': ['Africa', 'America],
'parrot': ['Europe'],
#... 100+ more rows here
'lion': ['Europe'],
#... 100+ more rows here
}
will end up with animal_lives_in['lion'] = 'Europe'. There's no way to detect
that I've written a mistake in the code because python won't tell me there's a
duplicated key assigned. It's easy to see when you have few keys but hard when
you've got many.
I think it should atleast raise a warning when this happens.
--
components: Interpreter Core
messages: 174507
nosy: Albert.Ferras
priority: normal
severity: normal
status: open
title: evaluating dict with repeated keys gives no error/warnings
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16385
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16386] imp.find_module does not specify registry key it searches on windows
New submission from Jan Duzinkiewicz: quote from http://docs.python.org/3/library/imp.html#imp.find_module: ...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file). I actually didn't know the registry key is listed in using Python on Window guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide. -- assignee: docs@python components: Documentation files: import_nt_reg.patch keywords: patch messages: 174508 nosy: dhgmgn, docs@python priority: normal severity: normal status: open title: imp.find_module does not specify registry key it searches on windows versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file27843/import_nt_reg.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16248] Security bug in tkinter allows for untrusted, arbitrary code execution.
Stefan Krah added the comment: Ramchandra Apte rep...@bugs.python.org wrote: Almost nobody knows that when using tkinter, code in .Tk.py is executed. (readprofile is not even documented!) While in your example, it is quite easy to see that it will run .bashrc The point of the example is that it's game over anyway once an attacker has write privileges to a user's home directory. sudo bash is certainly a more common operation than sudo tkapp.py, and users are not in the habit of auditing .bashrc each time they launch a shell. In fact, I'd probably be more likely to notice a new file .Tk.py than a small modification to my .bashrc. That said, I absolutely agree that *ideally* tkinter apps should not execute code from a startup file, especially if the startup file is *not* in the user's home directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Benjamin Peterson added the comment: Where it is now means raising a MemoryError in Python code will cause the fatal error. I don't know if that's a good idea. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*
Changes by Brett Cannon br...@python.org: -- type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16387] test_cmd_line_script failures
New submission from Stefan Krah:
test_cmd_line_script is failing on multiple buildbots:
==
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest)
--
Traceback (most recent call last):
File
/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/test_cmd_line_script.py,
line 373, in test_non_utf8
importlib.machinery.SourceFileLoader)
File
/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/test_cmd_line_script.py,
line 126, in _check_script
rc, out, err = assert_python_ok(*run_args)
File
/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/script_helper.py,
line 54, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File
/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/script_helper.py,
line 46, in _assert_python
stderr follows:\n%s % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-20:
ordinal not in range(128)
--
Ran 23 tests in 4.646s
--
components: Tests
keywords: buildbot
messages: 174511
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_cmd_line_script failures
type: behavior
versions: Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16387
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Guido van Rossum added the comment: There used to be some places in the C code that raise MemoryError to indicate that some parameter indicating a desired result size is out of range, i.e. before even trying to allocate anything. I can't confirm any, but these should probably be replaced with another exception. (I thought string times integer was one such place, but it raises OverflowError now.) If there are any left those should probably be replaced with OverflowError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Lukas Lueg added the comment: I have to say this feels like spooky action at a distance. Wouldnt it be less intrusive - while achieving the same result - to make MemoryError uncatchable if the flag is set? -- nosy: +ebfe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Roundup Robot added the comment: New changeset 0b5f00ccf907 by Stefan Krah in branch '3.3': Issue #16145: Support legacy strings in the _csv module. http://hg.python.org/cpython/rev/0b5f00ccf907 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16145 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Christian Heimes added the comment: MemoryError can be raised under two different circumstances that should be handled differently. Either the program tries to allocate a rather large chunk of memory for e.g. a string with a couple of hundred KB and more. Or Python can't malloc() even small amounts of memory for its most basic operations like raising an exception object. That's why PyErr_NoMemory() exists and why it uses a pre-allocated MemoryError object. When a program can't allocate memory for an image it usually has enough memory left to do proper error reporting and shut down. However when even x = 2 * 200 fails with a memory error then proper shutdown will most likely fail and hang up the process, too. Too bad that PyErr_NoMemory() is used for both scenarios and isn't aware how much memory was requested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16145] Abort in _csv module
Stefan Krah added the comment: Andrew and Serhiy, thanks for the reviews. Should be fixed now. -- assignee: - skrah resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16145 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Guido van Rossum added the comment: Well, you can fix that, right? Just add a new function with a better signature and use that for one of the two scenarios. (I think third scenario might be when realloc fails -- IIRC it doesn't guarantee that the original pointer is still valid either?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Terry J. Reedy added the comment: It it not a new library feature that anyone would use in other code. I have been meaning to raise this issue on pydev to see what others think. There are advantages to keeping the *human* interaction with IDLE consistent between releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings
Ramchandra Apte added the comment: This is an unavoidable behaviour of the hash tables (dictionaries) I don't see much use cases of a warning. -- nosy: +ramchandra.apte title: evaluating dict with repeated keys gives no error/warnings - evaluating dict with repeated keys gives no warnings ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings/errors
Ramchandra Apte added the comment: Retract earlier statement. I didn't read the comment fully. -- title: evaluating dict with repeated keys gives no warnings - evaluating dict with repeated keys gives no warnings/errors ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Stefan Krah added the comment:
Some of the buildbots are failing with the new test:
==
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest)
--
Traceback (most recent call last):
File
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_cmd_line_script.py,
line 373, in test_non_utf8
importlib.machinery.SourceFileLoader)
File
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_cmd_line_script.py,
line 126, in _check_script
rc, out, err = assert_python_ok(*run_args)
File
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/script_helper.py,
line 54, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/script_helper.py,
line 46, in _assert_python
stderr follows:\n%s % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-20:
ordinal not in range(128)
--
Ran 23 tests in 8.959s
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16218
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings/errors
Ramchandra Apte added the comment: You should be using json for configuration purposes anyway. This is low priority as only few programs use dictionaries with a gazillion keys. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16387] test_cmd_line_script failures
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - duplicate stage: needs patch - committed/rejected status: open - closed superseder: - Python launcher does not support non ascii characters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Serhiy Storchaka added the comment: Tests simplified. Thanks Hynek for review and advices. -- Added file: http://bugs.python.org/file27844/shutil_rmtree_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file27845/shutil_rmtree_tests-3.2_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file27840/shutil_rmtree_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file27841/shutil_rmtree_tests-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Lukas Lueg added the comment: In any strategy only a heuristic could be used in order to decide wether or not it's safe to raise MemoryError. How exactly is memory pressure expected for x=[2]*200 but not for x=2*200 ? I don't think a new function could ultimatly achieve it's goal. If MemoryError occurs, all bets are off. Shutting down as fast as possible is the best we could do, if requested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings/errors
Albert Ferras added the comment: I would use json, but it allows me to set list/strings, etc.. not python objects like I'd want -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings/errors
Albert Ferras added the comment: sorry: *it only allows me -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Christian Heimes added the comment:
Of course it can be fixed. But it's going to be a long and tedious piece of
work. PyErr_NoMemory() is called 314 times. MemoryError is raised about 40
times in C code.
I'm not sure what your question about realloc() really is. Are you unsure how a
a failing realloc() calls must be resolved?
Code like
ptr = realloc(ptr, size);
is usually a memory leak as it leaks the previously allocated memory in ptr. In
the error case the block in ptr is left untouched and is still valid. It must
be freed manually or can be used further and freed later.
if((ptr2 == realloc(ptr, size)) == NULL) {
free(ptr);
}
else {
ptr = ptr2;
}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16381
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating dict with repeated keys gives no warnings/errors
Albert Ferras added the comment: also, it creates confusion when this happens -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Jesús Cea Avión added the comment: Reopening bug. Quite a few buildbots are failing with this patch. Please, commit a new version or revert. -- resolution: fixed - stage: committed/rejected - commit review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
R. David Murray added the comment: It is a nice suggestion, but it is also probably a non-trivial change to the parser. If you want to try coming up with a patch we would consider it, but I suspect there is a limit to how much complexity we'd be willing to add to the parser code for this. It would also be a backward incompatible change, so it could only go into a new release regardless. (On the other hand Benjamin might take a look at this and say oh, that's easy and make some magic happen. You never know :) -- nosy: +r.david.murray priority: normal - low title: evaluating dict with repeated keys gives no warnings/errors - evaluating literal dict with repeated keys gives no warnings/errors type: behavior - enhancement versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Andrew Svetlov added the comment: I see. Sorry, my fault. Give me weekend to figure out why it fails. Thanks. -- assignee: - asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Christian Heimes added the comment: We can create some kind of heuristic when the memory error handler knows the size of the new block and the size difference on realloc(). It could be an application specific threshold, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Lukas Lueg added the comment: The heuristic basically has to decide if memory pressure is so high that it's not save to return to the interpreter. Even if there is a chosen value (e.g. failed allocation attempts below 1mb are considered fatal), there can always be another OS-thread in the interpreter process that eats away exactly that memory while we are returning MemoryError - the program might still hang. FWICS all MemoryErrors are to be considered fatal or none of them -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
Lukas Lueg added the comment:
This could be avoided by
lives_in_init = (('lion': ['Africa', 'America']), ('lion': ['Europe']))
lives_in = {}
for k, v in lives_in_init:
assert k not in lives_in
lives_in[k] = v
del lives_in_init
Which is fast enough if executed only during module-loading
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16385
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
Benjamin Peterson added the comment:
An error is out of the question for compatibility reasons. I think the idea for
a warning should be brought up on the python-ideas list. Silently rejecting
duplicates has a lot of precedent, though. For example, set literals and the
dict constructor:
dict(((dfs, 2), (dfs, 3)))
{'dfs' : 3}
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16385
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename
Stefan Krah added the comment: One of 13ebaa36d87d, 9f696742dbda or 6903f5214e99 causes test failures in test_pep277: == FAIL: test_failures (test.test_pep277.UnicodeFileTests) -- Traceback (most recent call last): File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pep277.py, line 120, in test_failures self._apply_failure(os.listdir, name) File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pep277.py, line 105, in _apply_failure self.assertEqual(wildcard, '*.*') AssertionError: '7_\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1' != '*.*' - 7_\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1 + *.* -- nosy: +skrah resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename
Stefan Krah added the comment: Additionally, some of the changes cause a failure in test_subprocess: == ERROR: test_no_leaking (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File C:\Users\stefan\pydev\cpython\lib\test\test_subprocess.py, line 823, in test_no_leaking handles.append(os.open(tmpfile, os.O_WRONLY|os.O_CREAT)) FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'c:\\users\\stefan\\appdata\\l ocal\\temp\\tmpa41o4x\\@test_2236_tmp' -- -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Roger Serwy added the comment: In a strict sense, the patch does break backward compatibility for third-party IDLE extensions that modify the rmenu_specs contents. It is not a private value since it lacks an initial underscore in its name. But given how undocumented IDLE is, especially its extension facility, I don't think poses any problems. (For what it's worth, I'm the developer of IdleX and I already released a trivial workaround for this change. I welcome this improvement to IDLE, especially when it deprecates an existing IdleX extension.) While keeping UI consistency may be desirable, keeping it crippled is not. Even Window's Notepad has a decent right-click menu. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
R. David Murray added the comment: Ah. Well, we prefer to err on the side of strictness for backward compatibility, so I think we should treat this as an enhancement, then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16388] Urllib screws up capitalization in User-Agent HTTP Header
New submission from Calvin Owens: Urllib encodes as: User-agent The correct form is: User-Agent This is quite important, as it makes this library totally unusable for scraping moronic websites which require a recognized User-Agent string to work correctly, of which there are many. -- components: Library (Lib) messages: 174540 nosy: Calvin.Owens priority: normal severity: normal status: open title: Urllib screws up capitalization in User-Agent HTTP Header type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16388] Urllib screws up capitalization in User-Agent HTTP Header
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - urllib/httplib header capitalization ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Roundup Robot added the comment: New changeset 969069d464bc by Stefan Krah in branch '3.3': Issue #15814: Use hash function that is compatible with the equality http://hg.python.org/cpython/rev/969069d464bc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Roundup Robot added the comment: New changeset 969069d464bc by Stefan Krah in branch '3.3': Issue #15814: Use hash function that is compatible with the equality http://hg.python.org/cpython/rev/969069d464bc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207589] IDLE: Right Click Context Menu
Ned Deily added the comment: I think it is clear that this is an enhancement. So then the question is: is there a good reason to make an exception here to the no new features in maintenance releases policy? David mentioned some considerations. I would add testing and documentation. Testing is a *big* concern with IDLE since IDLE is so dependent on Tk and we know from long experience that there can be differences among the various platform-specific Tk implementations (we currently support at least 4 different Tk varieties) and we have no standard automated tests for IDLE. So that increases the risk that we could break something in a maintenance release which we try really hard not to do. On the other hand, there is something to be said about maintaining compatibility as best as possible across IDLE version. I'm not fundamentally opposed to including this enhancement in maintenance releases. But I think it is important to recognize that it is an exception to policy and to have this discussion about it. Personally, I'm +0 on the whole feature - it's not something I would use - so I don't really have a stake in it. I do have a bit of a stake in the testing part and for that reason I'm -0 on the backports. I'm glad to see Todd tested on Linux and OS X - presumably someone has tested on Windows. If the backports remain, the feature should at least be smoke-tested at some point on all four of the branches and with all of the major Tk versions (Windows, X11, OS X Cocoa Tk 8.5, OS X Carbon Tk 8.4). Since he has the most experience in this area, I'm willing to defer to Roger's judgement call on the impact of this change with regard to IDLE extensions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Mark Dickinson added the comment: For 2.7, I don't see any problem with raising OverflowError for a length that's sys.maxsize, since it's hard to have sequences larger than that anyway. For 3.x, I'd also see this behaviour as reasonable, and not a bug. If it's raising OverflowError for lengths *smaller* than sys.maxsize, that's a bug. Unless that's the case, I'd call this a feature request for 3.4, rather than a bug that needs fixing in all the maintenance branches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Mark Dickinson added the comment: If it's raising OverflowError for lengths *smaller* than sys.maxsize, that's a bug. Ah, reading Ned's comment, it looks like that's exactly what it's doing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16347] configure.ac patch
Éric Araujo added the comment: This is due to the fact on the 64 bit they split lib and lib64 directories. This depends on the specific multiarch implementation. Debian 64-bit only has /usr/lib for instance. I had a look at the patch but did not understand what it does. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16347 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16388] Urllib screws up capitalization in User-Agent HTTP Header
Calvin Owens added the comment: 2275 hasn't been touched for almost 2 years. If there was a fix in v3.3, it ought to be backported. But it doesn't look like they ever came up with one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16347] configure.ac patch
Antonio Cavallo added the comment: Hi, the patch it is really simple, it adds the @LIB@ and @ARCH@ variables to the configure machinery. If you look into the Makefile.pre.in: INCLUDEDIR=¬@includedir@ CONFINCLUDEDIR=¬$(exec_prefix)/include SCRIPTDIR=¬…$(prefix)/lib This hardcodes lib that can be right on debian derivatives but on many other distributions it would be lib64 (fedora and opensuse notable ones). In theory SCRIPTDIR could be se to @libdir@ but... Samples of that hardcoded path (lib) are spread all over the source code and there're specific patches for these. This patch should make easier later on to fix these, in fact the patch should be totally safe (at least that would be my aim) with no impact. I hope this helps, thanks -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16347 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Serhiy Storchaka added the comment: I was not able to reproduce this error, I got other errors. The issue not in Python interpreter, the test is broken. Here is a patch that might solve the issue on some platforms (need to test on Windows). I guess failing of all command line tests when the path to temporary directory contains non-ascii. -- Added file: http://bugs.python.org/file27846/pythonrun_filename_decoding_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
New submission from Philip Jenvey: #9396 replaced a few caches in the stdlib w/ lru_cache, this made the mako_v2 benchmark on Python 3 almost 3x slower than 2.7 The benchmark results are good now that Mako was changed to cache the re itself, but the problem still stands that lru_cache seems to hurt the perf of inline res compared to 2.7. The fix for Mako did not affect the 2.7 benchmark numbers See more info here: http://mail.python.org/pipermail/python-dev/2012-November/122521.html -- components: Library (Lib) messages: 174550 nosy: brett.cannon, ncoghlan, pjenvey, rhettinger, zzzeek priority: normal severity: normal status: open title: re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench type: performance versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Paul Upchurch added the comment: For the concept of reasonable, it should be noted that this behaviour will affect code that works with reasonably sized sequences despite the largeness of the parameter. Consider an extremely large array. To work with such an array, one would typically break it into small segments. However, to simplify the code and reduce bugs it makes sense to use a consistent indexing method on each segment. The size of its parameter does not say anything about the size of a segment. Consider a class which implements virtual arrays. def __getitem__(...): ... start,stop,step=slice.indices(start,stop,step).indices(126) while True: if step0 and start=stop: break if step0 and start=stop: break p=pageid(start) make_page_resident(p) do work ... start=start+step As you can see, slice.indices should not be limited to sys.maxsize. If Python can perform the arithmetic calculation sys.maxsize+1 then slice.indices(sys.maxsize+1) should also work. The usage of slice.indices is to ensure consistent behaviour of the slicing operator. Another workaround for this bug: 5. write your own implementation of slice.indices I consider this a workaround. The correct way to handle the index parameter to __getitem__ and __setitem__ is to use slice.indices. That way, if the semantics of slicing changes in future versions of Python, your class will behave consistently. It seems to me that this is the main reason why slice.indices exists at all: to prevent inconsistent behaviour when people implement __getitem__ and __setitem__. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Serhiy Storchaka added the comment:
I think the issue is than slice constructor accepts integer out of Py_ssize_t
range. And more, it accepts any objects, not only integers or None.
slice(3.4, 'a', {})
slice(3.4, 'a', {})
May be we should disallow creating of such doubtful slices and raise TypeError
or OverflowError.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
Changes by Ezio Melotti ezio.melo...@gmail.com: -- keywords: +3.3regression nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16248] Security bug in tkinter allows for untrusted, arbitrary code execution.
Antoine Pitrou added the comment: I'm gonna point people to the discussion about the -s flag of the Python interpreter (added as part of PEP 370), since the issue is conceptually identical: http://mail.python.org/pipermail/python-dev/2008-January/076130.html Adding Christian to the discussion since he was the author and implementor of that PEP. -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
Changes by Antoine Pitrou pit...@free.fr: -- stage: - needs patch versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16390] re compilation slow in Python 3.3 due to functools.lru_cache overhead
New submission from Brett Cannon: The Mako developers discovered that under Python 3.3 their library under the mako_v2 benchmark went from 2.95x slower than Python 2.7 to 1.25x slower by simply avoiding an re compilation: http://www.makotemplates.org/trac/changeset/c1468b12f115ac9e469150ce24ea042aeae5e270 Their profiling showed that functools.lru_cache in rc._compiled_typed was a major contributor: http://paste.ofcode.org/yZRKnJfTsHesFR8hMWfc7f -- components: Library (Lib) messages: 174554 nosy: brett.cannon, pjenvey priority: normal severity: normal stage: needs patch status: open title: re compilation slow in Python 3.3 due to functools.lru_cache overhead type: performance versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16390 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16390] re compilation slow in Python 3.3 due to functools.lru_cache overhead
Philip Jenvey added the comment: Sorry Brett, beat you to it w/ #16389 =P -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16390 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16248] Security bug in tkinter allows for untrusted, arbitrary code execution.
Christian Heimes added the comment: It's gonna take a while to read this ticket ... Some comments: The code in site.py already does some checks, for example getuid() == geteuid(). System code and code that is run with administrator privileges shall be run with -Es to prevent code injection. See https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/938869 comment #24 for an issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Mark Dickinson added the comment: Paul: I think you make good arguments that this should be fixed for 3.4. I do however think that for versions earlier than 3.4 this 'fix' would be bordering on a new feature; it's also likely to require significant new code and tests, and so I'd be wary of introducing such a change in a maintenance release. I'd propose to fix this for 3.4 only. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14794] slice.indices raises OverflowError
Mark Dickinson added the comment: I'll look at creating a patch for 3.4 -- assignee: - mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
Antoine Pitrou added the comment: lru_cache() seems to use a complicated make_key() function, which is invoked on each cache hit. The LRU logic is probably on the slow side too, compared to a hand-coded logic which would favour lookup cost over insertion / eviction cost. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16353] add function to os module for getting path to default shell
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16354] Remember python version choice on docs.python.org
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16379] SQLite error code not exposed to python
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti, ghaering stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16379 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16382] Better warnings exception for bad category
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16382 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16354] Remember python version choice on docs.python.org
Changes by Georg Brandl ge...@python.org: -- resolution: - works for me status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Stefan Krah added the comment:
Serhiy, your original example from msg173373 still fails on
FreeBSD:
$ name=$(printf \xff)
$ echo print('Hello, world') $name
$ ./python $name
UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 0:
ordinal not in range(128)
[41257 refs]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16218
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16218] Python launcher does not support non ascii characters
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- nosy: -vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16383] Python 3.3 Permission Error with User Library on Windows
Jim Pattee added the comment: The problem is not file permissions nor the install. I did some further testing. The problem actually occurs with the library calls at lines 23 and 25. I changed these lines to eliminate the library call by just hard coding the file path. Change from: line 23:header_path = libastyle.get_astyle_directory() + /src/astyle.h line 25:beautifier_path = libastyle.get_astyle_directory() + /src/ASBeautifier.cpp Change to: line 23:header_path = C:\\Users\\jimp\\ZPythonPermissionError\\Projects/AStyle/src/astyle.h line 25:beautifier_path = C:\\Users\\jimp\\ZPythonPermissionError\\Projects/AStyle/src/ASBeautifier.cpp When run with the changes the program worked. The problem is apparently with the library call, not the file itself. Then I changed the same instructions to get the file name using the same instructions that the library program used. The library program uses “sys.path[0]” to get the directory containing the executed script. Change to: line 23:header_path = sys.path[0] + /../AStyle/src/astyle.h line 25:beautifier_path = sys.path[0] + /../AStyle/src/ASBeautifier.cpp This also worked. I want to do some more testing this weekend. I will hopefully have more info on Monday. Thanks for your input on this. Apparently this is not a problem on your PC. I have run this on both Windows 7 and Windows 8. I get the same results (a Permission Error) on both. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16383 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16383] Python 3.3 Permission Error with User Library on Windows
R. David Murray added the comment: Well, I run linux, not Windows. I haven't even looked at your code, frankly, since it is a zip file and includes third party stuff. Maybe a windows dev will find time to look at it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16383 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
