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
Alexander Belopolsky added the comment:
Aha! I did not know about the cleanup. Maybe that should be documented
as well.
This shows that using O& with a converter returning a PyObject* is a bad
idea. (General clean-up is not possible for O& because there is no way
to tell what
Alexander Belopolsky added the comment:
Your description of the patch is a bit misleading. As far as I can tell
only the first chunk (Python/import.c changes) addresses a potential
buffer overflow. For example the last chunk (Modules/posixmodule.c
changes) simply eliminates an unused variable
Alexander Belopolsky added the comment:
I tried to produce a buffer overflow in get_parent (import.c), but an
attempt to import a module with non-ascii characters is aborted in
getargs.c before get_parent is reached:
>>> __import__("\u0080xyz")
Traceback (most recent call las
Alexander Belopolsky added the comment:
Here are my comments on the other parts of the patch:
Python/structmember.c
The existing code is safe, but would silently produce wrong result if
T_CHAR attribute is assigned a non-ascii character.
With the patch this situation will be detected and an
Alexander Belopolsky added the comment:
Patch # 408326 was designed to make assignment to d[:] an error where d
is a dictionary. See discussion starting at
http://mail.python.org/pipermail/python-list/2001-March/072078.html .
I think the only reason slice objects need to be comparable is
Alexander Belopolsky added the comment:
> the change was meant to unify
> the behavior of built-in and
> user method objects
I don't think it achieved that. Consider:
>>> [].index == [].index
False
but
>>> UserList().index == UserList().index
Tr
Alexander Belopolsky added the comment:
This issue has been resolved in issue1742669 .
$ ./python.exe
Python 2.6a1+ (trunk:61230M, Mar 4 2008, 10:56:31)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license
Alexander Belopolsky added the comment:
In case I did not make my position clear in my previous post, I am -1 on
this RFE. x[:] should mean slicing, not getitem.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Note that L[:] and L[:] = [] are well-known idioms for making a copy of
a list and emptying the list respectively. (For dictionaries we have
D.copy() and D.clear().) Someone looking at x[:] or x[:] = [] should
immediately recognize a list copy or clear
Alexander Belopolsky added the comment:
Georg, did you miss the s/assuming/because/ part of my proposal? Python
guarantees that sizeof(Py_ssize_t) == sizeof(size_t) == sizeof(void*). (See PEP
353.)
"Assuming" is therefore misleading because it suggests that it may not
be a
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Armin,
I think this should be discussed on python-dev. I don't understand your
motivation for comparing methods of distinct but equal objects as equal.
The callback argument on the other hand, is
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
FWIW, grepping through Lib/test reveals the following statistics:
assertFalse: 83
assertTrue: 97
failUnless: 684
assert_: 1977
Not having assertTrue/assertFalse methods in the Library Reference does
not discourage people from
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Just to make the story complete, it should be mentioned that
assertFalse/True were added because these are the names used by JUnit:
r34209 | purcell | 2003
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
I am attaching a proof-of-concept patch which would optimize bytecode
generated from constant slices as follows:
Before patch:
>>> dis(lambda:x[1:2:3])
1 0 LOAD_GLOBAL 0 (x)
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is trivial to implement (see attached) and IMHO is a good idea.
The next question, however is whether similar changes should be made to
timedelta arithmetics. Timedelta case is not so clearcut because of the
usual dile
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Invoking a subclass's constructor is only an issue when subclass adds
data members. In this case, arithmetic methods need to be overridden.
Note that my patch does not make __add__ and friends invoke subclass'
c
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
It may be too late to express my opinion, but why symmetry with map is
so important? There are several reasons why sequence, predicate order
is natural for filter and function, sequence is a natural order for map.
1. I
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Py3k behavior seems to be better:
Python 3.0a2+ (py3k:61137M, Feb 29 2008, 15:17:29)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
>>> try:
... raise ValueError("foo")
... except object:
...
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This was discussed years ago and never got enough support:
http://mail.python.org/pipermail/python-dev/2005-October/057177.html
--
nosy: +belopolsky
type: -> feature request
__
Tracke
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
It looks like I completely missed PEP 3132. Sorry for a misleading
comment above.
At least I am not alone: "A little new feature in Python 3 that many
overviews don't tell you about: extended unpacking."
http:
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Note that this patch will expose a bug fixed in issue1950. (See msg63363.) I
suggest that the import.c part of issue1950 and this go
together. Alexandre?
--
nosy: +alexandre.vassalotti, belo
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I thought some more about this issue and the current behavior seems
wrong and potentially dangerous. Consider the following code:
class x:
pass
class y(x):
pass
try:
raise y
except y:
print "
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is a documented feature:
"""
normpath(path)
Normalize a pathname. ... It should be understood that this may change
the meaning of the path if it contains symbolic links!
"""
See http://doc
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This was duplicated in issue726204 and fixed in r37026.
--
nosy: +belopolsky
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
A related issue419070 was closed with no resolution (or resolution did
not survive the trip from SF), but it looks like the patch was rejected.
Some work towards this issue was done in r21437, but 7 years later it is
still mar
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This depends on issue433024 (SRE: (?flag) isn't properly scoped.)
--
nosy: +belopolsky
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is still a valid issue. (As of Python 2.6a1+ (trunk:61434, Mar 17
2008, 08:06:54).)
>>> bool(re.match("abc(?i)","AbC"))
True
The documentation says that the behavior of a regex with (?) not
at
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
If any work needs to be done on this issue, it should probably be
labeled "easy." (At least the writing the unit tests part. Making
<...> reprs consistent is another story.)
The unit tests for old-style and
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Mar 17, 2008 at 9:51 AM, Alexandre Vassalotti <
[EMAIL PROTECTED]> wrote:
>
> Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:
>
> .. Although I haven't reviewed this
> pat
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I think the attached patch captures the most of what can currently be
said about <...> reprs.
I think the biggest offender in terms of inconsistency in the 2.x series
is the file object with the repr which does not eve
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
There is now issue2322 (Clean up getargs.c and its formatting
possibilities) related to this.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
1301 - 1400 of 4095 matches
Mail list logo
