[issue3563] fix_idioms.py generates bad code

[Ali Polatel]

New submission from Ali Polatel <[EMAIL PROTECTED]>:

fix_idioms.py generates bad code for conversions in try/except blocks.
Example:
s=(1, 2, 3)
try:
t = list(s)
t.sort()
except TypeError:
pass

fix_idioms.py generates this diff:
--- test.py (original)
+++ test.py (refactored)
@@ -7,8 +7,7 @@
 
 s=(1, 2, 3)
 try:
-t = list(s)
-t.sort()
-except TypeError:
+t = sorted(s)
+except TypeError:
 pass
 
except TypeError is indented wrongly.

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71199
nosy: collinwinter, hawking
severity: normal
status: open
title: fix_idioms.py generates bad code

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3564] making partial functions comparable

[Erick Tryzelaar]

New submission from Erick Tryzelaar <[EMAIL PROTECTED]>:

functools.partial functions are not comparable, in both python 2.5 and 
3.0:

>>> def foo(): pass
>>> functools.partial(foo) == functools.partial(foo)
False

It can be worked around by comparing the func, args, and keywords, but 
this means that if a partial function is stored in some structure, such 
as:

>>> def foo(): pass
>>> f1=functools.partial(foo)
>>> f2=functools.partial(foo)
>>> (1,'a',f1) == (1,'a',f2)
False

Which complicates things when I'm comparing things in a function that 
works with generic data structures. Would it be possible to extend 
partial to support comparisons?

--
components: Library (Lib)
messages: 71200
nosy: erickt
severity: normal
status: open
title: making partial functions comparable
type: feature request
versions: Python 2.5, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3565] array documentation, method names not 3.0 compliant

[Matt Giuca]

New submission from Matt Giuca <[EMAIL PROTECTED]>:

A few weeks ago I fixed the struct module's documentation which wasn't
3.0 compliant (basically renaming "strings" to "bytes" and "unicode" to
"string"). Now I've had a look at the array module, and it's got similar
problems.

http://docs.python.org/dev/3.0/library/array.html

Unfortunately, the method names are wrong as far as Py3K is concerned.
"tostring" returns what is now called a "bytes", and "tounicode" returns
what is now called a "string".

There are a few other errors in the documentation too, like the 'c' type
code (which no longer exists, but is still documented), and examples
using Python 2 syntax. Those are trivial to fix.

I suggest a 3-step process for fixing this:
1. Update the documentation to describe the 3.0 behaviour using 3.0
terminology, even though the method names are wrong (I've done this
already).
2. Rename "tostring" and "fromstring" methods to "tobytes" and
"frombytes". I think this is quite important as the value being returned
can no longer be described as a "string".
3. Rename "tounicode" and "fromunicode" methods to "tostring" and
"fromstring". I think this is less important, as the name "unicode"
isn't ambiguous, and potentially undesirable, as we'd be re-using method
names which previously did something else.

I'm aware we've got the final beta in 4 days, and there's no way my
phase 2-3 can be done after that. I think we should aim to do phase 2,
but probably not phase 3.

I've fixed the documentation to accurately describe the current
behaviour, using Python 3 terminology. This doesn't change any behaviour
at all, so it should be able to be committed immediately.

I'll have a go at a "phase 2" patch shortly. Is it feasible to even
think about renaming a method at this stage?

Commit log:

Doc/library/array.rst, Modules/arrayobject.c:

Updated array module documentation to be Python 3.0 compliant.

* Removed references to 'c' type code (no longer valid).
* References to "string" changed to "bytes".
* References to "unicode" changed to "string".
* Updated examples to use Python 3.0 syntax (and show the output of
evaluating them).

--
assignee: georg.brandl
components: Documentation, Interpreter Core
files: doc-only.patch
keywords: patch
messages: 71201
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: array documentation, method names not 3.0 compliant
versions: Python 3.0
Added file: http://bugs.python.org/file11121/doc-only.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

