Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This seems to have something to do with the current locale.
On OS X 10.4.11/PPC I have:
$ echo $LANG
C
and the test fails. On OS X 10.5.5:
$ echo $LANG
en_GB.UTF-8
and test_cmd_line.py passes. Moreover, after doing:
$ export
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a minimal failing example, which I believe captures the cause of
the test_cmd_line failure. After "export LANG=C", on OS X 10.5, I get:
Python 3.0rc3+ (py3k:67335, Nov 22 2008, 09:11:58)
[GCC 4.0.1 (Apple
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm not competent enough in this area to judge how serious this bug is, or
determine what to do about it, but it seems as though it might potentially
be a release blocker.
Martin, would you be able to take a look?
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It looks like your conjectures are right in both cases.
I tried adding a few lines to Modules/python.c to print out the argv
entries as byte strings, before they're passed to mbstowcs. Results
on OS X 10.5:
> 1. Someb
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
This patch fixes 3 classes of bugs in Objects/longobject.c:
(1) declarations of a variable (usually a counter into the digits of
a PyLong) as int instead of Py_ssize_t.
(2) missing (twodigits) casts from multiplies and shifts.
(3)
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Updated patch: fix overflow checks to use offsetof instead of sizeof as
well.
Added file: http://bugs.python.org/file12141/string_alloc.patch
___
Python tracker <[EMAIL PROTECTE
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12140/string_alloc.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
There are a number of places in Objects/stringobject.c where memory is
allocated for a string of length n using:
PyObject_MALLOC(sizeof(PyStringObject) + n)
On my computer (OS X 10.5.5/Intel), and, I suspect, on most common
pla
New submission from Mark Florisson <[EMAIL PROTECTED]>:
The docstring of os.setpgrp says 'Make this process a session leader.',
but that's not what setpgrp does. setpgrp() is the same as setpgid(0,
0), which sets the pgid of the calling process to the pid of the calling
proc
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Yep. That works nicely.
Here's a revised patch.
Added file: http://bugs.python.org/file12148/string_alloc.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12141/string_alloc.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The +1 is there for the trailing null byte on the string: if s is a
Python string with len(s) == n, then the ob_sval array needs space for n+1
characters.
___
Python tracker <[EMAIL PROTECTE
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12148/string_alloc.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Hmmm. test_sys fails on 64-bit build.
Patch updated to fix this.
All tests now pass on 32-bit and 64-bit, debug and non-debug builds.
Added file: http://bugs.python.org/file12149/string_alloc
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm confused. I'm probably missing something, but why do you think such a
check is necessary? The code I'm seeing at around line 2766 is:
static Py_ssize_t
match_getindex(MatchObject* self, PyObject* index)
{
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I believe the code is correct as it is. The relevant lines are in
set_intersection:
if ((PyObject *)so == other)
return set_copy(so);
If the result of the set_copy is NULL then the NULL is passed directly
b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> abstract.c(PyNumber_AsSsize_t) shows this check of PyInt_AsSsize_t()'s
> parameter:
Yup. And that's because 'value' is the return value from
PyNumber_Index. PyNumber_Index might return NULL, so the check
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See explanation for issue 4465.
--
nosy: +marketdickinson
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See explanation for issue 4466.
It seems to me that you have some misunderstandings about the way that
Python works. Please could you refrain from introducing new issues here
unless you're sure that they really *are* issues.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Patch looks fine. (!)
Okay just to apply this to 2.6 and up? It's not a bugfix.
--
versions: -Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
So the obvious quick fix is, on OS X only, to set the locale to e.g.
"en_US.UTF-8" instead of "" just before the mbstowcs call.
Here's a patch that does this.
I don't like this much, though. For on
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm now very confused.
In trying to follow things of type wchar_t* around the Python source, I
discovered PyUnicode_FromWideChar in unicodebject.c. For OS X, the
conversion lands in the following code, where w is the incomi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> conversion from UTF-32 to UCS-2 here
That 'UCS-2' should be 'UTF-16', of course.
___
Python tracker <[EMAIL PROTECTED]>
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
On systems (Linux, OS X) where sizeof(wchar_t) is 4 and wchar_t arrays are
usually encoded as UTF-32, it looks as though PyUnicode_FromWideChar
simply truncates the 32-bit characters to 16-bits, thus giving incorrect
resul
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> it's very likely that
> the problem hasn't occurred in practice (and I doubt it would occur
> in 3.0 if not fixed - there are more severe problems around).
Okay. So it's an issue, but not a blocker. Opene
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Comments from MvL in issue 4388:
> I think you are right. However, conversion to/from wchar_t is/was
> rarely used, and so are non-BMP characters; it's very likely that
> the problem hasn't occurred in practice (a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> it is fine on linux
Interesting. Which version of Python is that? And is PyUNICODE 2 bytes
or 4 bytes for that build of Python?
___
Python tracker <[EMAIL PROTECTED]>
<http
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Just to be clear, the defect in PyUnicode_FromWideChar is present both in
Python 2.x and Python 3.x.
The problem with command-line arguments only occurs in Python 3.x, since
2.x doesn't use PyUnicode_FromWideChar in convertin
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Having different result types based on the input
> values would not be "smart" in my book, rather "incredibly fragile".
Well, there are precedents:
>>> type(2**3)
>>> type(2**-3)
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is on Windows, right? I don't know of any other platforms where
__int64 is defined.
At a first glance, it looks as though the code's correct, so we probably
just need to add some casts to silence the compiler. I&#x
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 2.7, Python 3.1
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See also issue 4497 for some compiler warnings that need to be silenced.
--
assignee: -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I think you brought up the math and cmath errors before, and I never
managed to get to the bottom of the problem. I'll have another go.
I don't think the (c)math test failures should be regarded as terribly
serious, though
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> (1.5802653829857376e+307+inf*j)
Those values look right; except that there's some code near the end of
the cexp function that's supposed to set errno to ERANGE if either the
real or imaginary component of the resu
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4506>
___
___
Python-bugs-list mailing list
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
keywords: +64bit -patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4506>
___
_
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4506>
___
___
Python-bugs-list mailing list
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4506>
___
___
Python-bugs-list mailing list
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This looks like a duplicate of issue 4388.
--
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4506>
___
___
Python-bugs-list mailing list
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Tracker issue: I don't seem to be able to remove the 'patch' keyword
without (accidentally) ending up with something else---in this case the
64bit keyword. Is this just me being incompetent, or should
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Raymond, could you please try the attached patch to see if it silences the
compiler?
--
keywords: +patch
Added file: http://bugs.python.org/file12212/issue4497.patch
___
Python tracker &
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Just a quick note to say I am still working on this. I'll post some new
code soon.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the assembly code---you're running Solaris on x86! Why
didn't you say so before? :)
I think I have an idea what's going on: it's the old extended-precision
versus double-precision problem. The calcu
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I'm failry sure I can find a SPARC here to run it on as well. They
> are rather few and far between though.
I don't think that's necessary. Thanks for disabusing me of my 'Solaris
implies SPARC'
Mark Tolonen <[EMAIL PROTECTED]> added the comment:
An extension to this idea: Support parsing #! lines in Windows and
select the version of Python used. python.exe could examine:
#!/usr/bin/python30
pattern match "python##", look in the registry to see if that versi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in r67588 (py3k), r65789 (release30-maint).
None of the fixes apply to 2.x.
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.6, Python 2.7
___
Python tra
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> r65789
That should be r67589.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4497>
___
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing as duplicate.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
All tests pass with this patch.
Committed to trunk, r67590. Will merge to 2.7, 3.0 and 3.1.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
versions: -Python 2.6, Python 2.7
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Merged.
Thanks for the report, Brian.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I agree that this probably isn't right for core Python. But I think this
is valuable work, and it would be nice to see this patch available and
maintained somewhere, if anyone has the energy.
I'm wondering whether the Sag
Mark Tolonen <[EMAIL PROTECTED]> added the comment:
I see it as primarily useful in this transition period between 2.x and
3.0, since py3 scripts aren't backward compatible and I see both being
installed for the few years. It could be a front-end launcher
suitable for "f
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing as invalid.
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There have been requests to add other C99 libm functions to Python:
expm1 is requested in issue 3501, and log2 came up in the issue 3724
discussion. I'm absorbing those issues into this one.
With these two, and the gamm
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm absorbing this issue into issue 3366.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Add gamma function, error functions and other C99 math.h
func
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm closing this, for reasons already given.
For the proposal to add log2, see issue 3366.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
priority: -> high
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2110>
___
___
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Applied to the trunk in r67601. Will merge to other branches if the
buildbots look okay.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3439>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Applied to py3k in r67610.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The segfault is a little worrying; I don't understand that at all.
Skip, can you come up with a configure patch that would allow isinf to be
detected on Solaris?
I'll also patch Py_IS_INFINITY to make sure that it for
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Skip, Jean:
Could you try the attached patch to see if it fixes the math.log and
math.log10 test failures. (The patch is generated against the trunk, but
should apply cleanly to py3k or either of the 2.6 or 3.0 maintenance
br
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Damien, if you're still there:
Please could you try the patch "math_log.patch" attached to issue 3167,
and let me know whether it fixes the test failure?
___
Python tracker <
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
versions: +Python 3.1
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4084>
___
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
+1 for a speedy removal of cmp and tp_compare
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In issue 4506, Skip reported that test_cmath fails on Solaris 10/x86 for
3.0. If my guesses are correct, it probably fails on all x86 systems that
(a) use the x87 coprocessor for floating-point (as opposed to using SSE2,
for e
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Skip. It looks like the top priority is fixing Py_IS_INFINITY,
then (still assuming that I'm not barking up entirely the wrong tree).
I've opened issue 4575 for the Py_IS_INFINITY fix.
I'll look at the chan
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'll work on fixing the unit tests if that's helpful.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Decimal fixes
Added file: http://bugs.python.org/file12265/remove_cmp_decimal.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Florisson <[EMAIL PROTECTED]>:
>>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w')
>>> f.read()
''
>>> f.readline()
Traceback (most recent call last):
File "", lin
Mark Florisson <[EMAIL PROTECTED]> added the comment:
Actually, I wouldn't expect it to fail like that, because it's not a bad
file descriptor, it's an actual that doesn't agree with the (userspace)
file mode. What I'd expect is probably a TypeError. Although an IO
Mark Florisson <[EMAIL PROTECTED]> added the comment:
s/actual/operation/
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4579>
___
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
remove_cmp3.patch adds to Christian's patch to fix 6 more test_failures:
(test_distutils, test_kqueue, test_list, test_sort, test_sqlite,
test_userlist).
On OS X, the only remaining test failure is test_unittest.py.
Added
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
About unittest:
unittest.TestLoader has an attribute "sortTestMethodsUsing", which it
expects to be an old-style comparison.
Should this attribute be updated (and renamed?) to expect a key function
instea
Mark Florisson <[EMAIL PROTECTED]> added the comment:
Perhaps it's linux specific then. I'm on debian lenny (2.6.26-1-amd64).
___
Python tracker <[EMAIL PROTECTED]>
<http://
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
There are two recent reports of build failures of Python 3.0 on OS X
10.5.5: see
http://mail.python.org/pipermail/python-list/2008-November/514159.html
and
http://mail.python.org/pipermail/python-3000/2008-December/015404.html
It
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Update patch to include fix for unittest.py and test_unittest.py.
Added file: http://bugs.python.org/file12278/remove_cmp5.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the information, nelis!
This appears to be a duplicate of issue 2173. Further analysis should go
there.
--
resolution: -> duplicate
status: open -> closed
___
Python tra
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See issue 4585, which appears to be the same problem.
--
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I think I've traced the 'no output' problem back to the device_encoding
function in Modules/posixmodule.c. The problem occurs when this function
is called to try to get the encoding for stdout.
On my machine, if I
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
nosy: +nelis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2173>
___
___
Python
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Could someone please try the attached patch and see if it solves the
problem.
I'm not sure whether Facundo's problem is the same issue or not.
--
keywords: +patch
versions: +Python 3.1
Added file: http://bugs.pyth
Mark Mentovai <[EMAIL PROTECTED]> added the comment:
This is not limited to Windows. I experience this bug on Mac OS X and
Linux as well.
http://mail.python.org/pipermail/python-list/2008-August/505753.html
Attachment 3210.py is a reduced testcase. It attempts to execute nocmd,
which
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> It is in the builtins in Python 2.x, so keeping it there would make
> porting easier, but then it's probably better to put it somewhere else
> to make people aware of the fact that the underlying machinery has
>
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
More seriously, if cmp were to go into the standard library somewhere,
perhaps Raymond's class decorator (for filling in missing rich
comparisons) could go into the same place?
___
Python trac
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Victor, what does
>>> 1e16 + 2.
give on your Ubuntu 2.5 machine?
(Humor me. :) )
___
Python tracker <[EMAIL PROTECTED]>
<http://b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Intel uses 80 bits float in internals, but load/store uses 64 bits
> float. Load/store looses least significant bits.
Exactly. If your Intel machine is Pentium 4 or newer, you can get
around this by using the SSE2 extensions
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Alexander]
> The flags you may be looking for are -msse2 -mfpmath=sse
Thanks, Alexander!
[Alexander again, from an earlier post...]
> I noticed that you replaced a call to _PyLong_AsScaledDouble with your
> round to neares
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Alexander]
> I also wonder whether round to nearest float can be implemented
without
> floating point arithmetics. I would think round towards zero should
be
> a simple matter of extracting an appropriate number of bits
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
As you say, performance would suffer.
What would using Python's integer type solve, that isn't already solved by
the patch?
I know the code isn't terribly readable; I'll add some comments
explaini
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
By the way, the algorithm here is essentially the same as the algorithm that I
implemented for the float.fromhex method, except that the float.fromhex method
is more
complicated in that it may have to deal with signed zeros or subn
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> floating-point variable "x" has an exact nonnegative integer value
> between 0 and 2**DBL_MANT_DIG.
Hmm. On closer inspection that's not quite true. After the line
x = x * PyLong_BASE + (dig & (PyLong_BA
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for your comments, Alexander.
Here's a rewritten version of the patch that's better commented and
somewhat less convoluted; I think it should be easier to verify the
correctness of this one.
Added file: http:/
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Minor cleanup of long_as_double2.patch.
Added file: http://bugs.python.org/file12320/long_as_double2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12312/long_as_double2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
IDLE's cursor blinks with Python 3.0 on Linux.
But it shouldn't (and doesn't for prior versions) because in my
.Xdefaults file I have the line:
*insertOffTime: 0
Now I have to manually edit idlelib/EditorWindow.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Committed, r67699. Thanks!
Leaving open because I still need to merge this to the 3.0 and 2.6
maintenance branches.
--
priority: release blocker -> normal
versions: +Python 2.6, Python 3.0 -Pyt
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Merged to 2.6 and 3.0 maintenance branches (r67700, r67701).
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
2501 - 2600 of 12223 matches
Mail list logo
