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
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
See attached. I don't know how to write unit tests for -3 warnings.
--
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file9699/issue2341.diff
__
Tracker <[E
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
While writing the patch, I noticed that "/* Normalize to raise ,
*/" comment was misplaced. Please consider a minor patch
that fixes that.
Added file: http://bugs.python.org/file9700/issu
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This belongs to issue2291.
--
nosy: +belopolsky, brett.cannon
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I am commenting on issue2371 patch here, so that I does not get lost in
a non-showstopper issue. Taek, please reattach your patch here when you
get a chance.
With the additional -3 logic, code duplication between tuple and
non
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
There is also a subtle bug in the issue2371 patch:
$ cat x.py
try:
raise ValueError
except ((ValueError,),):
pass
$ ./python -3 x.py
x.py:3: DeprecationWarning: catching classes that do not inherit from
BaseException
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is a minor concern, but existing -3 warnings refer to python 3.0
and above as "3.x", not 'Py3K'. It would be nice to preserve consistency.
--
nosy: +belopolsky
__
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Correction for msg63584: the old/new style difference example should read
"""
class x:
pass
class y(x):
pass
try:
raise y
except y:
print "b"
except:
print "a"
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Benjamin,
Your recent patches all use 4-space indentation, but Python 2.x
recommended style is still to use tabs unless you start a new file. See
PEP 7.
--
nosy: +belopolsky
__
T
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
-1
Sites that need this functionality can emulate this feature in site.py
by adding
sys.path[1:1] = os.getenv("PYTHON3PATH", "").split(os.pathsep)
in py3k installation.
I could not find any discussion b
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I left the following comment in issue2291 pertaining to this patch:
"""
There is also a subtle bug in the issue2371 patch:
$ cat x.py
try:
raise ValueError
except ((ValueError,),):
pass
$ ./
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
..
> - raising exceptions that don't derive from BaseException
See patch at issue2341.
__
Tracker <[
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
As requested by Guido at msg63858. Will create a patch.
--
components: Interpreter Core
messages: 63864
nosy: belopolsky
severity: normal
status: open
title: Raise a Py3K warning for __getitem__ or __getslice__ on exc
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> We still need patches to issue -3 warnings for:
> - __getitem__ or __getslice__ on exception instances
>
I've opened a se
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
As of r61478, the following code fails to produce a py3k warning:
try:
raise ValueError
except ((ValueError,object),):
pass
which is an error for in py3k:
Traceback (most recent call last):
File "x.py&q
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Mar 17, 2008 at 11:09 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
>
> Alex, can you please open a separate bug for that? The cross-posting of
> comments is unhelpful, and the issue was not introduced b
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
With the attached patch and -3 option:
>>> Exception(1,2,3)[0]
__main__:1: DeprecationWarning: In 3.x, __getitem__ is not supported for
exception classes, use args attribute
1
>>> Exception(1,2,3)[:]
__main__:1
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file9720/issue2380.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch fixes the problem.
Note that the original os.strerror code was not standard compliant.
See e.g.
http://www.opengroup.org/onlinepubs/95399/functions/strerror.html
--
keywords: +patch
nosy: +belopolsky
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
components: +Extension Modules
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2413>
__
__
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9755/posix-strerror.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Please ignore the first patch. I don't have enough permissions to remove
it.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
ISO/ANSI C strerror indicates out of range error by setting errno, but
existing code incorrectly checks for NULL return value. Attached patch
(tested n Mac OS X) makes os.strerror raise ValueError for out of range
ar
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
> I don't understand your objection.
> It sounds like you're objecting, but
> then suggesting an implementation?
This sounds like a kludge addressing a transient
problem. It also feels like a solution cate
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I agree this is a bug. Here is a related problem:
>>> 1 is divmod(1,1)[0]
False
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://b
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>>> int('1') is 1
False
>>> 1 is int('0b1', 2)
False
>>> 1 is 0b1 >> 4
False
there are probably more ...
__
Tr
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>>> 1 is 1|1
False
>>> 1 is 1&1
False
>>> 0 is 1^1
False
>>> 2 is 1<<1
False
__
Tracker &
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
And on some system "Unknown error: nnn" is returned with no error indication.
Your concern that the patch is invalid on some unidentified system.
This concern
can easily be addressed by checking for NULL return *in
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch fixes the cases discovered so far. It is possible that
in some of these cases creation of the long object that is later
discarded can be avoided by detecting small int return early, but such
optimizations
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached (issue2417a.diff) patch adds unit tests and fixes a few corner
cases when a non-preallocated 0 was returned to python.
Added file: http://bugs.python.org/file9785/issue2417a.diff
__
T
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This has been fixed around r42454.
--
nosy: +belopolsky
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This looks like a duplicate of issue723806 which was closed as "won't
fix."
--
components: +Interpreter Core -None
nosy: +belopolsky
type: -> behavior
Tracker &
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Mar 24, 2008 at 4:53 AM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> I'm not sure the class docstring approach is suitable for a mixin. It
> seems fine to me that pydoc strips the comme
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I hate to flip-flop like this, but please consider my new
arguments at issue2268. In short, slices being unhashable
prevents storing them in the code object's const dictionary
and thus prevents optimizing code involving c
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Looking at stringobject.c:1034:
i = 0;
if (i < size) {
Py_MEMCPY(op->ob_sval, a->ob_sval, Py_SIZE(a));
i = Py_SIZE(a);
}
while (i < size) {
j = (i <= size-i) ? i : size-i;
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch (issue1569291.diff) reimplements the optimization by
following Objects/stringobject.c logic as Raymond suggested.
I see two remaining issues which in my view should be addressed separately:
1. There is no che
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I forgot to mention that I added a unit test to cover the special case
of repeating a single-byte array.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I think this issue is largely superseded by PEP 3118
<http://www.python.org/dev/peps/pep-3118>, which is being backported to
2.6 (see issue2393). AFAICT, the only functionality not available from
the new buffer pro
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is a duplicate of issue2223. (See msg63244.)
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is a duplicate of issue2223.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is not a bug. All the reported functions expect va_list argument
to be initialized before being called. AFAICT, they are consistently
used in this way. For example,
PyObject *
PyObject_CallFunctionObjArgs(PyObject *ca
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the second thought the macro dance highlighted by OP belongs to
pyport.h. Attached patch defines Py_VA_COPY macro and uses it to simplify
va_list copying code.
--
keywords: +patch
Added file: http://bugs.pyth
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
title: uninitialized access to va_list -> Define Py_VA_COPY macro as a
cross-platform replacement for gcc __va_copy
type: compile error -> feature request
__
Tracker <[EMAIL PR
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
When peephole optimizer folds multiple constants into one, the old
constants remain in co_consts. Attached patch removes such unused
constants.
--
components: Interpreter Core
files: compress-consts.diff
keywords:
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I've noticed that the original patch does not handle the error condition
from failed consts resize correctly. Please see compress-consts-1.diff
for a fix.
Added file: http://bugs.python.org/file9868/compress-co
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Just to quantify the improvement:
Before:
$ ./python -m timeit -s"x='abc'" "x[::-1]"
100 loops, best of 3: 0.305 usec per loop
$ ./python -O -m timeit -s"x='abc'" "
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I have never had a problem of different python versions coexisting on
the same machine, but having 32-bit and 64-bit python coexist is much
harder. Particularly when 32-bit python is compiled on the 64-bit OS
(using -m3
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Can someone update the priority so that this is looked at before the 2.6
release?
--
nosy: +belopolsky
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Placing the entire library tree in /usr/lib64 is wasteful on dual
32/64bit installation, but placing just the C modules there is contrary
to python import logic and may cause problems to relative imports.
I have suggested
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Before:
>>> dis(lambda:+2)
1 0 LOAD_CONST 0 (2)
3 UNARY_POSITIVE
4 RETURN_VALUE
>>> dis(lambda:not 2)
1 0 LOAD_CONST
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Mar 28, 2008 at 3:25 AM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
>
> It would be helpful if we talked before going further on build-outs to
> the peephole optimizer.
Sure.
> IIRC, we chose to no
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Despite the title, the patch replaces "result == False" with "not
result" rather than "result is False". While probably ok in this
particular context, this changes the logic. For example,
>&
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Raymond wrote in his recent response on issue2499 (a patch that adds
unary '+' and 'not' folding to peephole optimizer):
"""
More importantly, we decided that the peepholer is the wrong pla
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This patch was applied at r37285 (in svn terms). It looks like closing
this issue was blocked by #1057835 which was deemed unrelated and
resolved in any case.
I suggest to close this issue.
--
nosy: +belopolsk
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I think this is not a bug. Here is a simpler way to illustrate the
issue:
def f(x):
for i in range(10):
if x:
pass
continue
f(True)
f(False)
If you run the code above under trace, you g
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sat, Mar 29, 2008 at 2:51 PM, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>
> Ned Batchelder <[EMAIL PROTECTED]> added the comment:
>
> I am measuring the code coverage of a set of tests, and one of my l
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sat, Mar 29, 2008 at 4:58 PM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> This has basically almost never been a problem in the real world.
I believe Ned gave an important use case. In coverage testing,
optimize
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Opening a new issue per Raymond's request at msg64764:
"""
It would be *much* more useful to direct effort improving the mis-
reporting of the number of arguments given versus those required for
instan
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
..
> It would be *much* more useful to direct effort improving the mis-
> reporting of the number of arguments given versus those requir
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch (issue2516poc.diff) presents proof-of-concept code which
changes the problematic reporting as follows:
>>> a.f(1,2)
Traceback (most recent call last):
File "", line 1, in
TypeError: .f() tak
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
..
> Weigh the cost/benefit carefully before pushing further. I don't doubt
> the legitimacy of the use case, but do think it affect
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I am attaching my fix along the lines of a solution suggested by Amaury
at http://mail.python.org/pipermail/python-dev/2008-
February/076747.html:
"""
> Or is the proper fix to incref the values
> going i
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
A more general approach would be to add both 'locals' and 'globals' to
be used by exec. At least, I would change 'ns' to 'locals'.
--
nosy: +belopolsky
__
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the second thought, I actually wanted Timer to mimic eval without
realizing that eval uses positional rather than keywords arguments.
'locals' is obviously a bad choice for the keyword parameter because it
masks
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 2, 2008 at 2:42 AM, Peter Otten <[EMAIL PROTECTED]> wrote:
> Alexander, I'm fine with a more specific argument name. ns was what
> the Timer already used internally.
>
Maybe it should be "
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I am uploading another work in progress patch because the problem proved
to be more difficult than I thought in the beginning. The new patch
addresses two issues.
1. a.f(..) -> A.f(a, ..) transformation is performed is sever
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 3, 2008 at 9:39 PM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> It's definitely a bug
What would you say to the following:
def f(x):
pass
class X:
xf = f
x = X()
x.xf(1,2)
--> TypeErr
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Thomas,
Could you add BUILD_*_UNPACK opcodes documentation to
Doc/library/dis.rst? It would also help if you modify CALL_FUNCTION_*
opcodes' documentation to explain how they will interact with unpacking
opcodes.
Do I
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
OP does not have the reference, but the issue is apparently in the time
and datetime modules documentation:
http://docs.python.org/dev/library/time.html#time.strftime
http://docs.python.org/dev/library/datetime.html#strftime-be
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 3:07 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Can you show an example where this would be different?
Admittedly a contrived example, but
...def __hash__(self):
...pri
1301 - 1400 of 3596 matches
Mail list logo