=?utf-8?q?[issue3565]_array_documentation, =09method_names_not_3.0_compliant?=

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> 2. Rename "tostring" and "fromstring" methods to "tobytes" and
> "frombytes". I think this is quite important as the value being returned
> can no longer be described as a "string".

I'm not a native speaker (of English), but my understanding is that the
noun "string", in itself, can very well be used to describe this type:
the result is a "byte string", as opposed to a "character string".
Merriam-Webster's seems to agree; meaning 5b(2) is "a sequence of like
items (as bits, characters, or words)"

--
nosy: +loewis
title: array documentation, method names not 3.0 compliant -> array 
documentation,  method names not 3.0 compliant

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

=?utf-8?q?[issue3565]_array_documentation, =09method_names_not_3.0_compliant?=

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

> I'm not a native speaker (of English), but my understanding is that the
> noun "string", in itself, can very well be used to describe this type:
> the result is a "byte string", as opposed to a "character string".
> Merriam-Webster's seems to agree; meaning 5b(2) is "a sequence of like
> items (as bits, characters, or words)"

Ah yes, that's quite right (and computer science literature will
strongly support that claim as well).

However the word "string", unqualified, and in Python 3.0 terminology
(as described in PEP 358) now refers only to the "str" type (formerly
known as "unicode"), so it is very confusing to have a method "tostring"
which returns a bytes object.

For array to become a good Py3k citizen, I'd strongly argue that
tostring/fromstring should be renamed to tobytes/frombytes. I'm
currently writing a patch for that - it looks like there's very minimal
damage.

However as a separate issue, I think the documentation update should be
approved first.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3565] array documentation, method names not 3.0 compliant

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

(Fixed issue title)

--
title: array documentation, method names not 3.0 compliant -> array 
documentation, method names not 3.0 compliant

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3565] array documentation, method names not 3.0 compliant

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

I renamed tostring/fromstring to tobytes/frombytes in the array module,
as described above. I then grepped the entire py3k tree for "tostring"
and "fromstring", and carefully replaced all references which pertain to
array objects.

The relatively minor number of these references suggests this won't be a
big problem. All the test cases pass.

I haven't (yet) renamed tounicode/fromunicode to tostring/fromstring.
The more I think about it, the more that sounds like a bad idea (and
could create confusion as to whether this is a character string or byte
string, as Martin pointed out).

The patch (doc+bytesmethods.patch) does both the original
doc-only.patch, plus the renaming and updating of all usages. Use the
above commit log, plus:

Renamed array.tostring to array.tobytes, and array.fromstring to
array.frombytes, to reflect the Python 3.0 terminology.

Updated all references to these methods in Lib to the new names.

Added file: http://bugs.python.org/file11122/doc+bytesmethods.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3565] array documentation, method names not 3.0 compliant

[Matt Giuca]

Changes by Matt Giuca <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11122/doc+bytesmethods.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3565] array documentation, method names not 3.0 compliant

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

Oops .. forgot to update the array.rst docs with the new method names.
Replaced doc+bytesmethods.patch with a fixed version.

Added file: http://bugs.python.org/file11123/doc+bytesmethods.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2676] email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Hi Jack,

> Antoine, I looked at your patch and I'm not sure why you applied it
> instead of applying mine (or saying +1 on me applying my patch).
> 
> Yours uses str.partition which I pointed out is sub-optimal (same big-Oh
> but with a larger constant factor) and also adds a function that returns
> two things, one of which is thrown away after having a str.strip
> performed on it.

I added that function so that the header splitting facility is
explicitly exposed as an internal API, as was the case with the regular
expression. I tried to mimick the behaviour of the regex as closely as
possible, which meant returning two things as well :-)

