Dave Malcolm added the comment:
I think when I wrote this I was over-optimistically thinking that we could just
add more patterns, but if it's becoming a pain, then your approach looks good
to me.
--
nosy: +dmalcolm
___
Python tracker
<ht
Dave Malcolm added the comment:
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue9263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm <dmalc...@redhat.com> added the comment:
On Fri, 2018-02-23 at 00:16 +, Cheryl Sabella wrote:
> Cheryl Sabella <chek...@gmail.com> added the comment:
>
> Did PEP553 make this issue obsolete?
I *think* they have slightly different scope: if I'm reading it r
Dave Malcolm added the comment:
The problem is that there are so many variables:
* which version of which compiler
* optimization flags
* which version of gdb
* which CPU architecture
etc (and the compiler and/or gdb could be carrying patches from downstream
distributors...)
All of these can
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21590
___
___
Python-bugs-list
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 11:10 +, Bohuslav Slavek Kabrda wrote:
Bohuslav Slavek Kabrda added the comment:
Hi,
I'd like to take this over after Dave Malcolm. I don't see any issues that
haven't been resolved, so my question is: What else can I do to make
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 14:15 +, Dave Malcolm wrote:
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 11:10 +, Bohuslav Slavek Kabrda wrote:
Bohuslav Slavek Kabrda added the comment:
Hi,
I'd like to take this over after Dave Malcolm. I
Dave Malcolm added the comment:
On Tue, 2014-01-07 at 16:30 +, Yury V. Zaytsev wrote:
Yury V. Zaytsev added the comment:
After lots of fiddling, I can tell you what's wrong with the macro:
apparently it's a compiler bug, visible at -O2 and disappearing at -O1.
Can you reduce
Dave Malcolm added the comment:
[FWIW, this looks similar to an issue I ran into on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=913732
which was due to a mismatch between the kernel headers on the system vs the
actually running kernel. I patched around it there with a downstream-only
Dave Malcolm added the comment:
FWIW, I feel that it's worth just expecting failures with an *optimized* build:
with an optimizing compiler, there's likely to always be some program counter
location where the debugger is going to get confused for some variables. Given
umpteen different
Dave Malcolm added the comment:
Antoine's patch looks reasonable to me, FWIW.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18772
Dave Malcolm added the comment:
On Mon, 2013-07-29 at 14:01 +, Ronald Oussoren wrote:
Ronald Oussoren added the comment:
The attached patch for the benchmark README.txt should document the status
quo.
--
Added file: http://bugs.python.org/file31073/issue-18181-full-v3.txt
Dave Malcolm added the comment:
pmuldoon: did you truncate the output of bt? (or did the superior gdb you're
using do this behind the scenes? I know you hack on gdb itself, and this looks
a superior gdb debugging an inferior gdb).
The reason for this error:
Python Exception type
Changes by Dave Malcolm dmalc...@redhat.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17833
Dave Malcolm added the comment:
On Wed, 2013-04-24 at 10:48 +, Alex Leach wrote:
Alex Leach added the comment:
I don't think I can tell you anything you don't know already, but ...
On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm rep...@bugs.python.org
wrote:
BTW, is that GCC
Dave Malcolm added the comment:
Is this an optimized or a debug build? (aka --with-pydebug)
What are the optimization flags passed to the C compiler?
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17833
Dave Malcolm added the comment:
Thanks. I can't see from that output what's going wrong.
Can you apply the following patch, which (I hope) will print more detailed info
where the failure happens.
--
keywords: +patch
Added file: http://bugs.python.org/file30005/find-more
Dave Malcolm added the comment:
Looking at test_gdb.out, the issue is that the threads waiting for the GIL have
e.g. this at the top of their backtrace:
Thread 2 (Thread 0x3fffb14af200 (LWP 37119)):
#0 0x008075181ea8 in __pthread_cond_timedwait (cond=0x103ea140 gil_cond,
mutex=0x103ea170
Dave Malcolm added the comment:
Can you try this candidate fix?
--
Added file: http://bugs.python.org/file30007/possible-fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17833
Dave Malcolm added the comment:
On Sat, 2013-04-20 at 21:25 +, Ned Deily wrote:
Ned Deily added the comment:
Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?
I was trying to think of one; the only reason I can think of is if there
are any compilers out
Dave Malcolm added the comment:
BTW, is that GCC format checking code available anywhere?
Am I right in thinking that it was an out-of-tree patch to GCC, from the
pre-plugin days?
[My cpychecker code adds some similar checking, but it doesn't use this
attribute
Dave Malcolm added the comment:
I didn't know that gdb supported embedding Python 3. Is this a set of patches
you're applying downstream, or an official gdb feature?
If so, it means everyone coding to the gdb API needs to somehow make their
FOO-gdb.py files be Python 3-compatible
Dave Malcolm added the comment:
Thanks. Does upstream gdb have a plan dcoumented somewhere for how to deal
with all of the FOO-gdb.py files. Are they expected to be coded to the common
Python 2/3 subset?
--
___
Python tracker rep
New submission from Dave Malcolm:
It appears that gcc's -Wformat warning changed from being on by default in gcc
4.7 and earlier to being off by default in gcc 4.8, needing to be enabled with
-Wformat (or -Wall), if I'm reading:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=193304
New submission from Dave Malcolm:
Does the devguide document the benchmarking suite anywhere? I can't see it
anywhere in the index on http://docs.python.org/devguide/ and google doesn't
seem to show anything.
suggested content:
* how to run the benchmarks for a Python 2 implementation
Dave Malcolm added the comment:
For reference, quoting PEP 3149:
sysconfig.get_config_var('SO')
'.cpython-32mu.so'
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16754
New submission from Dave Malcolm:
Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.
hmac implicitly defaults to using MD5.
MD5 should no longer be used for security purposes. See e.g.
http://www.kb.cert.org/vuls/id/836068
New submission from Dave Malcolm:
When running my refcount static analyzer [1] on a large corpus of real-world C
extension code for Python, I ran into the following construct in various places:
Py_XDECREF(PyObject_CallObject(callable, args));
This is bogus code: Py_XDECREF expands its
Dave Malcolm added the comment:
Minor bikeshedding/spelling nit: should
_Py_AllocedBlocks
be changed to
_Py_AllocatedBlocks
(and s/_Py_GetAllocedBlocks/_Py_GetAllocatedBlocks/)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15516
___
___
Python-bugs
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16612
___
___
Python-bugs-list
Dave Malcolm added the comment:
In my Fedora Python packages I've been applying this patch:
http://pkgs.fedoraproject.org/cgit/python.git/plain/00156-gdb-autoload-safepath.patch
which uses this code fragment to detect if gdb has the autoload safe path code,
rather than trying to guess it from
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16191
___
___
Python-bugs-list
New submission from Dave Malcolm:
In Python 3.2 and earlier:
str(ImportError(b'foo'))
b'foo'
In Python 3.3:
str(ImportError(b'foo'))
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __str__ returned non-string (type bytes)
This appears to be due to commit 76272
Dave Malcolm added the comment:
Sorry, it's 6825fd9b00ed
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15778
___
___
Python-bugs-list mailing
Changes by Dave Malcolm dmalc...@redhat.com:
--
keywords: +patch
Added file: http://bugs.python.org/file26988/fix-str-of-bogus-ImportError.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15778
Dave Malcolm added the comment:
(patch added)
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15778
___
___
Python-bugs
New submission from Dave Malcolm:
I've been testing various 3rd-party python code against 3.3b1, and see
ValueError: level must be = 0
exceptions where C code is using PyImport_ImportModuleEx.
PyImport_ImportModuleEx reads as
63 #define PyImport_ImportModuleEx(n, g, l, f) \
64
Dave Malcolm added the comment:
(FWIW, this was observed when compiling pygobject-3.3.4 against Python-3.3.0b1)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15610
Dave Malcolm added the comment:
On Thu, 2012-08-09 at 21:04 +, STINNER Victor wrote:
STINNER Victor added the comment:
Oh, I didn't realize that the documentation says that the default value is -1.
http://docs.python.org/library/functions.html#__import__
level specifies whether
Dave Malcolm added the comment:
On Tue, 2010-11-02 at 17:25 +, Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to
support this. Also, why do you allow any arguments to sys._breakpoint
New submission from Dave Malcolm:
I've been trying to get numpy working with Python 3.3, and to so I had to make
some changes to CPython - hence I'm posting this to the Python bug tracker.
numpy pokes at the insides of PyUnicodeObject in a few places and is thus
affected by the PEP 393
Changes by Dave Malcolm dmalc...@redhat.com:
Added file:
http://bugs.python.org/file26669/hack-out-test-against-MAX_UNICODE-from-cpython-3.3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15540
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +haypo, loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15540
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15540
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +teoliphant
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15540
___
___
Python-bugs-list
Dave Malcolm added the comment:
Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint
directly from Python is:
os.kill(os.getpid(), signal.SIGTRAP)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15516
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
I believe this was due to this line:
return self._gdbframe.name().startswith('pthread_cond_timedwait')
within is_waiting_for_gil(), and your gdb returned None for
self._gdbframe.name() for your build.
I've changed it to:
name = self
Dave Malcolm dmalc...@redhat.com added the comment:
Fixes committed to 3.2 and default: RHEL 6.3 is now green for both branches.
Closing this bug out.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python
Dave Malcolm dmalc...@redhat.com added the comment:
The approach Nick suggests seems reasonable, but rpm.expandMacro isn't usable:
there's no guarantee that the machine has Python bindings for rpm installed
(especially not for the version of Python that we've just built).
However, we can get
Dave Malcolm dmalc...@redhat.com added the comment:
(with the patch, it also continues to work on a test Fedora 15 box)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14443
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15110
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
keywords: -needs review
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14785
Dave Malcolm dmalc...@redhat.com added the comment:
I'm attaching an updated version of the patch; I hope there's still time before
Saturday to get it into 3.3
I found a bug in the configure script in the old patch: /usr/bin/dtrace was
required, even without requesting systemtap. I've fixed
Dave Malcolm dmalc...@redhat.com added the comment:
I'm able to reproduce this on a RHEL 6 box, and I did some investigating. The
stray .pyc files are indeed reported by file as python 2.6 byte-compiled so
yes, it's using /usr/bin/python to byte-compile them
On RHEL 6, with redhat-rpm-config
Dave Malcolm dmalc...@redhat.com added the comment:
Thanks. I too am wondering where the documentation should go. We currently
have several locations for documentation:
(1) the man page
(2) the Doc subdirectory aka docs.python.org
(3) various text files in the source tree, such as Misc
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +fche, scox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14776
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
Oops; closing. Thanks.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8330
Dave Malcolm dmalc...@redhat.com added the comment:
I tried the patch under Mageia 1 and got the following failure:
Thanks. I'm attaching an updated patch which reworks test_systemtap so that
(a) it turns up the verbosity of stap invocations from -v to -vv
(b) it tests the hello world stap
Dave Malcolm dmalc...@redhat.com added the comment:
On Wed, 2012-05-16 at 16:41 +, Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
I tried the patch under Mageia 1 and got the following failure:
test_systemtap skipped -- Test systemtap script did not run; stderr
Dave Malcolm dmalc...@redhat.com added the comment:
(Sorry about msg160913; looks like my initial email response took about an hour
to get through, and I'd subsequently commented using the webui form)
--
___
Python tracker rep...@bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
--
Removed message: http://bugs.python.org/msg160913
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14776
Changes by Dave Malcolm dmalc...@redhat.com:
--
Removed message: http://bugs.python.org/msg160914
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14776
Changes by Dave Malcolm dmalc...@redhat.com:
Removed file:
http://bugs.python.org/file25615/cpython-systemtap-2012-05-16-001.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14776
Dave Malcolm dmalc...@redhat.com added the comment:
Updated version of the patch, using test.script_helper.assert_python_ok() and
adding a NEWS entry
--
Added file: http://bugs.python.org/file25579/add-debug-malloc-stats-v2.patch
___
Python tracker
Dave Malcolm dmalc...@redhat.com added the comment:
Thanks. I'm attaching an updated version of the patch, wrapping all new C
entrypoints within a #ifndef Py_LIMITED_API
I also moved the existing _PyObject_DebugMallocStats() entrypoint to within a
#ifndef Py_LIMITED_API. As noted above
Dave Malcolm dmalc...@redhat.com added the comment:
Thanks Eric, Antoine and Mark.
I'm attaching two new patches: a replacement patch for cpython, and a new patch
for the devguide
I've moved the docs to the dev guide, starting a new Debugging and
Instrumentation section there.
Changes
Changes by Dave Malcolm dmalc...@redhat.com:
Added file:
http://bugs.python.org/file25540/devguide-systemtap-2012-05-11-001.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14776
Dave Malcolm dmalc...@redhat.com added the comment:
Issue #13405 covers DTrace; I've taken the liberty of also opening issue #14776
to cover SystemTap. I hope that once one of these is in the tree it will be
easier to get the other one
New submission from Dave Malcolm dmalc...@redhat.com:
I'm attaching a patch which generalizes the at-exit PYTHONMALLOCSTATS memory
usage report, so that it's available in a regular build and can be triggered
from Python, by calling:
sys._debugmallocstats()
This can be useful when debugging
New submission from Dave Malcolm dmalc...@redhat.com:
When building from source, if I create multiple configuration directories and
build from there e.g.:
mkdir configs
cd configs
mkdir config-A
cd config-A
../../configure
make
cd ..
mkdir config-B
cd config-B
../../configure --enable-shared
Dave Malcolm dmalc...@redhat.com added the comment:
Note to self: workaround is to
rm ../../Lib/_sysconfigdata.py || make ../../Lib/_sysconfigdata.py
before running my tests in either configuration, to force the file to be
regenerated using what make thinks the settings
New submission from Dave Malcolm dmalc...@redhat.com:
I'm attaching a patch which adds static markers for SystemTap for two probeable
events within CPython's bytecode interpreter, along with test cases and
documentation.
I'm hoping to get this merged for 3.3; is this PEP-worthy, or can
Dave Malcolm dmalc...@redhat.com added the comment:
I've refreshed my SystemTap patch, and opened a new issue, issue #14776 to
cover SystemTap.
Issue #4111 was originally opened on 2008-10-12 as Add DTrace probes, and was
generalized on 2009-12-08 to Add Systemtap/DTrace probes. That issue
Dave Malcolm dmalc...@redhat.com added the comment:
Like passwd and group information, the shadow password entries are pulled
through libc's Name Service Switch and modules for it, depending on
configuration.
See man nsswitch.conf.
Hence this is likely to be a configuration difference
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14757
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
As a post-processing step, rpmbuild will attempt to byte-compile any .py files
it encounters, and the results must be listed in the %files manifest. [1]
This is done by the script brp-python-bytecompile, which uses the compileall
module
Dave Malcolm dmalc...@redhat.com added the comment:
__os_install_post is defined within /usr/lib/rpm/redhat/macros and contains
this fragment:
/usr/lib/rpm/brp-python-bytecompile %{__python}
%{?_python_bytecompile_errors_terminate_build} \
Hence it will use %{__python} as the default when
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14621
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
Thanks for filing this bug report.
I'm not seeing the equal hashes you describe.
I'm using this recipe to hardcode a specific prefix and print the hashes using
it:
$ gdb --eval-command=break _PyRandom_Init --eval-command=run
--eval-command
Dave Malcolm dmalc...@redhat.com added the comment:
$ gdb --eval-command=break _PyRandom_Init --eval-command=run
--eval-command=print _Py_HashSecret --eval-command=set
_Py_HashSecret.prefix=0xcdcdcd00 --eval-command=print _Py_HashSecret
--eval-command=continue -eval-command=continue --args
Dave Malcolm dmalc...@redhat.com added the comment:
The originally attached patch is no good for the the 2.* branch, as it appears
that _testcapimodule.c will not become ssize_t safe in Python 2.*; see e.g.:
http://hg.python.org/cpython/rev/3ecddf168f1f
Am attaching a revised patch that I'm
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
Some notes from discussion with MvL at PyCon sprint:
The ideal is that:
- for any patch attached to an issue: the patch is uploaded to a Rietveld
instance colocated in the same db as Roundup (bugs.python.org)
- if it works, than
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13963
___
___
Python-bugs-list mailing
Dave Malcolm dmalc...@redhat.com added the comment:
It would appear that having:
[diff]
git = on
in ~/.hgrc breaks the rietveld integration, since hg diff then emits a diff
that doesn't identify the hg revision number, and hence the importer can't
determine the baseline
New submission from Dave Malcolm dmalc...@redhat.com:
Expat 2.1.0 Beta was recently announced:
http://mail.libexpat.org/pipermail/expat-discuss/2012-March/002768.html
which contains (among other things) a fix for a hash-collision
denial-of-service attack (CVE-2012-0876)
I'm attaching a patch
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14234
___
___
Python-bugs-list mailing
Changes by Dave Malcolm dmalc...@redhat.com:
--
components: +Library (Lib)
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14103
New submission from Dave Malcolm dmalc...@redhat.com:
$ mkdir some_directory_ending_with_a.py
$ python -c import imputil;
imputil.imp.find_module('some_directory_ending_with_a')
*** glibc detected *** python: double free or corruption (!prev):
0x01589bf0 ***
Aborted
What's happening
Dave Malcolm dmalc...@redhat.com added the comment:
Duplicate of issue 7732
--
resolution: - duplicate
status: open - closed
superseder: - imp.find_module crashes Python if there exists a directory
named __init__.py
___
Python tracker rep
Dave Malcolm dmalc...@redhat.com added the comment:
jcea: BTW, will you be at PyCon US this year? if so, can we sprint on getting
the DTrace and SystemTap hooks into CPython in some form acceptable to the rest
of the CPython maintainers
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14001
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
I'm not quite sure how that would interact with the -R command-line
option for enabling randomization.
The changes to the docs in the latest patch clarifies the meaning of
what I've implemented (I hope).
My view is that we should simply
Dave Malcolm dmalc...@redhat.com added the comment:
On Mon, 2012-02-06 at 23:00 +, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Alex Gaynor wrote:
There's no need to cover any container types, because if their constituent
types are securely hashable
New submission from Dave Malcolm dmalc...@redhat.com:
I've been waiting for patch review of my work on
http://bugs.python.org/issue13703 only to discover that people *have* been
reviewing it.
It turns out that next to some of the patches in the issue tracker there's a
review link, which
Dave Malcolm dmalc...@redhat.com added the comment:
On Mon, 2012-02-06 at 10:20 +, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
In a security fix release, we
Dave Malcolm dmalc...@redhat.com added the comment:
Can't randomization just be applied to integers as well?
It could, but see http://bugs.python.org/issue13703#msg151847
Would my patches be more or less likely to get reviewed with vs without
an extension of randomization to integers
Dave Malcolm dmalc...@redhat.com added the comment:
It's useful for the selftests, so I've kept PYTHONHASHSEED. However,
I've removed it from the man page; the only other place it's mentioned
(in Doc/using/cmdline.rst) I now explicitly say that it exists just to
serve the interpreter's own
1 - 100 of 412 matches
Mail list logo
