Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17176/bltinmodule4.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17175/bltinmodule4.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Alexander Belopolsky added the comment:
Attached patch, issue1533.diff, simplifies reference acrobatics at the expense
of extra local variables. For the first time the first compilation did not
have reference counting errors!
--
Added file: http://bugs.python.org/file17189/issue1533
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file9543/bltinmodule.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17176/bltinmodule4.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17171/bltinmodule3.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Sun, May 2, 2010 at 4:37 AM, Mark Dickinson wrote:
..
> - Please could you also add a test for small arguments for each test
> class?
Working on it ...
--
___
Python tracker
<http://bugs.p
Alexander Belopolsky added the comment:
> - Please could you also add a test for small arguments for each test
> class?
Done.
--
Added file: http://bugs.python.org/file17190/issue1533.diff
___
Python tracker
<http://bugs.python.org/
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17189/issue1533.diff
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bug
Changes by Alexander Belopolsky :
--
keywords: +26backport
___
Python tracker
<http://bugs.python.org/issue3720>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
assignee: -> ronaldoussoren
components: +Macintosh
___
Python tracker
<http://bugs.python.org/issue6763>
___
___
Python-
Changes by Alexander Belopolsky :
--
keywords: +needs review
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue
Changes by Alexander Belopolsky :
--
keywords: +needs review
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue4806>
___
___
Python-
Alexander Belopolsky added the comment:
On May 4, 2010, at 7:27 AM, Mark Dickinson
wrote:
>
> Mark Dickinson added the comment:
>
> Thanks for the fixes. The latest patch looks good to me.
>
> Alexander, is it okay for me to commit this?
>
Sure. Why do you have to
Alexander Belopolsky added the comment:
I see. Let me take a look.
BTW, I tried to use tabs for indentation in the patch, but emacs was
not always happy about it. Is there some c-mode setting that I don't
know about that would take care of that?
On May 4, 2010, at 8:34 AM, Mark Dick
Alexander Belopolsky added the comment:
On Tue, May 4, 2010 at 8:34 AM, Mark Dickinson wrote:
..
> I took the liberty of messing with your patch slightly; I didn't want
> to ask you to make further changes since the patch was fine, and my
> messing was mostly just to satisfy my
Changes by Alexander Belopolsky :
--
assignee: belopolsky -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list mai
Alexander Belopolsky added the comment:
On Tue, May 4, 2010 at 12:32 PM, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Applied to trunk in r80758.
>
> Do people want this to go into 2.6 as well?
Also, should additional unit tests forward ported to 3.x? I
Alexander Belopolsky added the comment:
I am attaching a py3k patch that adds new tests. Since there are no end user
visible changes, I don't believe a Misc/NEWS entry is needed. A commit message
may read:
Issue #1533: Tests only. Added tests for consistency in range function arg
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5727>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
The latest patch, os-getgroups-v2.patch, seems to have the same bug as I
reported in msg99926:
"""
The crash that I see is apparently due to underallocated memory:
alt_grouplist = PyMem_Malloc(n);
should be
alt_grouplist = PyMem_Ma
Alexander Belopolsky added the comment:
Ronald> How did you detect that the modern getgroups implementation
Ronald> doesn't query the kernel? That would be very odd.
I have just found the source code for getgroups:
http://www.opensource.apple.com/source/Libc/Libc-594.1.4/sys/getgro
Alexander Belopolsky added the comment:
Ronald,
Did you forget to attach your patch? I don't see v3.
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
Why do you expect dict_values to support set operations? Dict values unlike
keys are not sets, they are more like lists. Set operations of dict_values are
not supported in 3.x either.
--
nosy: +belopolsky -Alexander.Belopolsky
Alexander Belopolsky added the comment:
> Alexander, do you want to tackle the 2.6 backport?
I've never done a maintenance branch backport, but here is my attempt:
1. Checkout release26-maint
2. Apply 80757:80758 diff, fix rejected NEWS patch
3. Ignore 80838:80839 diff - small fl
Changes by Alexander Belopolsky :
--
keywords: +26backport
versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
> the requirements are different for 2.6: floats should give a
> DeprecationWarning rather than a TypeError.
I thought about it, but the comment in test_builtin.py,
# Reject floats when it would require PyLongs to rep
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17231/issue1533-release26-maint.diff
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
Similar logic can be written simpler as
use_pager = os.environ.get('MANPAGER') or os.environ.get('PAGER')
if use_pager:
...
(yes, I think ignoring empty *PAGER is preferable to an error)
I am not sure, pydoc should respec
Alexander Belopolsky added the comment:
The patch looks fine, but I wonder if regrtest.py could be taught to warn about
situations like this. Maybe run_unitest() should check that all leaf
subclasses of TestCase in the module are covered. Ideally, of course,
test_main() should be made
Alexander Belopolsky added the comment:
I am attaching a patch for py3k branch. I am +1 for backporting to 2.7 and I
avoided relying on py3k timedelta/timedelta in the patch. The tests and docs
will need to be modified for the backport.
Technically speaking, this is a change in documented
Changes by Alexander Belopolsky :
--
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue7900>
___
___
Python-bugs-list mai
Alexander Belopolsky added the comment:
> (1) there should be a Py_DECREF(total_microseconds) ...
Yes, regrtest -R is not a substitute for thinking.
> (2) in the docstring, replace 'loose' by 'lose'
>
Neither is spellcheck. :-)
> (3) also in the docstring, I
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17246/issue8644-py3k.diff
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Pytho
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17255/issue8644-py3k.diff
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17254/issue8644-py3k.diff
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Pytho
Alexander Belopolsky added the comment:
On Sat, May 8, 2010 at 10:07 AM, Mark Dickinson wrote:
..
> I definitely think this should go into 2.7 as well; Â total_seconds has only
> seen the light of day
> in the beta releases so far, so it's unlikely we'd break anyone's
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17266/issue8644.diff
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Python-bug
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17267/issue8644.diff
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Python-bug
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue8425>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
The problem is apparently due to the fact that small_set -= large_set
iterates over the large set removing entries from small_set while more
efficient small_set - large_set builds a new set iterating over a
small_set and adding items that are not in the
Changes by Alexander Belopolsky :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue8425>
___
___
Python-bugs-list mai
Alexander Belopolsky added the comment:
On the second thought, it is possible to preserve set identity and avoid
iteration over a large set. See issue8425a.diff attached.
It looks like the unit tests don't check identity preservation. I will submit
additional tests sh
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17284/issue8425-tests.diff
___
Python tracker
<http://bugs.python.org/issue8425>
___
___
Pytho
Alexander Belopolsky added the comment:
Note that issue8425a.diff leaves small_set.difference_update(large_dict)
unoptimized:
$ ./python.exe -m timeit -s "s = {1}; l = dict.fromkeys(range(1000));"
"s.difference_update(l)"
1000 loops, best of 3: 842 usec per loop
$ ./pyt
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue8256>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue8685>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I have two problems with this proposal:
1. In constrained memory environments, creating a temporary internal copy of a
large set may cause the difference operation to fail that would otherwise
succeed.
2. The break-even point between extra lookups and
Alexander Belopolsky added the comment:
I've noticed that your patch changes
>>> math.factorial(2.**63)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Python int too large to convert to C long
to
>>> math.factorial(2.**63)
Tracebac
Alexander Belopolsky added the comment:
I also started to wonder if a tighter upper limit for an acceptable argument
can be found.
In discussion of issue2138 I saw the following exchange:
"""
> Should there be some upper limit on the argument math.factorial would
take?
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 7:42 PM, Daniel Stutzbach
wrote:
..
> Isn't that adding an extra check in every case to speed up a
> you-can't-seriously-expect-that-to-work corner case?
>
The check is cheap - just a machine integer compari
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 7:42 PM, Daniel Stutzbach
wrote:
..
> Isn't that adding an extra check in every case ...
Speaking of micro-optimizations, did you consider a better than naive
algorithm for "Count the number of set bits in n&q
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 9:07 PM, Daniel Stutzbach
wrote:
>
> Daniel Stutzbach added the comment:
>
> On Tue, May 11, 2010 at 7:38 PM, Alexander Belopolsky
> wrote:
>> Speaking of micro-optimizations, did you consider a better th
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 10:19 PM, Alexander Belopolsky
wrote:
..
> Similarly, while unlikely to improve performance, I would prefer not
> to use any bit-trick implementation of ilog2 (in a separate function,
> of course) instead of calling float
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 5:58 PM, Mark Dickinson wrote:
> Yes, I'm interested in seeing the pure Python version.
Here is my translation of the reference implementation.
>Â It could go into test_math, and would be a useful form of documenta
Alexander Belopolsky added the comment:
On Tue, May 11, 2010 at 10:19 PM, Alexander Belopolsky
wrote:
..
> Another readability nit: for me k % 2 == 0 is a more readable check
> for even number than (k & 1) != 1. Performance-wise the two choices
> are the same, and either can b
Alexander Belopolsky added the comment:
On Wed, May 12, 2010 at 4:50 AM, Mark Dickinson wrote:
..
> (4) I wonder whether the recursion in factorial_part_product slows things
> down; Â it might be interesting to compare with an iterative version (but
> still one that clumps toget
Alexander Belopolsky added the comment:
Here is one more datapoint.
$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product; f = fm.factorial " "f(1)"
10 loops, best of 3: 66.1 msec per loop
[32794 refs]
$ ./python.exe -m timeit -
Alexander Belopolsky added the comment:
Daniel,
Your variant does not seem to work:
>>> def partial_product3(j, i):
... a = [l << 1 | 1 for l in range(j, i + 1)]
... n = len(a)
... while 1:
... if n == 1:
... return a[0]
... half = n//2
Alexander Belopolsky added the comment:
On Thu, May 13, 2010 at 5:31 PM, Mark Dickinson wrote:
> And why are we trying to speed up the pure Python factorial code here?
I would expect that for large factorials the performance will be
determined by the number of long multiplications and
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file17313/factorial4.py
___
Python tracker
<http://bugs.python.org/issue8692>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Thu, May 13, 2010 at 6:09 PM, Daniel Stutzbach
wrote:
..
> Speaking of getting side-tracked, I didn't see an answer to a question I asked
> earlier. I'd like to get some feedback before I proceed with revising the
> patch.
I did
Alexander Belopolsky added the comment:
On Wed, May 12, 2010 at 3:47 PM, Mark Dickinson wrote:
>...
> Realistically though, I don't see an iterative version of
> factorial_part_product as
> an option for the C patch, without a significant increase in complexity.
> Â Dani
Alexander Belopolsky added the comment:
On Thu, May 13, 2010 at 5:58 PM, Mark Dickinson wrote:
>Â Optimizations that speed up, say, factorial(n) for n <= 1000 would seem more
>valuable.
I am attaching a variant of my patch which precomputes partial
products that fit in 32 bit uns
Alexander Belopolsky added the comment:
Oh, my!
How did that last term get into precomputed list?!
It should have been
precomputed[] = {3, 15, 5, 35, 315, 63, 693, 9009, 1287, 19305, 328185, 36465,
692835,
14549535, 1322685, 30421755, 760543875, 58503375,
1579591125ul
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17327/factorial-precompute-partials.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Alexander Belopolsky :
Removed file:
http://bugs.python.org/file17327/factorial-precompute-partials.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Alexander Belopolsky :
Removed file:
http://bugs.python.org/file17325/factorial-precompute-partials.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17328/factorial-precompute-partials.patch
___
Python tracker
<http://bugs.python.org/issue8
Alexander Belopolsky added the comment:
Mark> Does anyone feel like doing a speed comparison between Daniel's C patch
and a version with a direct no-frills iterative version of
factorial_part_product (i.e., just a simple 'for (i = n; i <= m; i += 2) {
}?
Not a direc
Changes by Alexander Belchenko:
--
nosy: bialix
severity: normal
status: open
title: DeprecationWarning in zipfile.py while zipping 113000 files
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Alexander Belchenko:
C:\Python\2.5.1\lib\zipfile.py:719: DeprecationWarning: 'H' format
requires 0 <= number <= 65535
0, 0, count, count, pos2 - pos1, pos1, 0)
--
components: +Library (Lib)
__
Tracker <[EMAI
Alexander Belopolsky added the comment:
The problem still exists in 2.5.1.
The explanations given so far are not correct. With x.py as before (see
attached):
>>> import sys, gc, x
creating X('new')
creating X('old')
>>> del x,sys.modules['x']
de
New submission from Alexander Shigin:
Hello,
The operator "is" works strange with methods, i.e.:
>>> a = 1
>>> a.__abs__ is a.__abs__
False
If this is the preferred behavior by some reasons, I think
documentation should explain it.
It was tested on python 2
Alexander Shigin added the comment:
I think it's good idea to make a note in Comparisons section or make
some reference to data model section.
"""
The operators is and is not test for object identity: x is y is true if
and only if x and y are the same object. x is not
New submission from Alexander Belopolsky:
On Mac OS X, make fails with the following error
..
/usr/bin/ld: Undefined symbols:
_PyOS_mystrnicmp
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1
The attached patch fixes the issue.
--
components: Build
files: make
Alexander Belopolsky added the comment:
Looks like an SVN problem on my end. I am getting a stale version of the
makefile. Please close the issue as invalid.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Alexander Belopolsky:
In the spirit of files becoming context managers in 2.5, the attached
patch defines __enter__ and __exit__ methods for
tempfile.NamedTemporaryFile.
BTW, I was not able to add a "patch" keyword which seems appropriate here.
--
Alexander Belopolsky added the comment:
It also appears that the tuple and dict checks in function_call are
redundant. If there is a use case that results in function_call getting
anything (non null) other than dict and tuple in arg and kw, I don't
think silently ignoring such arguments i
Alexander Belopolsky added the comment:
Sorry, please ignore my last comment about arg. The null and tuple
checks are for argdefs, not arg.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alexander Belopolsky added the comment:
According to http://docs.python.org/api/object.html,
"""
PyObject* PyObject_Call(PyObject *callable_object, PyObject *args,
PyObject *kw)
Return value: New reference.
Call a callable Python object callable_object, with arg
Alexander Belopolsky added the comment:
Nick's comment made me think why NamedTemporaryFile can't simply
subclass file and get properly working context manager's methods for
free.
It turned out that although file is subclassable, in its present form,
it does not allow Nam
New submission from Alexander Belopolsky:
Attached patch makes file.__exit__ call subclass' close method.
--
components: Interpreter Core
files: file_exit.diff
messages: 62289
nosy: belopolsky
severity: normal
status: open
title: file.__exit__ does not call subclass' close m
Alexander Belopolsky added the comment:
Attached patch implements context management protocol for StringIO.
--
components: +Library (Lib)
nosy: +belopolsky
versions: -Python 3.0
Added file: http://bugs.python.org/file9470/with_StringIO.diff
__
Tracker
Alexander Belopolsky added the comment:
On i386 Linux, HZ is #defined as sysconf(_SC_CLK_TCK)
/usr/include/asm-i386/param.h:7:#define HZ sysconf(_SC_CLK_TCK)
so times does the right thing. On x86_64 HZ is defined as 100, but it
is the same value as sysconf returns.
I could not find an
Alexander Belopolsky added the comment:
Actually, a very simple change restores python2.5 behavior:
===
--- Modules/main.c (revision 60941)
+++ Modules/main.c (working copy)
@@ -187,6 +187,7 @@
if ((argv0
Alexander Belopolsky added the comment:
I have found relevant documentation in a comment preceding get_path_importer
definition:
... traverse path_hooks until a hook is found
that can handle the path item. Return None if no hook could;
this tells our caller it should fall back to
New submission from Alexander Belopolsky:
See attached patch.
--
components: Documentation
files: doc-import.diff
messages: 62678
nosy: belopolsky
severity: normal
status: open
title: Document PyImport_GetImporter
versions: Python 2.6
Added file: http://bugs.python.org/file9487/doc
Changes by Alexander Belopolsky:
Added file: http://bugs.python.org/file9488/issue2051.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2051>
__
___
Pyth
Changes by Alexander Belopolsky:
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2051>
__
___
Python-bugs-list mailing list
Unsubs
Alexander Belopolsky added the comment:
FYI: IEEE Standard 754 requires an invalid operation exception when
inf/nan conversion to integer is attempted.
--
nosy: +belopolsky
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Nick,
I understand the __main__.py issue now, but I still don't like your
approach. Allowing RunMainFromImporter to call exit and never return
does not feel right. (A minor problem is that objects on the C stack do
not get deleted.) Without a
Alexander Belopolsky added the comment:
I think a more elegant solution will be possible if issue2135 patch is
accepted. I suggest to reopen this issue for Py3k pending resolution of
issue2135.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alexander Belopolsky added the comment:
The patch breaks test_import on Mac OS 10.4:
$ ./python.exe -E -tt -bb ./Lib/test/regrtest.py test_import
test_import
test test_import failed -- Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 1199, in
main()
F
Alexander Belopolsky added the comment:
I've noticed that the proposed patch adds const qualifier to many C-API
functions' arguments. While at the first glance these changes are
reasonable, they add clutter to the already massive patch.
I would recommend to separate const qualifi
Alexander Belopolsky added the comment:
First, let me state that I like the idea of a uniform approach to
importing, but given the complexity of the task, Brett's approach (which
I understand as implementing the builtin importer classes in Python)
would make sense (as long as he can solv
Alexander Belopolsky added the comment:
issue1546078 presents a much more ambitious patch - supporting arbitrary
longs in range. It looks like that patch was applied to py3k branch
where performance issues are not yet a concern.
Unless there are plans to backport 1546078, I would like to see
Alexander Belopolsky added the comment:
Yes, index/longindex optimization is nice and can be applied to xrange.
However, I don't think python-dev will be happy with the 1546078-style
changes going to 2.6 and optimization patches are probably premature for
3.0.
The ssize_t approach
Alexander Belopolsky added the comment:
Nick, you are right about sys.exit(). I did to much C programming
lately and forgot that sys.exit() does not exit. :-)
I understood your comment as saying that 'importer' points to a valid
importer. Now I understand that with the present st
Alexander Belopolsky added the comment:
os_times3.PATCH works for me on Mac OS 10.4 and RHEL. I have a few
comments on the patch:
1. sysconf return type is long, not clock_t
2. If sysconf is present, but _SC_CLK_TCK is not supported, it will
return -1. In this case we should fall back to
1201 - 1300 of 4095 matches
Mail list logo