I think the point of the issue is to remove the pathological
(exponential) behaviour when parsing some headers, not to try to squeeze
out the last microseconds out of content-type parsing (which shouldn't
be, IMO, the limiting factor in email handling performance as soon as
it's not super-linear).

That said, I've timed the function against the regular expression and
the former is always faster, even for tiny strings (e.g. "a;b").

Your patch was keeping the regular expression as a module-level constant
while replacing all uses of it with a function, which I found a bit
strange (I don't think people are using paramre from the outside since
it's not documented, it's an internal not public API IMO). I also found
it strange to devote a docstring to the discussion of a performance
detail. But I don't have any strong feeling against it either, so you
can still apply it if you think it's important performance-wise.

Regards

Antoine.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3564] making partial functions comparable

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

It's highly debatable whether these should compare true. (Note: saying
"they aren't comparable" is a misnomer -- they are comparable, they just
don't compare equal).

>From a mathematical standpoint, they *are* equal, but it's impossible
(undecidable) to get pure equality of higher order values (functions) in
a programming language (because strictly, any two functions which give
the same results for the same input are equal, but it's undecidable
whether any two functions will give the same results for all inputs). So
we have to be conservative (false negatives, but no false positives).

In other words, should these compare equal?

>>> (lambda x: x + 1) == (lambda x: x + 1)
False (even though technically they describe the same function)

I would argue that if you call functools.partial twice, separately, then
you are creating two function objects which are not equal.

I would also argue that functools.partial(f, arg1, ..., argn) should be
equivalent to lambda *rest: f(arg1, ..., argn, *rest). Hence your example:
>>> def foo(): pass
>>> f1=functools.partial(foo)
>>> f2=functools.partial(foo)

Is basically equivalent to doing this:

>>> def foo(): pass
>>> f1 = lambda: foo()
>>> f2 = lambda: foo()

Now f1 and f2 are not equal, because they are two separately defined
functions.

I think you should raise this on Python-ideas, instead of as a bug report:
http://mail.python.org/pipermail/python-ideas/

But with two identical functions comparing INEQUAL if they were created
separately, I see no reason for partial functions to behave differently.

--
nosy: +mgiuca

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3530] ast.NodeTransformer bug

[Armin Ronacher]

Armin Ronacher <[EMAIL PROTECTED]> added the comment:

This is actually not a bug.  copy_location does not work recursively. 
For this example it's more useful to use the "fix_missing_locations"
function which traverses the tree and copies the locations from the
parent node to the child nodes:

import ast
a = ast.parse('foo', mode='eval')
x = compile(a, '', mode='eval')

class RewriteName(ast.NodeTransformer):
def visit_Name(self, node):
return ast.Subscript(
value=ast.Name(id='data', ctx=ast.Load()),
slice=ast.Index(value=ast.Str(s=node.id)),
ctx=node.ctx
)

a2 = ast.fix_missing_locations(RewriteName().visit(a))

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2310] Reorganize the 3.0 Misc/NEWS file

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I'm a little confused on what needs to happen here. It's "incomplete"
because it gets skipped in merges, but "2.6 ports don't need to be in 3.0".

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3542] Building an MSI installer crashes

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Thanks for the report. This is now fixed in r65709.

The right approach is to use the MS "wide string" API whereever
possible, e.g. invoke MsiSummarySetPropertyInfoW (instead of
MsiSummarySetPropertyInfo, as that defaults to MsiSummarySetPropertyInfoA).

If you ever find that you need to encode a Unicode string to a byte
string so that some "ANSI" API can accept it, use the "mbcs" encoding.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3542] Building an MSI installer crashes

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3055] test_list on 64-bit platforms

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Apparently this has been fixed as part of r65335 ("Security patches from
Apple:  prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3107] test_list uses unreasonable amounts of memory on 64-bit Linux

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Apparently this has been fixed as part of r65335 ("Security patches from
Apple:  prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue600362] relocate cgi.parse_qs() into urlparse

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

This is ok, maybe with some small changes in the docs.

I asked in python-dev if this should go now or wait until 2.7/3.1

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2776] urllib2.urlopen() gets confused with path with // in it

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Commited in revs 65710 and 65711.

