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
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 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
Changes by Alexander Belopolsky:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1040026>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mai
Alexander Belopolsky added the comment:
Small comment on the patch:
def clear(self):
-for key in self.data.keys():
+for key in self.keys():
unsetenv(key)
-del self.data[key
Alexander Belopolsky added the comment:
I would say dict's failure to call overloaded __setitem__ from
setdefault is a dict implementation problem which should be either
fixed, or clearly documented as warning to anyone who wants to derive
from dict.
A fix would be tr
Alexander Belopolsky added the comment:
> dict doesn't dynamically bind any calls; to
> properly replace the semantics of dict, you
> have to implement *all* API.
What was the rationale for this decision? To me it looks like a hold-
over from the time when dicts were not subclass
Alexander Belopolsky added the comment:
First, if the new thread on dict behavior does not make sense, please
see discussion at issue1367711 where it started. (My mistake following
up here.)
Second, the ability to subclass built-in type is such a great feature,
that it is a shame that doing
Alexander Belopolsky added the comment:
> The builtins make direct calls to their own internal methods.
Raymond, I guess issue2067 escaped your review. :-)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Alexander Belopolsky added the comment:
Let's get back on-topic.
I assume you are recommending to close this issue by rejecting the
patch. I disagree. The patch can be fixed to properly override all
methods and a unit test can be added to guarantee that all dict methods
are overr
Alexander Belopolsky added the comment:
See comments at issue2144. Benjamin Peterson demonstrated a more than 2x
speedup on a micro-benchmark. Plus, the fact that two people were
motivated enough to independently produce a near-complete patch is worth
something
Alexander Belopolsky added the comment:
> 1. .. It's preferable to cast into a clock_t immediately rather than
> doing a conversion for each of the ensuing divisions.
If that's your motivation, then you should cast to double instead.
However, I would leave it to comp
Alexander Belopolsky added the comment:
Aha, I should read my own sources:
"The value shall not change during the lifetime of the calling process,
[XSI] except that sysconf(_SC_OPEN_MAX) may return different values
before and after a call to setrlimit() which changes the RLIMIT_NOFILE
Alexander Belopolsky added the comment:
FWIW, the following minimal patch fixed the bug on MacOS X and does not
affect Linux:
===
--- Modules/posixmodule.c (revision 61014)
+++ Modules/posixmodule.c (working copy
Alexander Belopolsky added the comment:
Did anyone mention "clutch"? :-)
Oh, well, please close issue1367711 as a duplicate.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
New submission from Alexander Belopolsky:
Attached patch improves pydoc UserDict presentation.
One of the problems with the current documentation in comments is that
order of methods is not preserved and thus the method level comments in
DictMixin implementation are meaningless in pydoc. (In
Changes by Alexander Belopolsky:
Added file: http://bugs.python.org/file9530/UserDict-doc.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2172>
__
___
Pyth
Alexander Belopolsky added the comment:
Fixed an error in lavels doc. Needs review.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2172>
__
___
Python-bugs-list
Changes by Alexander Belopolsky:
--
components: +Documentation
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2172>
__
___
Pyth
Alexander Belopolsky added the comment:
Here is my take (posixmodule.diff). When ticks per seconds cannot be
determined, python should not provide times rather than refuse to build.
Initialization moved to the init function.
--
keywords: +patch
Added file: http://bugs.python.org
Alexander Belopolsky added the comment:
> I'd prefer a noisy compile error ..
That would be fine if you could verify that none of the currently
supported platforms will be affected. I would still feel uneasy about
refusing to build python simply because os.times is not ported to a
Alexander Belopolsky added the comment:
> You complained in msg62869 about the original patch that calling
sysconf
> on every call leads to an unacceptable slowdown. Your one-line patch
> calls sysconf five times on each call when HZ is not defined.
That's why I said that w
Alexander Belopolsky added the comment:
> HZ may be defined on your machine, but it isn't on my (Xeon) machine.
Are you sure? Please note that HZ will not show up in grep -w HZ
/usr/include because the right header file further up the tree.
On Solaris:
/usr/include/sys/param.h
Alexander Belopolsky added the comment:
Thanks Cristian for your intervention. This bug is clearly an
aberration: how many GvR reported bugs do you know that stayed open for
3+ years?
I think posixmodule.diff satisfies all your requirements and was not
opposed by anyone except yours truly
Alexander Belopolsky added the comment:
This is related to issue1540617 and issue1546078.
issue1540617 contains a simple patch that extend acceptable range of
argument to +/-2**63
issue1546078 contains a complete long integer support implementation and
was accepted in Py3k.
It looks like
Alexander Belopolsky added the comment:
> enumerate() and itertools.count() both
> show how to support arbitrary longs without
> killing the performance of common cases.
Unlike enumerate() and count(), range object has 3 integer members:
start, step and len. Doubling all of them as
Alexander Belopolsky added the comment:
Christian,
I was probably a bit sloppy using "range" instead of "xrange," but issue1540617
is limited to xrange only. Are you still -10 on extending
xrange on 64-bit platforms to +/- 2**63? If so, what is your position
on backport
Alexander Belopolsky added the comment:
> So far the memory for the ints is *never* returned
> to the system. I'm working on the problem.
Christian,
Are you working on the memory problem or on this issue? I think I have a
solution to OP's problem, but don't want to
Alexander Belopolsky added the comment:
Attached patch addresses OP's issue:
$ ./python.exe bad_range.py
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L,
18446744073709551619L, 18446744073709551620L, 1844674407370955
Alexander Belopolsky added the comment:
I am not sure what this patch would accomplish. I tried
$ cat t.py
def f():
return 1
1+2
from dis import dis
print dis(f)
Both with and without patch I get
$ ./python.exe -O t.py
2 0 LOAD_CONST 1 (1)
3
Alexander Belopolsky added the comment:
Douglas Greiman submitted many similar changes with his issue2135 patch.
His patch also amends documentation, which is missing here.
I am adding dgreiman to the nosy list here to avoid duplication of
effort.
I am -0 on the idea.
--
nosy
Alexander Belopolsky added the comment:
> Do we really need another way to spell a <= x < b? Have you got a
> real-world use case in mind for the version with step > 1?
> I'm at most lukewarm; I'd be willing to look at a patch to the C code
> in the py3k-struni
Alexander Belopolsky added the comment:
In the absence of an identity function, map accepting None is useful in
the cases like this:
converters = {..}
y = map(converters.get(c), x)
That will now have to be rewritten as
conv = converters.get(c)
if conv is None:
y = list(x)
else:
y = map
Alexander Belopolsky added the comment:
> What specific event triggered your working on this?
That was a long time ago, but IIRC, we had some code dealing with large
files that grew up beyond 2G. The files contained fixed-length records
and we used xrange to iterate over record offsets.
Alexander Belopolsky added the comment:
Attached patch removes support for None from filter and
itertools.ifilter. My objections for removing that from map do not
apply because bool function can be used instead of None in filter
achieving similar performance and better clarity.
None support
Alexander Belopolsky added the comment:
Can you assign this to Raymond as well? If this is done first, issue2186
patch will be simpler (at least in the documentation portion). The same
question on the fate of ifilterfalse is pertinent here as well.
--
nosy: +belopolsky
Alexander Belopolsky added the comment:
I figured that out:
>>> def g():
... raise RuntimeError
...
Before the patch:
>>> dis(g)
2 0 LOAD_GLOBAL 0 (RuntimeError)
3 RAISE_VARARGS1
6 LOAD_CONST
Alexander Belopolsky added the comment:
Raymond,
There must be a reason why we constantly disagree. Do you live in
California by any chance? :-)
I am not sure if map(None, ..) fate is still up for voting given your
changes at r60206, but your own patch illustrates the problem that I
Alexander Belopolsky added the comment:
Raymond,
it looks like you just broke the build for me:
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c: In
function 'ifilter_next':
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c:2058:
error: invalid operands
Alexander Belopolsky added the comment:
Attached patch adds test_elim_unreachable() unit test. Last two
assertions should fail with unpatched python.
I am still trying to convince myself that the transformation are
correct.
> I propose that codestr[] array is made one byte
> long
Alexander Belopolsky added the comment:
Paul,
You are right. I misunderstood that comment myself. I've tried the
attached modification to your patch (unreachable-code-1.diff) and it
passes all tests while fixing msg62953 problem:
$ cat t.py
def f():
return 1
1+2
from dis i
Alexander Belopolsky added the comment:
> What do you guys think about just making the predicate argument
> optional?
You've read my mind! That what I was going to suggest if I realized that
optional argument does not have to be the last one.
Looks like it would make se
Alexander Belopolsky added the comment:
> I think the motivation behind your other use case will likey be
> addressed in a more general way with an identify function being
> added to the operator module.
Quite true, but I thought operator.identity was dead and buried. Can
y
Alexander Belopolsky added the comment:
I have added more tests as Neal suggested. See unreachable-code-with-
tests.diff for a combined patch. I've rerun all tests after removing
.pyc files and also with -O option (ensuring no existing .pyo files as
well). All works.
I've rem
Alexander Belopolsky added the comment:
Raymond Hettinger wrote in msg63027 (issue2186):
"""
.. it looks like there [is an] agreement on dropping None for map() and
going forward with the operator.identity() patch. Will check these in
in the next couple of days.
"&quo
Alexander Belopolsky added the comment:
> Since you don't increment codelen ..
Good catch!
> For this reason, if() before
> writing the RETURN_VALUE is not needed.
In this case it will be clearer to use STOP_CODE instead of RETURN_VALUE
New submission from Alexander Belopolsky:
I am attaching a proof-of-concept patch that changes the bytecode
generated from {1:1,2:2,3:3,4:4} from
BUILD_MAP4
LOAD_CONST 2 (1)
LOAD_CONST 2 (1)
STORE_MAP
LOAD_CONST 1 (2
Alexander Belopolsky added the comment:
Hmm, it looks like this was considered before (issue402227), but back
then there were no set literals. If stack-saving approach is better for
dicts, it should be better for sets as well. In any case, maybe it is
time to revisit the issue and decide on
Alexander Belopolsky added the comment:
I did not think of the insertion after creation change of semantics. Do
I understand that this is important when keys have custom
comparison/hash methods with side-effects. If it is important for the
language to guarantee the create/insert order in
Alexander Belopolsky added the comment:
The patch looks reasonable to me. Bytecode docs need to be changed. At
minimum like this:
===
--- Doc/library/dis.rst (revision 61097)
+++ Doc/library/dis.rst (working copy)
@@ -463,9 +463,9
Alexander Belopolsky added the comment:
Since names and varnames are known to be tuples of interned strings,
they can be compared without calling abstract API. Just compare sizes
and then compare item pointers in a loop.
What are the cases when co_names == co_varnames? How often is this the
Alexander Belopolsky added the comment:
Here are my comments on the py3k patch:
1. Sign of a PyLong object o is the same as the sign of Py_SIZE(o). I
would think it is safe to use this fact within python core. (User code
that may need to work across multiple versions of python may need to
Alexander Belopolsky added the comment:
It looks like non-windows code has a similar problem:
static PyObject *
posix_2str(PyObject *args,
char *format,
int (*func)(const char *, const char *))
{
char *path1 = NULL, *path2 = NULL;
int res;
if
Changes by Alexander Belopolsky:
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2179>
__
___
Python-bugs-list mailing list
Unsubs
Alexander Belopolsky added the comment:
It looks like you are running regrtest from the trunk with the py3k
interpretor.
Works for me.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alexander Belopolsky added the comment:
attached simple patch seems to fix the problem but should be reviewed by
Christian.
--
keywords: +patch
Added file: http://bugs.python.org/file9596/regrtest.patch
__
Tracker <[EMAIL PROTECTED]>
Alexander Belopolsky added the comment:
> Can you test it on your machine please?
Running on a 4-core Opteron (2.6GHz).
Should complete in an hour or so ...
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Alexander Belopolsky added the comment:
test_collections fails (with -R :: only). Does not look like something
related to the recent changes, rather test is not happy about being
repeated.
$ ./python Lib/test/regrtest.py -R :: test_collections
test_collections
beginning 9 repetitions
Alexander Belopolsky added the comment:
I would say filename/lineno are excluded from hash on purpose because
they are ignored in comparisons:
>>> compile("0", "a", "eval") == compile("0", "b", "eval")
True
Include/code.h
Alexander Belopolsky added the comment:
Here are the results from regrtest.py -R ::
..
301 tests OK.
7 tests failed:
test_collections test_cprofile test_frozen test_inspect
test_logging test_pkg test_profile
..
$ cat reflog.txt
test_cmd_line leaked [-23, 0, 0, 23] references, sum=0
New submission from Alexander Belopolsky:
Much of existing code relies on PyArg_Parse* leaving C variables
unmodified when conversion failed. Attached patch documents that
behavior.
--
files: doc-arg.diff
keywords: patch
messages: 63243
nosy: belopolsky
severity: normal
status: open
Changes by Alexander Belopolsky:
--
components: +Documentation
severity: normal -> minor
type: -> feature request
versions: +Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky added the comment:
The affected code is the only case I could find in stdlib where O&
format was used to populate PyObject* variables. Although it appears to
be valid usage, the code presents an exception to the following note at
http://docs.python.org/dev/c-api/arg.
Alexander Belopolsky added the comment:
Good catch, Hirokazu!
The patch looks correct to me.
Works as advertised on Mac OS 10.4.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alexander Belopolsky added the comment:
On the test_os patch: I would rename LeakTest to ErrorTest and leave it
on for all platforms. BTW, I cannot produce a definitive proof that
posix_2str leaks when second conversion fails (regrtest -R does not
catch it because the leaked buffer is not a
Alexander Belopolsky added the comment:
PYTHONPATH variable is likely to be defined by sysadmins who may not know
what os.pathsep is. Maybe it is better to say "OS-dependent separator
(';' on Windows, ':' on Linux and other UNIX-like OSes or ',' on some
les
Alexander Belopolsky added the comment:
> .. but I have made the doc reference a link to the os.pathsep
I knew you would say that :-). I was making my comment out of real life
experience: sysadmins rarely know python language, but can do good job
administering python installations.
Alexander Belopolsky added the comment:
> Feel free to propose an alternative wording for the patch
I thought I already did in my first post. The complete sentence should
read:
"""
The format is the same as the shell's :envvar:`PATH`: one or more
directory pathn
Alexander Belopolsky added the comment:
With the following patch:
===
--- Lib/test/test_itertools.py (revision 61284)
+++ Lib/test/test_itertools.py (working copy)
@@ -707,6 +707,12 @@
a = []
self.makecycle
Alexander Belopolsky added the comment:
It looks like the problem is that the internal grouper object becomes a
part of a cycle: keyfunc -> grouper(x) -> keyfunc(tgtkey), but its type
does not support GC. I will try to come up with a patch.
__
Tracker &
Alexander Belopolsky added the comment:
Oops. Here is my patch anyways.
--
keywords: +patch
Added file: http://bugs.python.org/file9625/groupby-leak.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Alexander Belopolsky added the comment:
I think it should be changed to "because sizeof(Py_ssize_t) ==
sizeof(void*)"
--
nosy: +belopolsky
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
1201 - 1300 of 3596 matches
Mail list logo
