[issue457066] pow(a,b,c) should accept b0
Thomas Dybdahl Ahle lob...@gmail.com added the comment: For anyone who finds this through google, if you are finding the inverse mod a prime, you can use fermats little theorem: pow(a, -1, mod) = pow(a, a-2, mod). (You also need that mod doesn't divide a). -- nosy: +Thomas.Dybdahl.Ahle ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue457066 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13835] whatsnew/3.3 misspelling/mislink
New submission from July Tikhonov july.t...@gmail.com: 1) Paragraph describing range() comparison links to issue13021. This issue seems unrelated. It should be issue13201. 2) Paragraph describing of unicode_internal codec, mentions (utf-16-le or utf-16-le) and (utf-32-le or utf-32-le). It should be (utf-16-le or utf-16-be) and (utf-32-le or utf-32-be) respectively. -- assignee: docs@python components: Documentation files: whatsnew-3.3-misspelling.diff keywords: patch messages: 151765 nosy: docs@python, july priority: normal severity: normal status: open title: whatsnew/3.3 misspelling/mislink versions: Python 3.3 Added file: http://bugs.python.org/file24291/whatsnew-3.3-misspelling.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Boštjan Mejak bostjan.me...@gmail.com added the comment: Terry, I agree with you on having *i*th instead of *i*-th. The fact that i is written in italics eliminates the need of a hyphen. Justin, can I ask you to make a new patch which fixes key-function to key function and *i*'th to *i*th This is the last decision. Also, if anyone of you can, please then just incorporate that final patch that Justin will make. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Stefan Krah stefan-use...@bytereef.org added the comment: This is the last decision. Also, if anyone of you can, please then just incorporate that final patch that Justin will make. Thanks. Stop acting like a manager. A while ago a person had his account disabled for constantly bumping up issues and telling other people what to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Boštjan Mejak bostjan.me...@gmail.com added the comment: Yeah, I guess I was kind of rude. Sorry about that. I think my proposal is acceptable. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13835] whatsnew/3.3 misspelling/mislink
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8a38bbf92048 by Sandro Tosi in branch 'default': Issue #13835: fixes to What's new 3.3; patch by July Tikhonov http://hg.python.org/cpython/rev/8a38bbf92048 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13835] whatsnew/3.3 misspelling/mislink
Sandro Tosi sandro.t...@gmail.com added the comment: Thanks July, I've just committed your patches! -- nosy: +sandro.tosi resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file24222/random-6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file24254/random-fix_tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file24253/random-7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file24198/random-5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13836] Define key failed
New submission from olivier pyt...@noetika.com: Hi, I tried to define new key in python idle and then python 2.5.1 failed to launch. What I did : I defined a new key, applied and changed my mind, removed my key set named 'ole'. I launched cmd C:\Python25\Lib\idlelib..\..\python idle.py got dozens of messages : Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'redo' from section 'ole'. returning default value: '' Finally, this opened python idle so I went again to configure idle/keys and saw that my key set was still there. I selected again Delete custom Key set and now it's ok. -- messages: 151771 nosy: olivier57 priority: normal severity: normal status: open title: Define key failed versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Charles-François Natali neolo...@free.fr added the comment: As a Python user (and not a committer), I disagree. As an user, I don't care too much where the function should be placed (although I believe os or sys are sensible choices). What I do care is that I want a extremely simple function that will just work. Don't make me add code for handling all the extra cases, such code should be inside the function. For what it's worth, as a Python committer, I agree with you. Python is a very high level language, and I think the standard library should be as natural and offer the same productivity gain as the core language does. Exposing to the user a mere wrapper around a syscall/library just doesn't make sense to me. Sure, it should be made available for those who want/need to do low-level system programming (and I'm one of those), but the vast majority of users want something higher level than the POSIX/Windows library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13829] exception error
Dan kamp bitbuc...@roontoon.com added the comment: I have received this from the macpython listserv it that helps. Would really like to find this issue. From the traceback, it appears that there is a problem with Python's _scproxy module; that's an internal helper C module that provides an interface to the OS X System Configuration framework to access Internet proxy configurations for the urllib module. You should open an issue for this at bugs.python.org. Please include the original crash report traceback. On Jan 21, 2012, at 12:03 PM, Brett Cannon wrote: Brett Cannon br...@python.org added the comment: Then I'm going to assume the bug lies with Moviegrabber doing something wrong and it isn't Python's direct fault. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13829 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4966] Improving Lib Doc Sequence Types Section
Nick Coghlan ncogh...@gmail.com added the comment: Éric, are you still planning to work on this? Otherwise I'll make a first pass at doing the split into 3 sections (as per my earlier comment) and implementing some of Terry's suggestions. Linked Hg repo is a 2.7 based feature branch where I'll be publishing my changes as I make them. -- hgrepos: +106 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Terry J. Reedy tjre...@udel.edu added the comment: Justin, if you do a new patch, put both changes in one .diff. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6727] ImportError when package is symlinked on Windows
Jason R. Coombs jar...@jaraco.com added the comment: After hearing back from Microsoft support (and by proxy, the Visual Studio development team), it is clear that this issue is very low priority for them (they see it as having trivial business impact), so we cannot expect it to be fixed in the upstream libraries anytime soon. This response essentially means that if Python wants to support these symbolically-linked directories, it cannot use stat/wstat on Windows and must use instead the Windows APIs. As seen in issue13412, this bug not only affects import.c, but also affects posixmodule (such as with os.listdir). After addressing this issue for import.c, it will probably be necessary to also address it for other parts of Python that use stat/wstat (or other calls that depend on those calls). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4966] Improving Lib Doc Sequence Types Section
Ezio Melotti ezio.melo...@gmail.com added the comment: Éric is without Internet till the end of the month, so I think it's OK if you go ahead and start working on this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13814] Document why generators don't support the context management protocol
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
vr gamer vrgam...@gmail.com added the comment: I'm not certain that I agree with the argument used to justify keeping this as a 'normal' priority issue. Apparently, since it doesn't effect the entire python community and being as there is no readily available solution, the decision is to treat it as a minor problem. Were one to apply the same logic to, what say, epidemiology, then I suppose the lack of a vaccine for HIV would not be a particularly pressing issue either. If priority escalation is out of the question, can we at least have an update? After three years of workarounds, I'm beginning to suspect that the idea is to wait until the effected packages become deprecated and then declare 'solved!'. -- nosy: +vr.gamer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Antoine Pitrou pit...@free.fr added the comment: But I observe that unless I explicitly flush stdout and stderr before terminating, the output is lost entirely, even if the exit is not abnormal. This isn't the desired behavior, is it? Indeed that's a bit surprising. Which Python version are you using? Under Unix or Windows? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs
Michał Michalski pyt...@michalski.im added the comment: Maybe it will sound strange, but what is this task REALLY about? I mean - I can see two problems here, but no clear information about which problem is a real problem and - if it is - what is the expected behavior. Problems I can see are: 1) Type of returned value changes depending on the value source (list for user provided or list for default) 2) It's impossible to set list as 'default' I understand that this task concentrates on 1st one, however changing behavior described in 2nd would - in my oppinion - fix 1st one too - am I right? User would define the returned type by defining the 'default' as a list or string. But - if we assume that we only discuss 1st problem here - what is the expected behavior? Provided workaround is suggesting that we expect string, but - basing on current nargs behavior and intuition - I'd rather expect to get a list, when I define nargs with * or +. This sounds natural for me. Could someone explain me the problem and the expected behavior in a clear way? Sorry if I'm not clear, but it's my first post here and maybe I've missed something in the description or I assume something that is not true (especially that the task is quite old... ;) ). -- nosy: +regis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9625 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein jon.brandv...@gmail.com added the comment: On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not under 2.7.1. On Linux, I have not reproduced the problem on versions 2.6.3, 2.7.2, 3.1.1, or 3.2.2. So to summarize: - It seems there should be a stderr flush call on the line I indicated, for symmetry with the surrounding code. - Even without this line, it should still be flushed automatically upon child process exit, but this doesn't happen under Windows and Python 3.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Antoine Pitrou pit...@free.fr added the comment: Le dimanche 22 janvier 2012 à 17:58 +, Jon Brandvein a écrit : Jon Brandvein jon.brandv...@gmail.com added the comment: On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not under 2.7.1. On Linux, I have not reproduced the problem on versions 2.6.3, 2.7.2, 3.1.1, or 3.2.2. Thanks. - Even without this line, it should still be flushed automatically upon child process exit, but this doesn't happen under Windows and Python 3.x. Yes, that's what surprises me. There's no reason for stderr not to be flushed implicitly at process end, since that's part of sys.stderr's destructor, which should be called at shutdown. That said, it certainly doesn't harm to add a flush() call there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13837] test_shutil fails with symlinks enabled under Windows
New submission from Antoine Pitrou pit...@free.fr: This happens when symlinks are enabled under Windows. This doesn't affect any buildbots since they don't run the tests as administrator (or they are not recent enough to have symlink support): == FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil) -- Traceback (most recent call last): File C:\t\cpython\lib\test\test_shutil.py, line 193, in test_copymode_follow _symlinks self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode) AssertionError: 33206 != 33060 == FAIL: test_move_dangling_symlink (test.test_shutil.TestMove) -- Traceback (most recent call last): File C:\t\cpython\lib\test\test_shutil.py, line 58, in wrap return func(*args, **kwargs) File C:\t\cpython\lib\test\test_shutil.py, line 1136, in test_move_dangling_ symlink self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link)) AssertionError: 'c:\\users\\antoine\\appdata\\local\\temp\\tmp8bl4eu\\baz' != 'c :\\users\\antoine\\appdata\\local\\temp\\tmplc6h2h\\quux' - c:\users\antoine\appdata\local\temp\tmp8bl4eu\baz ?-- ^^ + c:\users\antoine\appdata\local\temp\tmplc6h2h\quux ? ^^^ ^^ -- components: Library (Lib), Tests messages: 151783 nosy: brian.curtin, hynek, pitrou, tim.golden priority: normal severity: normal stage: needs patch status: open title: test_shutil fails with symlinks enabled under Windows type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13837] test_shutil fails with symlinks enabled under Windows
Antoine Pitrou pit...@free.fr added the comment: (tests were added in #12715 and #9993) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13772] listdir() doesn't work with non-trivial symlinks
Antoine Pitrou pit...@free.fr added the comment: Another issue with the detection scheme is that it's not atomic: there can be a race condition between the GetFileAttributesExW() and CreateSymbolicLinkW() calls. I propose applying the following patch to 3.2 and 3.3 (+ doc fix, not included in the patch). -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file24292/windirlink.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13520] Patch to make pickle aware of __qualname__
Changes by Hynek Schlawack h...@ox.cx: -- nosy: +hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Boštjan Mejak bostjan.me...@gmail.com added the comment: I fixed Justin's patch. Anyone cares to incorporate it? -- Added file: http://bugs.python.org/file24293/fixed patch final.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13816] Two typos in the docs
Georg Brandl ge...@python.org added the comment: Sorry, but the patch introduces two markup errors: - *i*th is invalid reST, it needs to be *i*\ th - you broke the table markup (the vertical lines must be aligned) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13834] In help(bytes.strip) there is no info about leading ASCII whitespace
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 960d93deb8c2 by Georg Brandl in branch '3.2': Fix #13834: strip() strips leading and trailing whitespace. http://hg.python.org/cpython/rev/960d93deb8c2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13834] In help(bytes.strip) there is no info about leading ASCII whitespace
Georg Brandl ge...@python.org added the comment: Fixed, thanks! -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13838] In str.format {0:#.5g} for decimal.Decimal doesn't print trailing zeros
New submission from py.user port...@yandex.ru:
http://docs.python.org/py3k/library/string.html#format-specification-mini-language
The '#' option:
For floats, complex and Decimal the alternate form causes the result of the
conversion to always contain a decimal-point character, even if no digits
follow it. Normally, a decimal-point character appears in the result of these
conversions only if a digit follows it. In addition, for 'g' and 'G'
conversions, trailing zeros are not removed from the result.
1)
import decimal
'{0:#.5g}'.format(1.5)
'1.5000'
'{0:.5f}'.format(decimal.Decimal(1.5))
'1.5'
'{0:.5g}'.format(decimal.Decimal(1.5))
'1.5'
'{0:#.5g}'.format(decimal.Decimal(1.5))
'1.5'
no zeros with #
2)
import decimal
'{0:#.5g}'.format(decimal.Decimal('1.5000'))
'1.5000'
'{0:.5g}'.format(decimal.Decimal('1.5000'))
'1.5000'
zeros without #
--
components: Interpreter Core, Library (Lib)
messages: 151790
nosy: py.user
priority: normal
severity: normal
status: open
title: In str.format {0:#.5g} for decimal.Decimal doesn't print trailing zeros
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13838
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13838] In str.format {0:#.5g} for decimal.Decimal doesn't print trailing zeros
Eric V. Smith e...@trueblade.com added the comment: See issue #7098 for a discussion. I propose to close this issue. -- nosy: +eric.smith, mark, skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein jon.brandv...@gmail.com added the comment: I've been looking over this package some more, and in particular, /Lib/multiprocessing/forking.py. There's plenty I don't understand, and I do have questions, if you would be willing to indulge me. I see that both the unix and windows codepaths define an exit alias for terminating the child process without performing any cleanup. On unix, this is os._exit (though it calls it directly in Popen.__init__() instead of using the alias). On Windows, it is the win32 ExitProcess() function. A quick check confirms that replacing this windows alias with exit = sys.exit causes flushing to occur. So my main question is: What's wrong with using sys.exit()? I would speculate it's either because there's shared state between child and parent, or to avoid propagating SystemExit through user code in the case freeze_support() was used. If forking.py is to terminate directly via the OS, I think it's forking.py's responsibility to flush stdout and stderr in main() on the Windows side, the way it does in Popen.__init__() on the unix side. I also want to point out that the sys.exit() in freeze_support() is unreachable due to the exit() in main(). So it no longer surprises me that the output is not being flushed in Python 3 under windows. What surprises me is that it *is* flushed in Python 2. I remember hearing something about differences between 2 and 3 in how they handle buffering, so I'm investigating this for my own curiosity. Incidentally, Python 2 still flushes when I remove newlines from my output text, so line buffering doesn't seem to be impacting my observations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13838] In str.format {0:#.5g} for decimal.Decimal doesn't print trailing zeros
Changes by Eric V. Smith e...@trueblade.com: -- nosy: +mark.dickinson -mark ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7098] g formatting for decimal types should always strip trailing zeros.
Changes by py.user port...@yandex.ru: -- nosy: +py.user ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13838] In str.format {0:#.5g} for decimal.Decimal doesn't print trailing zeros
py.user port...@yandex.ru added the comment: my question is about the # option it is described as working with Decimal but it doesn't work with Decimal -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment: @dmalcolm: How did you chose Py_MAX_AVERAGE_PROBES_PER_INSERT=32? Did you try your patch on applications like the test suite of Django or Twisted? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13839] -m pstats should combine all the profiles given as arguments
New submission from Matt Joiner anacro...@gmail.com: Frequently when profiling multiple threads, I need to combine several dump stat files. Currently -m pstats reads the profiling data at only the first path given. It should merge all the profiling data from all the paths given. $ python3.3 -m pstats prof/5506-7f00f* Minimalist patch attached. -- components: Library (Lib) files: m-pstats-merge-profiles.patch keywords: patch messages: 151795 nosy: anacrolix priority: normal severity: normal status: open title: -m pstats should combine all the profiles given as arguments 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/file24294/m-pstats-merge-profiles.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12684] profile does not dump stats on exception like cProfile does
Changes by Matt Joiner anacro...@gmail.com: -- resolution: works for me - status: languishing - open versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment: On Sat, 2012-01-21 at 23:47 +, Alex Gaynor wrote: Alex Gaynor alex.gay...@gmail.com added the comment: On Sat, Jan 21, 2012 at 5:42 PM, Gregory P. Smith rep...@bugs.python.orgwrote: Gregory P. Smith g...@krypto.org added the comment: On Sat, Jan 21, 2012 at 2:45 PM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: You said above that it should be hardcoded; if so, how can it be changed at run-time from an environment variable? Or am I misunderstanding. You're right, I used the wrong word. I meant it should be a constant independently of the dict size. But, indeed, not hard-coded in the source. BTW, presumably if we do it, we should do it for sets as well? Yeah, and use the same env var / sys function. Despite the DICT in the title? OK. Well, dict is the most likely target for these attacks. While true I wouldn't make that claim as there will be applications using a set in a vulnerable manner. I'd prefer to see any such environment variable name used to configure this behavior not mention DICT or SET but just say HASHTABLE. That is a much better bikeshed color. ;) I'm still in the hash seed randomization camp but I'm finding it interesting all of the creative ways others are trying to solve this problem in a way that could be enabled by default in stable versions regardless. :) -gps -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ I'm a little slow, so bear with me, but David, does this counting scheme in any way address the issue of: I'm able to put N pieces of data into the database on successive requests, but then *rendering* that data puts it in a dictionary, which renders that page unviewable by anyone. It doesn't address this issue - though if the page is taking many hours to render, is that in practice less unviewable that everyone getting an immediate exception with (perhaps) a useful error message? Unfortunately, given the current scale factor, my patch may make it worse: in my tests, this approach rejected malicious data much more quickly than the old collision-counting one, which I thought was a good thing - but then I realized that this means that an attacker adopting the strategy you describe would have to do less work to trigger the exception than to trigger the slowdown. So I'm not convinced my approach flies, and I'm leaning towards working on the hash randomization patch rather than pursuing this. I need sleep though, so I'm not sure the above is coherent Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein jon.brandv...@gmail.com added the comment: Some more information: When I write to a new file created by open(), all versions flush correctly. However, if I reassign sys.stdout to that file, Python 3.x does not (again, under Windows). I wonder what it is that causes these other files to flush. (Note: I am testing by calling time.sleep() and inspecting the output file during and after the pause.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment: I arbitrarily started with 50, and then decided a power of two would be quicker when multiplying. There wasn't any rigorous analysis behind the choice of factor. Though, as noted in msg151796, I've gone off this idea, since I think the protection creates additional avenues of attack. I think getting some kind of hash randomization patch into the hands of users ASAP is the way forward here (even if disabled by default). If we're going to support shipping backported versions of the hash randomization patch with the randomization disabled, did we decide on a way of enabling it? If not, then I propose that those who want to ship with it disabled by default standardize on (say): PYTHONHASHRANDOMIZATION as an environment variable: if set to nonzero, it enables hash randomization (reading the random seed as per the 3.3. patch, and respecting the PYTHONHASHSEED variable if that's also set). If set to zero or not present, hash randomization is disabled. Does that sound sane? (we can't use PYTHONHASHSEED for this, since if a number is given, that means use this number, right?) FWIW, I favor hash randomization in 2.* for PyStringObject, PyUnicodeObject, PyBufferObject, and the 3 datetime classes in Modules/_datetimemodule.c (see the implementation of generic_hash in that file), but to not do it for the numeric types. Sorry; I only tried it on the python test suite (and on a set of reproducers for the DoS that I've written for RH's in-house test suite). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein jon.brandv...@gmail.com added the comment: It turns out the file output was flushing due to garbage collection. When I created and held a global reference to it, it ceased to flush. Clearly, reassigning sys.stdout also held a reference to it. So it wasn't any kind of special sys.stdout-specific logic. I tried using os.fsync to determine whether data was being saved in an OS-level buffer. But since the OS may be free to ignore fsync, it's kind of worthless for this purpose. I also found that under Python 2.x, even a low-level exit like os._exit or multiprocessing.win32.ExitProcess, called from within a user-level function in the child, caused flushing. My best guess is that 1. Python 2.x is not buffering data at the Python level. I can't see how it could be and still flush it out when calling _exit(). 2. Python 3.x is buffering at the Python level, and the Python File object needs to be destroyed or explicitly flushed before the hard low-level exit() in forking.py. The solutions I can think of for Python 3.x are: 1. Replace exit = win32.ExitProcess with exit = sys.exit. All outstanding file objects will be destroyed and flushed naturally as the interpreter is torn down. 2. Add an explicit stdout/stderr flush where appropriate in forking.py and process.py, to ensure tracebacks get written and to match the unix behavior. Leave it to the user to worry about flushing their own streams. 3. Continue to use win32.ExitProcess, but add some kind of mechanism for walking through all existing Python File objects and flushing/destroying them. This was a fleeting thought; it really amounts to reimplementing the behavior of destructing the Python interpreter. I'd really like to hear if there are good reasons for why (1) isn't how it's done currently. I'd also like to hear an explanation of Python 2.x's buffering. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
New submission from Vincent Pelletier plr.vinc...@gmail.com:
ctypes.create_string_buffer documentation[1] says init_or_size parameter should
accept a string. As of 3.2, it raises:
import ctypes
ctypes.create_string_buffer('foo')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.2/ctypes/__init__.py, line 59, in create_string_buffer
buf.value = init
TypeError: str/bytes expected instead of str instance
It works fine as of 2.7 (and very probably any 2.x up to ctypes introduction):
import ctypes
ctypes.create_string_buffer('foo')
ctypes.c_char_Array_4 object at 0x7fbdcb8b95f0
[1] http://docs.python.org/py3k/library/ctypes.html#ctypes.create_string_buffer
Regards,
Vincent Pelletier
--
components: ctypes
messages: 151800
nosy: vpelletier
priority: normal
severity: normal
status: open
title: create_string_buffer rejects str init_or_size parameter
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13840
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
Georg Brandl ge...@python.org added the comment: It should only take bytes; str is Unicode in 3.x. So the docs and the error message are wrong, the behavior is correct. Reclassifying as a docs issue. -- assignee: - docs@python components: +Documentation -ctypes nosy: +docs@python, georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