Thank you all!!

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2776] urllib2.urlopen() gets confused with path with // in it

[Facundo Batista]

Changes by Facundo Batista <[EMAIL PROTECTED]>:


--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I wonder if it might be most effective to make a _testcapi interface to
PyErr_NoMemory.

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3563] fix_idioms.py generates bad code

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

It's due to these lines in fix_idioms:

if next_stmt:
 next_stmt[0].set_prefix(sort_stmt.get_prefix())

I'm not sure what the correct way to deal with this is. Anyway I'm
attaching a test case.

--
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file11124/indentation_test.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> I wonder if it might be most effective to make a _testcapi interface to
> PyErr_NoMemory.

How would that work in this case? (I actually don't know what the test
purpose of this test is.)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

You're right; this test would be pointless with that. However, I'm
looking at test_exceptions' test_MemoryError that is failing for me
because it gives a OverflowError instead of a MemoryError.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3131] 2to3 can't find fixes_dir

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3131] 2to3 can't find fixes_dir

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

I reported the same bug with another patch: #3553. I used __import__ 
and module.__file__ attribute (and not realpath).

--
nosy: +haypo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

[C. Scott Ananian]

New submission from C. Scott Ananian <[EMAIL PROTECTED]>:

Although HTTP/1.1 says that servers SHOULD send a Connection: close
header if they intend to close a persistent connection (sec 8.1.2.1),
clients (like httplib) "MUST be able to recover from asynchronous close
events. Client software SHOULD reopen the transport connection and
retransmit the aborted sequence of requests without user interaction so
long as the request sequence is idempotent" (sec 8.1.4) since servers
MAY close a persistent connection after a request due to a timeout or
other reason.  Further, "Clients and servers SHOULD both constantly
watch for the other side of the transport close, and respond to it as
appropriate." (sec 8.1.4).

httplib currently does not detect when the server closes its side of the
connection, until the following bit of HTTPResponse in httplib.py
(python2.5.2):

def _read_status(self):
# Initialize with Simple-Response defaults
line = self.fp.readline()
...
if not line:
# Presumably, the server closed the connection before
# sending a valid response.
raise BadStatusLine(line)
...

So we end up raising a BadStatusLine exception for a completely
permissible case: the server closed a persistent connection.  This
causes persistent connections to fail for users of httplib in mysterious
ways, especially if they are behind proxies: Squid, for example, seems
to limit persistent connections to a maximum of 3 requests, and then
closes the connection, causing future requests to raise the BadStatusLine.

There appears to be code attempting to fix this problem in
HTTPConnection.request(), but it doesn't always work.  RFC793 says, "If
an unsolicited FIN arrives from the network, the receiving TCP can ACK
it and tell the user that the connection is closing.  The user will
respond with a CLOSE, upon which the TCP can send a FIN to the other TCP
after sending any remaining data." (sec 3.5 case 2)  Key phrase here is
"after sending any remaining data": python is usually allowed to put the
request on the network without raising a socket.error; the close is not
signaled to python until HTTPResponse.begin() invokes
HTTPResponse._read_status.

It would be best to extend the retry logic in request() to cover this
case as well (store away the previous parameters to request() and if
_read_status() fails invoke HTTPConnection.close(),
HTTPConnection.connect(), HTTPConnection.request(stored_params), and
retry the HTTPConnection.getresponse().  But at the very least python
should document and raise a EAGAIN exception of some kind so that the
caller can distinguish this case from an actual bad status line and
retry the request.

--
components: Library (Lib)
messages: 71221
nosy: cananian
severity: normal
status: open
title: httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2310] Reorganize the 3.0 Misc/NEWS file

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I worry that many things were not recoded in Misc/NEWS at all,
especially in the early days of 3.0 development (e.g. in the p3yk branch
:-).

