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 Schmolck <[EMAIL PROTECTED]> added the comment:
Ah, well nice to see this finally going somewhere, although I'm a bit
puzzled as to why my patch was "clearly not implemented" :)
Andy, wrt. to your points:
1. Yes, but see below.
2. Are you sure using i
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
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I missed the first line copying the class definition into my previous
post. Class 'X' was defined as follows:
class X(int):
def __hash__(self):
print('hash', self)
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the other hand, the time module allows full [00,61] range:
>>> [time.strftime('%S',time.strptime(x, '%S')) for x in ('00', '61')]
['00',
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 3:42 PM, Anton Fedorov <[EMAIL PROTECTED]> wrote:
> There no leap second in 2000th.
I was just too lazy too look up the leap second year, but datetime
module knows nothing about leap second
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 4:02 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> .. The order of evaluation is the same, the
> BUILD_SET implementation just hashes the evaluated items in a different
> order. You can&
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Python-3000 discussion <http://mail.python.org/pipermail/python-
3000/2008-March/012753.html> did not reveal any opposition to the idea
of batch processing of dict displays. However, a compromise suggestion
was made to l
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
title: PyString_FromStringAndSize() to be considered unsane ->
PyString_FromStringAndSize() to be considered unsafe
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
As long as snprintf is used with a fixed size buffer using an idiom
snprintf(buffer, sizeof(buffer), ..)
there is no issue because sizeof(buffer) cannot be zero. AFAICT, this
is how python uses PyOS_vsnprintf wrapper.
On the
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Tue, Apr 8, 2008 at 9:21 PM, Justin Ferguson <[EMAIL PROTECTED]> wrote:
> ..
> While no one seems to ever use it this way, don't forget that a good
> alternative to asprintf() is calling sprintf() with
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This has just been fixed in the trunk: r62235.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I agree that PySSL_SSLread should check that its argument is >= 0. I
don't think this check belongs to PyString_FromStringAndSize. It
should be the responsibility of the caller to verify that the
preconditio
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 1:16 PM, Justin Ferguson <[EMAIL PROTECTED]> wrote:
..
> That said, theres plenty of other implementations that manage this
> without the potential of underflowing a buffer
>
Do you have i
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 1:20 PM, Justin Ferguson <[EMAIL PROTECTED]> wrote:
..
> Do I need to create proof of concepts for each of these bugs, or can I
> reference this ticket?
>
It would be best if you could pro
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 3:08 PM, Justin Ferguson <[EMAIL PROTECTED]> wrote:
> Okay, so I'm not sure whose point of view takes precedence here?
I don't have a strong view on this, but just a few points to co
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 2:49 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Isn't the bug here rather that strptime doesn't allow leap seconds?
This is not specific to strptime. The datetime module do
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Omitting the ordinals from {} format units will present a problem with
internationalization because the arguments may need to be rendered in
different order in different languages. This is a frequent problem with
the % formats
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is a feature explained in PEP 3101:
"""
Implementation note: The implementation of this proposal is
not required to enforce the rule about a simple or dotted name
being a valid Python identifier.
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Your patch does not check the return values of PyObject_RichCompare
calls for NULL. This is probably ok given the current restrictions on
the type of start/step/stop, but adding the null checks will make the
code more
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Actually, the patch contains an exploitable bug:
$ cat x.py
class X(int):
def __eq__(self, other):
raise ValueError
x = range(X(1),X(10),X(1))
x == x
$ ./python x.py
Segmentation fault (core
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 6:08 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ah yes, and variable declarations must be at the start of a block
You can avoid the need for extra local variables by declaring
range_richcompa
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 10, 2008 at 3:16 AM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
>
> And, a __hash__ method should be added.
>
See issue2268 for a slice.__hash__ implementation which sho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
My guess is that this is due to the fact that strings cache their hash
values while tuples don't. IIRC, caching tuple's hash values has been
proposed and rejected some time ago. Furthermore, dict lookups are
heavily o
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
If @test file is not writable in the current directory,
test_support.TESTFN is changed to '/tmp/@test', but several tests fail
if TESTFN is an absolute path:
$ mkdir @test
$ make test
..
4 tests failed:
test_
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 10, 2008 at 1:17 PM, David Remahl <[EMAIL PROTECTED]> wrote:
> I submit that a check for negative values (non-assert-based) should be
> added to PyString_FromStringAndSize().
See is
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 9, 2008 at 8:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > [*sigh* i wish we didn't use a signed size type all over the place]
>
> What would you use for error returns then?
>
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 10, 2008 at 3:48 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
Maybe as the first step we could get rid of the size sign abuse in
long integer objects. I would suggest reserving a bit in the first
(or la
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
+1 on adding the match argument. Can you comment on how one would
implement the old behavior? I would guess match=lambda x,y: x in y,
which is not that bad, but maybe that should be the default and those
who need pattern ma
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
-1
I don't think <0, 1, ..., 9> is much clearer than range(0, 10). The
only problem students may have is that 10 not in range(0, 10), but this
can be learned very quickly. The <..> repr breaks x == eval(repr(
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I did not realize that the proposed patch only affects str and not repr.
Some of may previous arguments against it do not hold in this case, but
I am still -1.
If you introduce range before list, it will be hard to explain why
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
It looks like our messages have crossed in flight.
> this little patch allows them to print(range(100,0,-1))
> and get a much better intuition about what is happening.
This is a really bad example. Why would you want to i
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 11, 2008 at 12:10 PM, Michael Amrhein
<[EMAIL PROTECTED]> wrote:
>
..
> a) A string given in ignore contains wildcard character(s):
> In this case this parameter would have no effect in the previ
1401 - 1500 of 4095 matches
Mail list logo
