Changes by Oren Milman :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/issue27111>
___
___
Python-bugs-list mailing list
Unsub
Changes by Oren Milman :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/issue27441>
___
___
Python-bugs-list mailing list
Unsub
Oren Milman added the comment:
Thanks for the review, Mark :)
--
___
Python tracker
<https://bugs.python.org/issue27214>
___
___
Python-bugs-list mailin
Oren Milman added the comment:
ImpImporter was first added in changeset 37808
(https://hg.python.org/cpython/rev/ccc0b5412799) and updated a day later in
changeset 37821 (https://hg.python.org/cpython/rev/3135648026c4).
Both of these commits were introduced to support PEP 302.
Since then
Oren Milman added the comment:
I would be happy to write a patch for this issue, if you don't mind.
Terry, as you were the one to commit the patch for #21559, I guess you are OK
with keeping the OverflowError.
Also, I agree that the error message for '_testcapi.getargs_b(-1)' (a
Oren Milman added the comment:
That's awesome! Thanks :)
--
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Python-bugs-list mailing list
Oren Milman added the comment:
Note that http://bugs.python.org/issue26896 is now closed (the patches proposed
in it (with some minor changes) were committed).
--
nosy: +Oren Milman
___
Python tracker
<http://bugs.python.org/issue20
Oren Milman added the comment:
I am sorry, but I can't see why micro-benchmarking is needed here, as my
patches only remove code that does nothing, while they don't add any new code.
The assembly the compiler generates (on my PC) for 'Py_SIZE(v) = negative ?
-ndigits
Changes by Oren Milman :
Added file: http://bugs.python.org/file43662/patchedCPythonTestOutput_ver2.txt
___
Python tracker
<http://bugs.python.org/issue27441>
___
___
Changes by Oren Milman :
--
keywords: +patch
Added file: http://bugs.python.org/file43608/issue27441_ver1.diff
___
Python tracker
<http://bugs.python.org/issue27
Changes by Oren Milman :
Added file: http://bugs.python.org/file43609/patchedCPythonTestOutput_ver1.txt
___
Python tracker
<http://bugs.python.org/issue27441>
___
___
New submission from Oren Milman:
current state
In six different functions, the following happens:
1. Function x calls _PyLong_New, with var y as the size argument.
* Among others, _PyLong_New sets the ob_size of the new int to y (the
size argument it
Oren Milman added the comment:
Also, Brett was the one who added the three terms to the glossary in
https://hg.python.org/cpython/rev/ea5767ebd903, and a clarification of 'finder'
in https://hg.python.org/cpython/rev/88cee7d16ccb, so I guess his input in this
matter also would
Oren Milman added the comment:
Except for some trailing spaces I have just found in my original proposed
patches, I don't have any extra changes to add. So as soon as Brett answers
about those two assignments, I would update and upload the patches diff file.
With regard to terminolo
Changes by Oren Milman :
Added file: http://bugs.python.org/file43435/proposedPatches.diff
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file43434/badMicroBenchProposedPatches.diff
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Oren Milman added the comment:
I did some micro-benchmarking, and it looks like bad news for my patch.
I wrote a simple C extension in order to call PyLong_AsUnsignedLongMask and
PyLong_AsUnsignedLongLongMask from Python code (attached).
Then I ran the following micro-benchmarks using both the
Oren Milman added the comment:
Ah, that's a cool alternative to divide and ceil. I would change my patch
accordingly.
And would write the patch also for _PyLong_AsUnsignedLongLongMask, and work on
some micro-benchmarking for it and _PyLong_AsUnsignedLongMask.
Indeed _testcapimodule.c i
Changes by Oren Milman :
Added file: http://bugs.python.org/file43347/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Pytho
New submission from Oren Milman:
current state
1. In Objects/longobject.c in _PyLong_AsUnsignedLongMask, in case v is a
multiple-digit int, _PyLong_AsUnsignedLongMask iterates over all of its digits
(going from the most to the least significant digit) and does (for
Changes by Oren Milman :
Added file: http://bugs.python.org/file43348/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27298>
___
___
Python-bug
Oren Milman added the comment:
done.
By the way, I am logging in to bugs.python.org through accounts.google.com, but
I couldn't see any way to do the same in www.python.org, so I have a native
account there (with the same email address). I hope that won't b
Changes by Oren Milman :
Added file: http://bugs.python.org/file43208/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27222>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file43209/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27222>
___
___
Pytho
New submission from Oren Milman:
current state
1. long_rshift first checks whether a is a negative int. If it is, it does
(edited for brevity) 'z = long_invert(long_rshift(long_invert(a), b));'.
Otherwise, it calculates the result of the shift and stores i
Changes by Oren Milman :
Added file: http://bugs.python.org/file43187/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27214>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file43188/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27214>
___
___
Pytho
New submission from Oren Milman:
the current state
long_invert first checks whether v is a single-digit int. If it is, it simply
does 'return PyLong_FromLong(-(MEDIUM_VALUE(v) + 1));'.
Otherwise, long_invert does (edited for brevity) 'x = long_add(v,
Py
Changes by Oren Milman :
Added file: http://bugs.python.org/file43164/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Pytho
Oren Milman added the comment:
I considered doing that, but I had already opened another issue
(http://bugs.python.org/issue27145) in which I had proposed to replace that
in-place negate in long_sub with a call to _PyLong_Negate.
But I guess I shouldn't worry about my patches coll
Oren Milman added the comment:
After giving it some more thought, I feel somewhat uncertain about that check
for a failure after using _PyLong_Negate.
At first I noticed that after every call to _PyLong_Negate there is such a
check. But then I realized that in my patch, and also in long_mul
Oren Milman added the comment:
I just realized I had forgotten to check for a failure after using
_PyLong_Negate. The updated diff file is attached.
--
Added file: http://bugs.python.org/file43148/proposedPatches.diff
___
Python tracker
<h
Oren Milman added the comment:
All right. The updated diff file is attached.
I compiled and ran the tests again. They are quite the same. The test output is
attached.
--
Added file: http://bugs.python.org/file43144/issue27073.diff
___
Python
Changes by Oren Milman :
Added file: http://bugs.python.org/file43145/patchedCPythonTestOutput2.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Pytho
Oren Milman added the comment:
I agree. This assert only indirectly verifies that something bad doesn't
happen.
The bad thing that might happen is an in-place negating of an element of
small_ints, so the most direct assert should be 'assert(Py_REFCNT(z) == 1);'.
This is exac
Oren Milman added the comment:
And after quadruple checking myself, I found a foolish mistake - in that flow,
x_add received at least one multiple-digit int (not necessarily two :().
I fixed that mistake in the comment. The updated diff file is attached.
--
Added file: http
Oren Milman added the comment:
After giving it some more thought (while working on another, somewhat related
issue - http://bugs.python.org/issue27145), I realized that that assert in
long_add could further verify that the int x_add returned is a multiple-digit
int (as x_add had received two
Changes by Oren Milman :
Added file: http://bugs.python.org/file43043/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27145>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file43042/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27145>
___
___
Python-bug
New submission from Oren Milman:
the current state
>>> if is32BitCPython:
... PyLong_SHIFT = 15
... elif is64BitCPython:
... PyLong_SHIFT = 30
...
>>> # case A #
>>> a = 2 ** PyLong_SHIFT - 1
>>> b = 2 ** PyLong_SHIFT
Changes by Oren Milman :
Added file: http://bugs.python.org/file42975/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27111>
___
___
Python-bug
Changes by Oren Milman :
Added file: http://bugs.python.org/file42974/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27111>
___
___
Pytho
New submission from Oren Milman:
the proposed changes
In Objects/longobject.c in long_add and long_sub, the variables 'result' and
'r' (respectively), are used only once, and don't seem to make the code any
clearer.
It seems the 'result
Oren Milman added the comment:
Thanks for the reviews!
I added an assert in long_add (in long_sub it might be that the result is 0).
The updated diff file is attached.
--
Added file: http://bugs.python.org/file42926/issue27073.diff
___
Python
Changes by Oren Milman :
Added file: http://bugs.python.org/file42922/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file42921/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue27073>
___
___
Python-bug
New submission from Oren Milman:
the proposed changes
I believe the following checks are redundant:
1. in Objects/longobject.c in long_add:
In case both a and b are negative, their absolute values are added
using x_add, with the result stored in z
Changes by Oren Milman :
Added file: http://bugs.python.org/file42772/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26972>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file42771/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26972>
___
___
Python-bug
New submission from Oren Milman:
the proposed changes:
I believe there are some mistakes in the following docstrings:
1. in Lib/importlib/_bootstrap.py:
- _module_repr - a typo
- _exec - I believe 'Execute the module specified by the spec' is more
accurate than &#
Oren Milman added the comment:
thanks for the review!
I replied to both of your comments, though I am not sure what is expected of me
in the rest of the process.
Whatever it is, I would be happy to help as much as I can.
--
___
Python tracker
Changes by Oren Milman :
Added file: http://bugs.python.org/file42668/patchedCPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Pytho
Changes by Oren Milman :
Added file: http://bugs.python.org/file42667/CPythonTestOutput.txt
___
Python tracker
<http://bugs.python.org/issue26896>
___
___
Python-bug
New submission from Oren Milman:
the proposed changes:
1. it seems there is some mix-up with the terms 'importer' and 'finder' (and
rarely also 'loader') in the import system and in related code (I guess most of
it is just relics from the time before PEP 302)
New submission from Oren Milman:
In Parser\parser.c in classify, the 'str' parameter is assigned into the local
variable 's'. However, 'str' is not used anywhere else in the function, which
makes 's' redundant.
My proposal is to simply remove '
Oren Milman added the comment:
Sorry for being so clueless.
The diff is attached.
I manually did some checks to verify that relevant stuff work correctly (the
imaginary number 0j, and fractions starting with '0.').
I run 'python -m test', and got the following output:
New submission from Oren Milman:
In Parser\tokenizer.c, in tok_get, in the identification of a potential NUMBER
token, in case the token starts with a '0', the next char of the token is
retrieved, followed by two redundant checks:
if (c == '.')
goto fraction;
if
301 - 357 of 357 matches
Mail list logo