I'm not sure if it's possible to fix this retroactively, however.  As
long as we keep the changes between the betas complete, and as long as
somebody updates the "what's new" document (I have volunteered for that
though I'm not sure I'll get to it :-( ) I'm okay.

So let's close this.  We don't need more busy-work.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Let's lower the priority a little then.

--
nosy: +benjamin.peterson
priority: release blocker -> critical

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3424] imghdr test order makes it slow

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Done in r65713.

--
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3530] ast.NodeTransformer bug

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3564] making partial functions comparable

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

I would add that making the comparison "right" for partial would be
trickier than it seems:

>>> from functools import partial
>>> type == type
True
>>> 1 == 1.0
True
>>> partial(type, 1)() == partial(type, 1.0)()
False

If partial(type, 1) and partial(type, 1.0) were to compare equal, it
would break the expectation, stated by Matt, that two equal function
objects produce the same results when given the same inputs.


PS: 
>>> partial(type, 1)()

>>> partial(type, 1.0)()


--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Can you test with that patch?

--
components: +Tests
keywords: +patch
nosy: +pitrou
type:  -> resource usage
Added file: http://bugs.python.org/file11125/memerror.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2756] urllib2 add_header fails with existing unredirected_header

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

What I think is that the AbstractHTTPHandler is grabbing the headers, in
the do_open() method, in an incorrect way.

Check the get_header() method from Request:

def get_header(self, header_name, default=None):
return self.headers.get(
header_name,
self.unredirected_hdrs.get(header_name, default))

What it's doing there is to grab the header from self.header, and if not
there use the one in self.unredirected_hdrs, and if not there return the
default.

So, to emulate this behaviour, in do_open() I just grabbed first the
unredirected headers, and then updated it with the normal ones.

See my simple patch I attach here, which solves the issue, and passes
all the tests also.

Added file: http://bugs.python.org/file11126/issue2756-facundo.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Antoine, it works great, both in 2.6 and in 3.0 (with the obvious small
modification).

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3567] test_ossaudiodev fails when run with -bb

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

I suppose the sunau module hasn't received a lot ot love lately :-)

test test_ossaudiodev failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
146, in test_playback
sound_info = read_sound_file(findfile('audiotest.au'))
  File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
27, in read_sound_file
au = sunau.open(fp)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 469, in open
return Au_read(f)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 158, in __init__
self.initfp(f)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 167, in initfp
magic = int(_read_u32(file))
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 138, in _read_u32
if byte == '':
BytesWarning: Comparison between bytes and string

--
components: Library (Lib)
messages: 71229
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_ossaudiodev fails when run with -bb
type: behavior
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3568] list enumeration corrupt when remove()

[Jacek]

New submission from Jacek <[EMAIL PROTECTED]>:

Hi

I wrote my first program in python, and I found bug in it.
I explain it in example (I do it under Windows XP):

1. At the begining create some directories:
>mkdir .\test\
>mkdir .\test\.svn
>mkdir .\test\cvs
>mkdir .\test\pdk

2. Next create file ".\bug.py" with content:
import re
import os

print 'example1:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk(r'.\\test\\'):
   ldirIndex = 0
   for ldirName in ldirs:
  if lpatternDirSkip.search(ldirName):
 ldirs.remove(ldirName)
   print ldirs

print 'example2:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk('.\\test\\'):
   ldirIndex = 0
   while ldirIndex < len(ldirs):
  if lpatternDirSkip.search(ldirs[ldirIndex]):
 ldirs.remove(ldirs[ldirIndex])
 ldirIndex -= 1
  ldirIndex += 1
   print ldirs

3. Next run cmd.exe (in the same directory) and type "bug.py". Result is:
example1:
['cvs', 'pdk']
[]
[]
example2:
['pdk']
[]

