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
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 11, 2008 at 12:06 PM, Brad Miller <[EMAIL PROTECTED]> wrote:
> Our use of range in the first few classes is exactly for iteration
> purposes, but I do not like students to have to have too many mysteri
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
As you are working on this, please consider changing
self.hide+self.ignore in phase0 to chain(self.hide, self.ignore) where
chain should be imported from itertools. There is no need to create the
combined list (twice!) and not acc
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller <[EMAIL PROTECTED]> wrote:
..
> My question is how does this get resolved. When I posted this idea to
> python-dev Guido suggested an approach. Nobody else expressed an o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Note that in r61458 Neal replaced PyMem_RESIZE with a direct call to
PyMem_REALLOC thus eliminating integer overflow check even from the debug
builds.
--
nosy: +belopolsky, nnorwitz
__
T
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Justin,
Where did you find the definition that you cited:
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
?
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The following simple change should be enough for this issue, but I would
consider implementing the overflow check in the PyMem_RESIZE and PyMem_NEW
macros and de-deprecate the
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, Apr 13, 2008 at 11:12 PM, Gregory P. Smith
<[EMAIL PROTECTED]> wrote:
..
> Here's a patch that fixes this by making both Python's malloc and
> realloc return NULL if (0 <= size <= PY_SSIZE
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The patch does not add unit tests for hash(range(..)). I would actually
test that hash(range(a,b,c)) == hash((a,b,c)) for various values of a,
b, and c.
A nit-pick: while I personally like the coding style with line breaks
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Tue, Apr 15, 2008 at 10:21 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> I'm not really sure what to do about the hash. I
> just removed the Py_SIZE parts. I hope that's OK.
If you want to maintai
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
With range_eq5.patch applied on an x86-64 Linux box:
$ ./python
Python 3.0a4+ (py3k:62359M, Apr 16 2008, 13:36:31)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits&quo
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
range_eq5.patch fails to reproduce tuple hash because in the tuple hash
implementation the len variable varies between iterations over items. I
would just use literals for the three different values of mult rather
than copyin
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 16, 2008 at 3:40 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
..
> Why would you want to have hash(range(a,b,c)) == hash((a,b,c)) ?
No particular reason other than that this is easy to test and gives
some
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 16, 2008 at 9:24 PM, Benjamin Peterson wrote:
..
> Why not just hash a tuple?
There are a few reasons, but neither is good enough to have another
round of code review :-)
1. It is strange to have the hash function
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I would say this is a good idea for 2.6.
Note that C functions are more forgiving:
>>> from datetime import *
>>> date(1,2,**{u'day':10})
datetime.date(1, 2, 10)
>>> dict(**{u'x':1
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10045/issue2646.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the interface, I would suggest renaming 'exclude' to 'ignore' for
consistency with filecmp.dircmp. Also consider detecting file separator
in the patterns and interpreting them as an absolute (if
patte
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Current Doc/library/functions.rst says "The use of apply() is exactly
equivalent to function(*args, **keywords)." which is no longer correct
because f(*args, **keywords) notation allows use of an arbitrary mapping
as
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This has nothing to do with set.update, the difference is due to the
time to setup the generator:
$ python -m timeit -s 'x = set(range(1)); y = []' 'x.update(y)'
100 loops, best of 3: 0.38 usec per loo
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 24, 2008 at 2:23 PM, John Arbash Meinel
<[EMAIL PROTECTED]> wrote:
..
> So if you compare consuming a generator multiple times to creating it
> each time, it is 0.662 usec - 0.173 usec = 0.489 usec to
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
components: Interpreter Core
files: range.diff
keywords: patch
nosy: belopolsky
severity: normal
status: open
title: Fix indentation in range_item
versions: Python 3.0
Added file: http://bugs.python.org/file10104/rang
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Attached patch makes range objects precompute their length on creation.
This speeds up indexing and len at the expense of a small increase in
range object size. The main benefit, however is that unsupported length >
sy
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Attached patch adds documentation for the new in 2.5 APIs:
PyObject* PyLong_FromSsize_t(Py_ssize_t v)
PyObject* PyLong_FromSize_t(size_t v)
and
Py_ssize_t PyLong_AsSsize_t(PyObject *pylong)
--
assignee: georg.
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
-
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Web submission did not work. Trying sending the patch as an e-mail attachment.
--
keywords: +patch
Added file: http://bugs.python.org/file10108/doc-long.diff
__
Tracker <[EMAIL
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
For some reason the tracker web interface fails to upload the patch.
Trying again with this message, if it fails again, will resubmit by e-
mail.
__
Tracker <[EMAIL PROTECTED]>
<http://
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 12:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
..
> I don't much like this aspect of the change: there are uses for
>
> for i in range(ridiculously_large_number):
For this app
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Option (3) would require changing both sq_item and sq_length signatures,
which is likely to have a large negative impact on performance.
Option (2) would either require a change for the sq_length signature, or
leave the prob
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 4:37 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
..
> for i in range(1, p):
> if (i_is_a_nonresidue_modulo_p):
> break
>
> Here p might be a 200-digit prime number, and
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 4:37 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> I don't really see what's wrong with the indentation.
Sorry, I thought it would be obvious from the patch. As of revision
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 5:31 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Comments?
In the range_hash function, len, start, step locals should be declared
Py_ssize_t, not long. Also, you can use range_leng
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
It looks like e-mail processor eats '>>>' examples. My examples were
>>> range(2**100) == range(2**100+1)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 5:57 PM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
..
> - Did you change your mind about range equality?
> range(0,10,2) == range(0,9,2)
> seems True now; it was not with ran
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 7:10 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
..
> I think I'd be okay with normalization on creation, so that range(0,
> 5, 2) returns range(0, 6, 2). Hm, but isn't that o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
With respect to range_eq8_normalize2.patch, it is unusual to have a
function that consumes a reference to its argument. I would combine
normalize_stop with PyNumber_Index and make it similar to validate_step
with resp
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
... and your patch produces wrong results:
>>> list(range(5,0,-2)) # expected [5, 3, 1]
[5, 3]
See my patch in issue2690 for a way to compute length correctly in
range_new.
__
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The patch looks good. Just a question: I thought the strings returned by
PyUnicode_AsStringAndSize are 0-terminated, while your patch at several
places attempts to explicitly 0-terminate a copy of such string. Are you
sure t
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I've implemented range slicing and x in range(..) in range-sequence.diff
and registered range with the Sequence ABC.
Added file: http://bugs.python.org/file10131/range-sequence.diff
__
Trac
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Reviewing my own patch (range-sequence.diff), I've realized that it is
being a bit too clever in handling x in range(..) where x is not an
integer. It seems that upon a failed PyLong_Check, range_contains should
just
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
> For me, range() should mimic a number generator: no limit, no length.
That's itertools.count()
__
Tracker <[EMAIL PROTECTED]>
<http://bu
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
..
> Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
> the result doesn't fit in a Py_ssize_t.
http
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
type: -> feature request
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2723>
__
___
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 2:32 AM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> Wouldn't it be better to raise OverflowError or somesuch?
Thats what the current code does. I don't know what Guido's full
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I thought new code is supposed to use Py_TYPE macro instead of ->ob_type:
+ "%.200s object is not an iterator", it->ob_type-
>tp_name);
..
+ res = (*it->ob_type->tp_iternext)
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
One more question: What is the rationale for
+ res = (*it->ob_type->tp_iternext)(it);
+ if (res == NULL) {
..
+ PyErr_SetNone(PyExc_StopIteration);
+ return NULL;
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> > .. builtin_next() should return
> > NULL with
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> the iternext slot is designed to return NULL without setting an
> exception.
This is not what the documentation says:
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
See discussion in issue2719 for details.
--
assignee: georg.brandl
components: Documentation
files: doc-typeobj.diff
keywords: patch
messages: 66016
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: c
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The start/step/stop getter functions should INCREF return values. Is
there a reason not to adapt slice implementation:
static PyMemberDef slice_members[] = {
{"start", T_OBJECT, offsetof(PySliceObject,
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
- With length precomputed in range_new, we can probably get rid of
get_len_of_range.
- There is no need to recompute length in range_iter.
A nit: iterator object's size member is called "len", but the same
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
One more nit: you don't need to zero out trailing range_as_sequence
members explicitly.
static PySequenceMethods range_as_sequence = {
(lenfunc)range_length, /* sq_length */
};
shoul
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Lorenz's patch uses a set, not a list for special characters. Set
lookup is as fast as dict lookup, but a set takes less memory because it
does not have to store dummy values. More importantly, use of frozenset
inst
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, May 8, 2008 at 10:36 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
> The title of this issue (#2650) is "re.escape should not escape underscore",
> not "re.escape is too slow and too easy to rea
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, May 8, 2008 at 11:45 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
> My argument is only that Python should behave the same in
> this respect as other systems that use substantially the same
> regular expres
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is similar to issue2516.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch makes a >> b return 0 for b > maxsize.
--
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file10234/issue2804.diff
__
Tracker <[EMAIL
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the second thought, it is theoretically possible to have a long int a
for which a >> maxsize is not zero because that would require only
maxsize/15 digits. I am not sure it is worth the trouble to acco
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, May 9, 2008 at 7:08 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
..
> I'm -1 on this patch (or any other fixing the perceived problem).
> Special cases aren't special enough to break the rules.
&g
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, May 11, 2008 at 6:38 PM, Gregory P. Smith
<[EMAIL PROTECTED]> wrote:
..
> But I must've missed something, why can't __len__ return the correct
> value?
The problem is the C signature of the sq_leng
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
With attached teestmodule.zip and svn revision 67006,
$ ./python.exe testmodule.zip
Traceback (most recent call last):
File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 121, in
_run_module_as_main
&
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch addresses the crash, but two issues remain:
$ ./python.exe testmodule.zip
**
File "__main__", line ?, in __main__.c
Failed exam
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file11878/doctest.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The next patch, doctest-1.patch addresses the line number issue, but the
file name is still wrong.
$ ./python.exe testmodule.zip
**
File "__main__&q
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I don't think there is an easy way to fix source file name reporting
without injecting __file__ = '/' into the
module namespace is zipimporter, but I don't know if any code relies on
__file__ set to None.
S
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
With attached test.zip and svn revision 67006,
$ ./python.exe test.zip
> /Users/sasha/Work/python-svn/trunk/test.zip/__main__.py(2)f()
(Pdb) l
[EOF]
With pdb.patch:
$ ./python.exe test.zip
> /Users/sasha/Work/pyth
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file11883/pdb.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
components: +Library (Lib)
type: -> behavior
versions: +Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3, Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This must be very similar to #4197 and #4201 that I reported a few days
ago. I'll see if a similar patch would work in this case.
--
nosy: +belopolsky
___
Python tracker <[E
1401 - 1500 of 3596 matches
Mail list logo