5. Comment:
In this example I want to remove from list of directories (ldirs) every
hiden directories (like ".svn") and directory "CVS". 
Example1 is the comfortable way, but it products wrong result (the "cvs"
directory is not remove). This is only happen when I remove some
directories from the list. I don't care that there was deleted one
element from the list. It should be special case, and enumeration on the
rest elements should be correct.
Example2 works correcty (it's work around of this problem).

Jacek Jaworski

--
components: Build
messages: 71230
nosy: jacek
severity: normal
status: open
title: list enumeration corrupt when remove()
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Senthil:

Look at that URL that the server returned in the second redirect:

http://www.wikispaces.com?responseToken=ee3fca88a9b0dc865152d8a9e5b6138d

See that the "?" appears without a path between the host and it.

Check the item 3.2.2 in the RFC 2616, it says that a HTTP URL should be:

  http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

So, we should fix that URL that the server returned. Guess what: if we
put a "/" (as obligates the RFC), everything works ok.

The patch I attach here does that. All tests pass ok.

What do you think?

--
keywords: +patch
Added file: http://bugs.python.org/file11127/issue2464-facundo.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3568] list enumeration corrupt when remove()

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

It's a known fact that mutating a list during iteration will cause
problems. You should mutate a copy of the list.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

With sys.maxint gone in 3.0, test_raisexxx() is also gone in 3.0b2

--
nosy: +tjreedy

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Terry, I don't get to understand your comment. Could you please explain
in more detail? Thank you!

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3569] Glitch in eval() doc

[Terry J. Reedy]

New submission from Terry J. Reedy <[EMAIL PROTECTED]>:

LibRef/built-in functions/eval() has this section

This function can also be used to execute arbitrary code objects (such
as those created by compile()).
In this case pass a code object instead of a string.
The code object must have been compiled passing 'eval' as the kind argument.

As pointed out by Patrick Maupin on py-dev today, the first and third
statements are contradictory: 'arbitrary' != 'limited to kind "eval"'
and the third is wrong in 2.5.  It is still wrong in 3.0b2:

>>> eval(compile('1+2', '', 'eval'))
3
>>> eval(compile('1+2', '', 'exec')) # runs and returns None

Because of the first line, I assume this is intended.

Patrick suggests that the third line be expanded to

In order to return a result other than None to eval's caller,  the code
object must have been compiled passing 'eval' as the kind argument.

I prefer the slightly more compact

In order for eval to return a result other than None, the code object
must have been compiled passing 'eval' as the kind argument.

or even

However eval will return None unless the code object was compiled with
'eval' as the kind argument.

--
assignee: georg.brandl
components: Documentation
messages: 71235
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Glitch in eval() doc
versions: Python 2.5, Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3568] list enumeration corrupt when remove()

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

Since you are just beginning Python, I suggest you report questionable
program behavior on newsgroups comp.lang.python,
gmane.comp.python.general at news.gmane.org, or the python.org mailing
list python-list (all three are equivalent).

--
nosy: +tjreedy

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3556] test_raiseMemError consumes an insane amount of memory

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Can you test with that patch?

I personally can't test it for the next three weeks, sorry.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3567] test_ossaudiodev fails when run with -bb

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

Systems that don't run this test (Windows, ??) cannot catch such problems.
Does adding 'b' fix sunau and the test?

--
nosy: +tjreedy

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue896052] symtable module not documented

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I wrote up some documentation for it in r65715.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3570] str.find docstring typo

[Andy Harrington]

New submission from Andy Harrington <[EMAIL PROTECTED]>:

When you enter help("".find)
you get
...
such that sub is contained within s[start,end]
...

s[start, end] makes no sense.  It should be s[start:end].

--
assignee: georg.brandl
components: Documentation
messages: 71240
nosy: andyharrington, georg.brandl
severity: normal
status: open
title: str.find docstring typo
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3571] test_closerange in test_os can crash the test suite

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

I've been trying to track down the following failure which very recently
has started to plague the py3k buildbots:

[...]
test_os
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1197, in 
main()
  File "./Lib/test/regrtest.py", line 400, in main
print(test)
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1490, in write
self.flush()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1455, in flush
self.buffer.flush()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1071, in flush
self._flush_unlocked()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1079, in _flush_unlocked
n = self.raw.write(self._write_buf)
IOError: [Errno 9] Bad file descriptor


I've determined that the failure in writing to the raw stream underlying
stdout is caused by the fact that the file descriptor 0 has been closed
in test_os.test_closerange:

def test_closerange(self):
f = os.open(support.TESTFN, os.O_CREAT|os.O_RDWR)
# close a fd that is open, and one that isn't
os.closerange(f, f+2)

The problem arises when the call to os.open above returns 0. Normally 0
is the file descriptor underlying stdin, I don't know why it ends up
available for other uses, this would deserve investigation.

In the meantime, a way of circumventing this problem would be to rewrite
test_closerange in a saner way, such that closerange() doesn't try to
close important file descriptors.

--
components: Tests
messages: 71241
nosy: pitrou
priority: critical
severity: normal
status: open
title: test_closerange in test_os can crash the test suite
type: behavior
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3571] test_closerange in test_os can crash the test suite

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Here is a temptative patch. It should fix the problems with test_closerange.

--
keywords: +patch
Added file: http://bugs.python.org/file11128/test_closerange.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Uhm, this patch can cause trouble if not adapted a bit. The index method
may return None for either index1 or index2, which will cause a
TypeError in that for loop.

If code is needed to confirm this, try the following:
menu = Tkinter.Menu(tearoff=False)
menu.delete(0)

--
nosy: +gpolo
resolution: fixed -> 
status: closed -> open

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3572] with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

Reproducing this bug is simple:

./python -c "import os; os.close(2); 1/0"

--
components: Interpreter Core
messages: 71244
nosy: pitrou
priority: high
severity: normal
status: open
title: with closed file descriptor #2 (stderr), py3k hangs when trying to print 
an exception
type: crash
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3549] Missing IDLE Preferences on Mac

[cfr]

cfr <[EMAIL PROTECTED]> added the comment:

Also with Python 2.5.2 on OS X 10.4.11 (PPC but it is the universal
installer): there is no Preferences... menu.

The help mentions an Options menu. I don't know if that is the
equivalent, but I cannot find that either.

--
nosy: +cfr

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1397] mysteriously failing test_bsddb3 threading test in other threads

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

This still happens regularly on buildbots. Just today:
http://www.python.org/dev/buildbot/3.0.stable/amd64%20gentoo%203.0/builds/925/step-test/0

The bsddb tests must be fixed so that exception raised in other threads
(especially when produced by assert* methods) cause the test to fail.
The exceptions do indicate a failure, which should be corrected rather
than ignored.

--
nosy: +pitrou
priority: normal -> high
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3572] with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception

[Guido van Rossum]

Changes by Guido van Rossum <[EMAIL PROTECTED]>:


--
nosy: +gvanrossum

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3572] with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Curious. I wonder if this is platform specific because this does not
hang for me on MacOS.

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3571] test_closerange in test_os can crash the test suite

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

I've finally diagnosed the problem. test_buffer_is_readonly was opening
stdin's file descriptor again in raw mode, and closing it implicitly by
using "with". 

It should be fixed in r65731.

There's a justice: the test had been checked in by me.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3573] IDLE hangs when passing invalid command line args (directory(ies) instead of file(s))

[Guilherme Polo]

New submission from Guilherme Polo <[EMAIL PROTECTED]>:

Passing a single directory as a command line argument can make IDLE hang.
To achieve this the user needs to configure IDLE to open an editor
window by default.

The attached patch discards filenames that failed to load, so in the end
it may open an empty editor window instead of hanging.

--
components: Library (Lib)
files: fix_idle_startup_hang.diff
keywords: patch
messages: 71249
nosy: gpolo
severity: normal
status: open
title: IDLE hangs when passing invalid command line args (directory(ies) 
instead of file(s))
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11129/fix_idle_startup_hang.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3572] with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Hmm, sorry, false alarm. This was due to some debugging code I had added
in my working copy.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

New submission from Brett Cannon <[EMAIL PROTECTED]>:

The following leads to a SyntaxError in 3.0:

  compile(b'# coding: latin-1\nu = "\xC7"\n', '', 'exec')

That is not the case in Python 2.6.

--
messages: 71251
nosy: brett.cannon
severity: normal
status: open
title: compile() cannot decode Latin-1 source encodings

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Looks like Parser/tokenizer.c:check_coding_spec() considered Latin-1 a
raw encoding just like UTF-8. Patch is in the works.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3567] test_ossaudiodev fails when run with -bb

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Fixed in r65734. I can't guarantee that the whole sunau module is ok,
just that it works enough for the test to pass (and emit the expected
sound...).

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2693] IDLE doesn't work with Tk 8.5

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Hi there,

The revisions you are after are r59653 and r59654.
I really don't see a reason to not patch release25-maint with those ones.

--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

looks good to me.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1397] mysteriously failing test_bsddb3 threading test in other threads

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

agreed, that should be made to cause the test to fail.  a
failureException method that sets a flag that the main thread will
detect and fail on when exiting should do the trick.

side note:
...sadly that failure appears to be a test issue, not really a bsddb
wrapper issue...

(There are many tests in the Lib/bsddb/test/ full test suite that appear
to go overboard as far as testing a python wrapper is concerned and are
effectively tests of BerkeleyDB features themselves.  That doesn't help
our test reliability.)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Here is a potential fix. It broke test_imp because it assumed that
Latin-1 source files would be encoded at Latin-1 instead of UTF-8 when
returned by imp.new_module(). Doesn't seem like a critical change as the
file is still properly decoded.

--
keywords: +patch
Added file: http://bugs.python.org/file11130/fix_latin.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Attached is a test for test_pep3120 (since that is what most likely
introduced the breakage). It's a separate patch since the source file is
marked as binary and thus can't be diffed by ``svn diff``.

--
components: +Interpreter Core
priority:  -> critical
versions: +Python 3.0
Added file: http://bugs.python.org/file11131/pep3120_test.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3574] compile() cannot decode Latin-1 source encodings

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
type:  -> behavior

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

Ah, I that was a simple fix. :) I very much overlooked the problem after
being so much given the hints at the web-sig.

I have some comments on the patch, Facundo.
1) I don't think is a good idea to include that portion in the
http_error_302 method. That makes the fix "very" specific to "this"
issue only. 
Another point is, fixing broken url's should not be under urllib2,
urlparse would be a better place.
So, I came up with the approach wherein urllib2 does unparse(parse) of
the url and parse methods will fix the url if it is broken. ( See
attached   issue2464-PATCH1.diff)

But if we handle it in the urlparse methods, then we are much
susceptible to breaking RFC conformance, breaking a lot of tests, Which
is not a  good idea.

So,I introduced fix_broken() method in urlparse and called it to solve
the issue, using the same logic as yours (issue2464-py26-FINAL.diff)
With fix_broken() method in urlparse, we will have better control
whenever we want to implement a behavior which is RFC non-confirming but
implemented widely by browsers and clients.

All tests pass with issue2464-py26-FINAL.diff

Comments,please?

Added file: http://bugs.python.org/file11132/issue2464-py26-FINAL.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Senthil]

Changes by Senthil <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11133/issue2464-PATCH1.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

Patch for py3k, but please test this before applying.

Added file: http://bugs.python.org/file11134/issue2463-py3k.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Senthil: I don't like that.

Creating a public method called "fix_broken", introducing new behaviours
now in beta, and actually not fixing the url in any broken possibility
(just the path if it's not there), it's way too much for this fix.

I commited the change I proposed. Maybe in the future will have a
"generic url fixing" function, now is not the moment.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com