[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +Jeremy.Hylton

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

[issue9997] function named 'top' gets unexpected namespace/scope behaviour

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Let me fix that.

--
nosy: +Jeremy.Hylton

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

[issue6500] urllib2 maximum recursion depth exceeded

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Ok.  I'll take a look, too.

Jeremy

On Sat, Feb 27, 2010 at 4:30 AM, Ezio Melotti  wrote:
>
> Changes by Ezio Melotti :
>
>
> --
> nosy: +orsenthil
> status: pending -> open
>
> ___
> Python tracker 
> <http://bugs.python.org/issue6500>
> ___
>

--

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

[issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved.  If so, I'm not sure that
we want to re-open the discussion.  On the other hand, it's been a
long time since the PEP was approved and we do have a moratorium on
language changes, so it doesn't hurt to slow things down.

I'd argue that the intent of the PEP is pretty clear.  You can take
any assignment statement where the LHS doesn't have subscripts, put a
nonlocal or global in front of it, and it means that all those
assignments are to global/nonlocal variables.

Jeremy

On Wed, Feb 24, 2010 at 4:20 AM, Georg Brandl  wrote:
>
> Georg Brandl  added the comment:
>
>> I also notice that the Grammar in the PEP is more complicated:
>> nonlocal_stmt ::=
>>     "nonlocal" identifier ("," identifier)*
>>                ["=" (target_list "=")+ expression_list]
>>   | "nonlocal" identifier augop expression_list
>>
>> The Grammar in the patch is:
>> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
>> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
>>
>> It appears that the PEP is trying to support:
>>
>> nonlocal x = y = z = 1
>> nonlocal a, b = c, d = 1
>
> It also tries to support augmented assignment; however I'm not sure what the 
> semantics of that should be.
>
> Further, there is an ambiguity if too much freedom is allowed: what about
>
>   global x = 1, y
>
> Is it declaring a global "x" and assigning a tuple, or declaring a global "x" 
> and a global "y"?
>
>> If we're going to support the PEP as written, I think we need to
>> modify Global() and Nonlocal() to look exactly like Assign(), but add
>> an extra check to verify that all of the expressions in the targets
>> are Name, List, or Tuple.  You'd probably want to check this at the
>> time you are generating the AST, so that you're not stuck with some
>> extra state in the compiler traversal about whether you are generating
>> code for a Global() or an Assign().
>
> I would not support List or Tuple as targets.  Same basic problem as
> above, and I don't see a use case.
>
> I see two possibilities for the actual syntax:
>
> 1) global *either* supports multiple identifiers, *or* one identifier
> and an assignment.
>
> 2) global always supports multiple identifiers, each with an optional
> assignment; tuples need parentheses.
>
> In both cases, I would keep it simple and not allow multiple targets or
> augmented assignment.
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4199>
> ___
>

--

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

Re: [issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

I also notice that the Grammar in the PEP is more complicated:
nonlocal_stmt ::=
"nonlocal" identifier ("," identifier)*
   ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

The Grammar in the patch is:
+global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
+nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]

It appears that the PEP is trying to support:

nonlocal x = y = z = 1
nonlocal a, b = c, d = 1

If we're going to support the PEP as written, I think we need to
modify Global() and Nonlocal() to look exactly like Assign(), but add
an extra check to verify that all of the expressions in the targets
are Name, List, or Tuple.  You'd probably want to check this at the
time you are generating the AST, so that you're not stuck with some
extra state in the compiler traversal about whether you are generating
code for a Global() or an Assign().

This approach makes the compiler code very simple.  We use exactly the
same code for Global(), Nonlocal(), and Assign().  It does have the
downside that you need to enforce this unwritten constraint of the AST
in ast.c and in the ast module.

It also means that the AST will change in a non-backwards compatible
way.  I don't see how to do that given that we're also changing the
language spec.  (Do you want to include the spec change in your
patch?)

Jeremy

On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton  wrote:
> On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
>  wrote:
>>
>> Benjamin Peterson  added the comment:
>>
>> I think I may have been merging add_ast_fields when I wrote the patch.
>>
>> Here's a new patch that handles "global x, = (5,)". To do it, I added a
>> new flag* to the Global and Nonlocal AST objects that indicates whether
>> the value needs to be unpacked or not.
>
> You shouldn't need to do this.  The unpack is implied if the number of
> identifiers is greater than 1.
>
> Jeremy
>
>
>
>> * The flag is an int. The bool AST type was removed in py3k.
>>
>> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>>
>> ___
>> Python tracker 
>> <http://bugs.python.org/issue4199>
>> ___
>> ___
>> Python-bugs-list mailing list
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>>
>>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
 wrote:
>
> Benjamin Peterson  added the comment:
>
> I think I may have been merging add_ast_fields when I wrote the patch.
>
> Here's a new patch that handles "global x, = (5,)". To do it, I added a
> new flag* to the Global and Nonlocal AST objects that indicates whether
> the value needs to be unpacked or not.

You shouldn't need to do this.  The unpack is implied if the number of
identifiers is greater than 1.

Jeremy

> * The flag is an int. The bool AST type was removed in py3k.
>
> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4199>
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

--

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

[issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Is deferred blocker a higher priority?

Jeremy

On Tue, Feb 23, 2010 at 4:37 PM, Georg Brandl  wrote:
>
> Georg Brandl  added the comment:
>
> "High" is not high enough :)
>
> --
> priority: high -> deferred blocker
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4199>
> ___
>

--

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

[issue4617] SyntaxError when free variable name is also an exception target

[Jeremy Hylton]

Jeremy Hylton  added the comment:

The patch looks pretty good.

I'd factor out the common error-checking code (common between
LOAD_DEREF and DELETE_DEREF) into a helper function.

It would also be good to add some test cases.

Jeremy

On Tue, Feb 23, 2010 at 9:38 AM, Guido van Rossum
 wrote:
>
> Guido van Rossum  added the comment:
>
> I don't think so. It's very marginal.
>
> --Guido (on Android)
>
> On Feb 23, 2010 8:52 AM, "Amaury Forgeot d'Arc" 
> wrote:
>
> Amaury Forgeot d'Arc  added the comment:
>
> The above patch adds a new opcode (DELETE_DEREF), does the Moratorium apply
> here?
>
> --
>
> ___
> Python tracker 
> <http://bugs.python...
>
> --
> Added file: http://bugs.python.org/file16341/unnamed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4617>
> ___

--

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

[issue4617] SyntaxError when free variable name is also an exception target

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Mon, Feb 22, 2010 at 6:10 PM, Guido van Rossum
 wrote:
>
> Guido van Rossum  added the comment:
>
> All examples so far (*) have to do with our inability to have properly nested 
> blocks. If we did, I'd make the except clause a block, and I'd issue a syntax 
> warning or error if a nested block shadowed a variable referenced outside it. 
> Ditto for generator expressions and comprehensions.

There's no reason we couldn't revise the language spec to explain that
except clauses and comprehensions are block statements, i.e.
statements that introduce a new block.  For the except case, there
would be some weird effects.

y = 10
try:
  ...
except SomeError as err:
  y = 12
print y  # prints 10

In the example above, y would be a local variable in the scope of the
except handler that shadows the local variable in the block that
contains the try/except.  It might be confusing that you couldn't
assign to a local variable in the except handler without using a
nonlocal statement.

> As long as we don't have nested blocks, I think it's okay to see the 
> limitation on (implicit or explicit) "del" of a cell variable as a compiler 
> deficiency and fix that deficiency.

The general request here is to remove all the SyntaxErrors about
deleting cell variables, right?  Instead, you'd get a NameError at
runtime saying that the variable is currently undefined.  You'd want
that change regardless of whether we change the language as described
above.

hoping-for-some-bdfl-pronouncements-ly y'rs,
Jeremy

> __
> (*) However there's also this example:
>
>>>> def f():
> ...  try: 1/0
> ...  except Exception as a:
> ...   def g(): return a
> ...   return g
> ...
> SyntaxError: can not delete variable 'a' referenced in nested scope
>>>>
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4617>
> ___
>

--

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

Re: [issue4617] SyntaxError when free variable name is also an exception target

[Jeremy Hylton]

It's an interesting bug.  Maybe the compiler shouldn't allow you to
use such a variable as a free variable in a nested function?

On Thu, Feb 11, 2010 at 9:09 PM, Craig McQueen  wrote:
>
> Craig McQueen  added the comment:
>
> There's also this one which caught me out:
>
> def outer():
>  x = 0
>  y = (x for i in range(10))
>  del x  # SyntaxError
>
> --
> nosy: +cmcqueen1975
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Sun, Feb 21, 2010 at 5:38 PM, Robert Buchholz  wrote:
>
> Robert Buchholz  added the comment:
>
> almost... HTTPConnection is calling close() on the socket object, but 
> HTTPResponse still has an open file-like object from a previous makefile() 
> call. That object still has an internal reference to the socket.

That's right.  The makefile() method on sockets works that way, and
the HTTP library depends on that behavior (and pretty much always
has).

Jeremy

>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue7806>
> ___
>

--

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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

Jeremy Hylton  added the comment:

In particular, I mean this part of the socket API:

socket.makefile([mode[, bufsize]])
Return a file object associated with the socket. (File objects are
described in File Objects.) The file object references a dup()ped
version of the socket file descriptor, so the file object and socket
object may be closed or garbage-collected independently. The socket
must be in blocking mode (it can not have a timeout). The optional
mode and bufsize arguments are interpreted the same way as by the
built-in file() function.

The language may be a little vague, but it means that closing the file
generated by makefile() should not close the underlying socket.

Jeremy

On Sun, Feb 21, 2010 at 3:23 PM, Jeremy Hylton  wrote:
>
> Jeremy Hylton  added the comment:
>
> On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
>  wrote:
>>
>> R. David Murray  added the comment:
>>
>> But the docs (which presumably describe the API) say that the socket is 
>> unusable after the call to close, which argues that the paramiko sockets are 
>> following the documented API.  Do the docs need to be corrected?
>
> I mean the documented socket API.
>
> Jeremy
>
>> --
>>
>> ___
>> Python tracker 
>> <http://bugs.python.org/issue7806>
>> ___
>>
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue7806>
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

--

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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
 wrote:
>
> R. David Murray  added the comment:
>
> But the docs (which presumably describe the API) say that the socket is 
> unusable after the call to close, which argues that the paramiko sockets are 
> following the documented API.  Do the docs need to be corrected?

I mean the documented socket API.

Jeremy

> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue7806>
> ___
>

--

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

[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

Jeremy Hylton  added the comment:

On Fri, Feb 19, 2010 at 6:22 PM, R. David Murray  wrote:
>
> R. David Murray  added the comment:
>
> But a goal is for the standard library to work with Python implementations 
> other than CPython, and the reference counting behavior described won't 
> happen in non-reference counting implementations.  So I don't think that 
> requiring emulation of ref-counting behavior is valid.

I don't think an implementation of Python sockets would be considered
correct unless it supported this behavior.  CPython goes to elaborate
lengths to make it work across platforms.

Jeremy

> --
> nosy: +r.david.murray
>
> ___
> Python tracker 
> <http://bugs.python.org/issue7806>
> ___
>

--

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

Re: [issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response

[Jeremy Hylton]

I don't think the HTTPConnection class was designed to work with
sockets that don't follow the Python socket API.  If you want to use a
different socket, you should create some wrapper that emulates the
Python socket ref count behavior.

Jeremy

On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz  wrote:
>
> Robert Buchholz  added the comment:
>
> An example cannot be constructed using the standard python socket class. As 
> you point out, the response.will_close attribute is set correctly: The client 
> is supposed to close to connect after completion of the request (as does the 
> server). However, when the HTTPConnection object calls close() on the socket, 
> reading the request is not completed -- the request object merely created a 
> file-like object representing the socket.
>
> The reason why this is not an issue is that the Python socket library does 
> reference counting to determine when to close a socket object. When the 
> HTTPConnection calls close(), its own socket object is destroyed and 
> unreferenced. However, the file-like object in the HTTPResponse still has a 
> copy of the socket.
>
> In alternative socket implementations (like Paramiko SOCKS-proxied sockets), 
> this poses a problem: When the socket user calls close(), they actually close 
> the socket -- as the original socket API documentation describes:
>
>    close()
>    Close the socket.  It cannot be used after this call.
>
>    makefile([mode[, bufsize]]) -> file object
>    Return a regular file object corresponding to the socket.  The mode
>    and bufsize arguments are as for the built-in open() function.
>
> Consequently, I do not consider this to be a bug in Paramiko and reported it 
> for the httplib. I can present example code using a paramiko tunneled socket 
> (client and server) if you like.
>
> --
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Amaury-- I think that will work.  I put together a small patch that seems to 
pass all the tests, but it too messy.  We need some care to make sure we don't 
spin forever if there's some degenerate case where we never escape GC.

--

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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Jeremy Hylton]

Jeremy Hylton  added the comment:

One last thought on this bug.  The problem is that after we try to delete 
garbage, we really can't know much about the state of the objects in the 
finalizers list.  If any of the objects that are cleared end up causing a 
finalizer to run, then any of the objects in the finalizers list may be 
reachable again.  One possibility is to do nothing with the objects in the 
finalizers list if there was any garbage to delete.  That means objects with 
finalizers would be harder to get to gc.collect()--for example, you'd need to 
call gc.collect() twice in a row.  The first time to clear garbage, the second 
time to handle unreachable objects with finalizers.  Or the GC could run a 
second time if garbage was cleared and finalizers was non-empty.

A more complicated possibility would be to track some object state about when a 
finalizer was run.  If any of the objects in finalizers had a finalizer that 
ran while garbage was cleared, we could skip the finalizers list.  I don't know 
how to implement this, since an arbitrary C type could run Python code in 
tp_dealloc without notifying GC.

--

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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I spent some time to understand the example script today.  The specific issue 
is that a set of objects get put into the list of unreachable objects with 
finalizers (both Immutable and Finalizer instances).  When Cycle's __dict__ is 
cleared, it also decrefs Immutable which resurrects it and Finalizer.  The 
garbage collector is not prepared for an unreachable finalizer object to become 
reachable again.  More generally, it's hard to assume anything about the state 
of the finalizers after unreachable trash is collected.  I'll think more about 
what to do, but I don't see any easy solutions.

--

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

[issue1540] Refleak tests: test_doctest and test_gc are failing

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I'm trying to figure out the attached script.  If I run Python 3.0, the script 
doesn't run because of the undefined gc.DEBUG_OBJECTS.  If I just remove that, 
the script runs without error.  Does that mean the problem is fixed?  Or is 
running without an error an example of the problem?

If I add gc.DEBUG_SAVEALL, it fails--but that seems obvious because 
DEBUG_SAVEALL adds all objects with finalizers to gc.garbage.

--
nosy: +Jeremy.Hylton

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

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

[Jeremy Hylton]

Not that we've removed the try one more time branch of the code,
because it was causing other problems.

Jeremy

On Sun, Aug 16, 2009 at 6:24 PM, Gregory P. Smith wrote:
>
> Gregory P. Smith  added the comment:
>
> btw, when using async io (poll, select, etc) I -think- your socket will
> see a read event when the server closes the connection (sends you a FIN
> or even a RST) at which point your sock.recv() when you've been told
> data was ready will return 0 bytes indicating that the server has closed
> the connection.
>
> I like your MSG_PEEK hack here.  I'll figure out if this or something
> else should go into (the giant mess that is) httplib.
>
> --
> priority:  -> normal
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5578] unqualified exec in class body

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Why did it change from 2.5 to 2.6?  I'm not sure that the change makes
any sense.  (Dreading the answer that I changed it...)

--

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

[issue5628] TextIOWrapper fails with SystemError when reading HTTPResponse

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I just wanted to mention that the current head of py3k returns an
http.client.HTTPResponse and not a urllib.respone.addinfourl.  That
doesn't mean it is the right thing to pass to TextIOWrapper.  It's an
instance of RawIOBase.

--

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

[issue5628] TextIOWrapper fails with SystemError when reading HTTPResponse

[Jeremy Hylton]

New submission from Jeremy Hylton :

import io
import urllib.request

f_bytes = urllib.request.urlopen("http://www.python.org/";)
f_string = io.TextIOWrapper(f_bytes, "iso-8859-1")
print(f_string.read())

--
components: Library (Lib)
messages: 84840
nosy: jhylton
severity: normal
status: open
title: TextIOWrapper fails with SystemError when reading HTTPResponse
versions: Python 3.0

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

[issue2344] Using an iteration variable outside a list comprehension needs a Py3K warning

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Seemed like a good idea, but no one knew how to do it.

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

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

[issue2344] Using an iteration variable outside a list comprehension needs a Py3K warning

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +jhylton

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

[issue1346238] A constant folding optimization pass for the AST

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
priority: high -> normal

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

[issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +jhylton

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

[issue5524] execfile() removed from Python3

[Jeremy Hylton]

Jeremy Hylton  added the comment:

It doesn't seem helpful to leave this issue open, particularly since the
title suggest there's a problem with execfile being removed and that's
not going to change.

--
nosy: +jhylton
status: open -> closed

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

[issue5578] unqualified exec in class body

[Jeremy Hylton]

Jeremy Hylton  added the comment:

exec is allowed in a class statement

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

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

[issue4831] exec() behavior - revisited

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I think this bug ran out of steam.  Python is behaving as intended, and
I think Georg addressed all of David's questions.

--
nosy: +jhylton
resolution:  -> works for me
status: open -> closed

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

[issue991196] An inconsistency with nested scopes

[Jeremy Hylton]

Jeremy Hylton  added the comment:

This code behaves as intended.  The module-level execution environment
is different than other environments.  The global scope and local scope
are the same dictionary.  Assignments at the top-level become globals
because of this behavior of the execution environment.  If you want exec
to mimic the top-level environment, you need to pass it a single dictionary.

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

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

[issue991196] An inconsistency with nested scopes

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
assignee:  -> jhylton
nosy: +jhylton

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

[issue1153622] eval does not bind variables in lambda bodies correctly

[Jeremy Hylton]

Jeremy Hylton  added the comment:

The current docs cover this case:
http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features

It basically says that code compiled via exec / eval can't access free
variables.

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

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

[issue4315] On some Python builds, exec in a function can't create shadows of variables if these are declared "global" in another function of the same module

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Committed revision 70809 (trunk).  Needs to be backported.

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

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

[issue1659410] Minor AST tweaks

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +jhylton

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

[issue4675] urllib's splitpasswd does not accept newline chars in passwords

[Jeremy Hylton]

Jeremy Hylton  added the comment:

looks good to me

--
nosy: +jhylton

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

[issue4962] urlparse & nfs url (rfc 2224)

[Jeremy Hylton]

Jeremy Hylton  added the comment:

looks good to me

--
nosy: +jhylton

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

[issue5578] unqualified exec in class body

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
assignee:  -> jhylton
nosy: +jhylton
resolution:  -> accepted
type:  -> behavior

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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[Jeremy Hylton]

Jeremy Hylton  added the comment:

The attached file is vaguely related to the current discussion.  I'd
like to document the API for the urllib response, but I'd also like to
simplify the implementation on the py3k side.  We can document the
simple API on the py3k side, then support some version of that API on
the py2k side.

Apologies for the noise in this patch.  I was on a plane, and I don't
understand DVCS yet.

--
keywords: +patch
Added file: http://bugs.python.org/file13473/addinfourl_removal.diff

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

[issue918368] urllib doesn't correct server returned urls

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +jhylton

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

[issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
nosy: +jhylton

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

[issue3243] Support iterable bodies in httplib

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Seems like a reasonable feature request.  I'm going to apply a variant
of the patch in 3.1 first.

--
assignee:  -> jhylton
nosy: +jhylton
resolution:  -> accepted

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

[issue5542] Socket is closed prematurely in httplib, if server sends response before request body has been sent

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I think it makes sense to leave the socket open in this case.  (In
general, I think httplib is too aggressive about closing the socket.) 
I'm checking in a version for py3k, and will get around to backporting
it later.

Committed revision 70643.

--
resolution:  -> accepted

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

[issue5542] Socket is closed prematurely in httplib, if server sends response before request body has been sent

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Wow!  Old issue.  This behavior was present in Greg's original version
of the code.

--

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

[issue5542] Socket is closed prematurely in httplib, if server sends response before request body has been sent

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
assignee:  -> jhylton
nosy: +jhylton

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

[issue5314] http client error

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Committed revision 70638.

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

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

[issue5314] http client error

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Ok.  Discovered that RFC 2616 says that iso-8859-1 is the default
charset, so I will use that to encode strings instead of ascii.  If you
want utf-8, you could encode the string yourself before calling
request().  Presumably, you should also add a content-type that explains
the charset.  I'll clarified this in the docs.

--
assignee:  -> jhylton

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

[issue5314] http client error

[Jeremy Hylton]

Jeremy Hylton  added the comment:

The documentation is pretty vague on this point.  If you send something
other than plain ascii, it gets a bit tricky to figure out what other
headers need to be added.  It would be safer for the client to pick an
encoding (e.g. utf-8) and encode the string before calling request(). 
It affects the content-length and presumably also the content-type.

--

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

[issue5468] urlencode does not handle "bytes", and could easily handle alternate encodings

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Indeed, I think I confused some other character encoding issues related
to HTTP with the URI issue.  The discussion in RFC 3986 is length and
only occasionally clarifying for this issue.  That is, it doesn't say
anything definitive like applications are free to use any character
encoding when decoding a URI.  But I think it agrees with your
assessment that an application is free to interpret the binary data
however it wants, e.g. http://tools.ietf.org/html/rfc3986#section-2.1

--
assignee:  -> jhylton
resolution:  -> accepted

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

[issue5314] http client error

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I'm not sure what to do here.  I guess changing to utf-8 is safe insofar
as the current code only accepts ascii, so the only code that breaks
will be code that depends on the encode() call raising an exception.  It
seems like the client out to specify the encoding, though.  We could fix
that via documentation.

--
nosy: +jhylton

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

[issue5418] urllib.response.addinfourl does not support __exit__

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Makes sense to me.
Committed revision 70625.

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

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

[issue5418] urllib.response.addinfourl does not support __exit__

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
assignee:  -> jhylton
nosy: +jhylton
resolution:  -> accepted

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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[Jeremy Hylton]

Jeremy Hylton  added the comment:

A plausible solution is to pick some core set of functionality that we
think people need and document that API.  We can modify one or both of
the current implementations to include that functionality.  What do we need?

--

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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[Jeremy Hylton]

Jeremy Hylton  added the comment:

No deep thought was given to the HTTPMessage API.  Here's the extent of
the discussion that I can find.  I've changed the names, but you can
find the full discussion at http://bugs.python.org/issue2848

A: mimetools.Message is compatible with email.message.Message, right?
B: I don't know how compatible it is.
C: The APIs are bit different, but it should be possible to migrate from 
the old to the new.

--
nosy: +jhylton

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

[issue5468] urlencode does not handle "bytes", and could easily handle alternate encodings

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I'm not sure I understand the part of the code that deals with binary
strings.  I agree the current behavior is odd.  RFC 2396 says that
non-ascii characters must be encoded as utf-8 and then percent escaped.
 In the test case you started with, you encoded b'\xa0\x24'.  It doesn't
seem like this should be allowed, since it is not valid utf-8.

--
nosy: +jhylton

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

[issue4631] urlopen returns extra, spurious bytes

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I have a patch here that seems to work for the specific url and that
passes all the tests.  Can anyone check whether it works for a larger
set of cases?

I'm a little concerned because I don't understand the new io library in
much detail.  There's an override for _checkClosed() in the HTTPResponse
that seems a little dodgy.  I'll try to get someone to review that
specifically.

Added file: http://bugs.python.org/file12361/urllib-chunked.diff

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

[issue4631] urlopen returns extra, spurious bytes

[Jeremy Hylton]

Jeremy Hylton  added the comment:

Brief update:  The Python 2.x code works because readline() is provided
by socket._fileobject.  The Python 3.x code fails because it grabs the
HTTPResponse.fp instance variable at the end of
AbstractHTTPHandler.do_open.  That method needs to pass the response to
addinfourl(), but needs to have support for readline / readlines before
it can do that.

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

[issue3761] urllib.request and urllib.response cannot handle HTTP1.1 chunked encoding

[Jeremy Hylton]

Jeremy Hylton  added the comment:

I'm sorry that I didn't notice this bug report in September!  The
chunked support does exist in the http package, but it doesn't work with
urllib.  Tracking in 4631.

--
nosy: +jhylton
resolution:  -> duplicate
status: open -> closed
superseder:  -> urlopen returns extra, spurious bytes

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

[issue4631] urlopen returns extra, spurious bytes

[Jeremy Hylton]

Changes by Jeremy Hylton :


--
assignee:  -> jhylton

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

Re: [issue4631] urlopen returns extra, spurious bytes

[Jeremy Hylton]

Does the same thing happen with 2.6?

Jeremy

On Thu, Dec 11, 2008 at 8:53 AM, Jean-Paul Calderone
 wrote:
>
> Jean-Paul Calderone  added the comment:
>
> The "f65" is the chunk length for the first chunk returned when
> requesting that URL.  A proxy could easily hide this by switching to a
> different transfer encoding.
>
> --
> nosy: +exarkun
>
> ___
> Python tracker 
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [issue4608] urllib.request.urlopen does not return an iterable object

[Jeremy Hylton]

Oops.  I didn't think it translate the code in addinfobase to the new
style of iterators.

Jeremy

On Tue, Dec 9, 2008 at 7:50 AM, Senthil <[EMAIL PROTECTED]> wrote:
>
> Senthil <[EMAIL PROTECTED]> added the comment:
>
> I verified this bug in the Py3.0 and Py3.1. Shall come out with a patch
> for it.
>
> --
> nosy: +orsenthil
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I submitted r67442, which combines the headers and body in a single
send() call.  We should look at the buffering issue now, although I
probably won't have any time to check on it until Friday.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4456] xmlrpc is broken

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I don't think I understand this report.  The TransportSubclassTestCase
class tests the behavior of overridable methods that don't exist in
Python 3.0.  Is this really a Python 3.0 problem?  I'm not sure why we
expect it to work there.

Jeremy

On Fri, Nov 28, 2008 at 5:43 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> New submission from Benjamin Peterson <[EMAIL PROTECTED]>:
>
> It looks there are logic problems with regards to encoding in xmlrpc:
>
>if not isinstance(methodname, str):
>methodname = methodname.encode(encoding)
>
> Merging r67370 and running test_xmlrpc gives:
>
> test_bug_1164912 (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_cmp_datetime_DateTime (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_bad_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_bare_datetime (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_big_int (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_big_long (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_load (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_none (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_recursive_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_dump_recursive_seq (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_newstyle_class (test.test_xmlrpc.XMLRPCTestCase) ... ok
> test_escape (test.test_xmlrpc.HelperTestCase) ... ok
> test_datetime_datetime (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_decode (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_default (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_repr (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time_struct (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_time_tuple (test.test_xmlrpc.DateTimeTestCase) ... ok
> test_decode (test.test_xmlrpc.BinaryTestCase) ... ok
> test_default (test.test_xmlrpc.BinaryTestCase) ... ok
> test_string (test.test_xmlrpc.BinaryTestCase) ... ok
> test_dotted_attribute (test.test_xmlrpc.FaultTestCase) ... ok
> test_dump_fault (test.test_xmlrpc.FaultTestCase) ... ok
> test_repr (test.test_xmlrpc.FaultTestCase) ... ok
> test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase) ...
> ERROR
> test_send_content (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_send_host (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_send_request (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
> test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection2 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection3 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_introspection4 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_simple1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
> test_basic (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_fail_no_info (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_fail_with_info (test.test_xmlrpc.FailingServerTestCase) ... ok
> test_cgi_get (test.test_xmlrpc.CGIHandlerTestCase) ... ok
> test_cgi_xmlrpc_response (test.test_xmlrpc.CGIHandlerTestCase) ... ok
>
> ==
> ERROR: test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase)
> --
> Traceback (most recent call last):
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 657, in
> test_custom_user_agent
>req = self.issue_request(TestTransport)
>  File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
> issue_request
>proxy.pow(6, 8)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
>return self.__send(self.__name, args)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
>verbose=self.__verbose
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
>return self._parse_response(resp, None)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
> _parse_response
>p.feed(response)
>  File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
>self._parser.Parse(data, 0)
> xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
>
> ==
> ERROR: test_send_content (test.te

[issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I did the simple part of the patch, where the request and headers are
sent at the same time.  The applied patch didn't pass the test suite,
and I want to think about the buffering change a bit more.  It's
definitely tricky.

Jeremy

On Fri, Nov 28, 2008 at 5:53 AM, Kristján Valur Jónsson
<[EMAIL PROTECTED]> wrote:
>
> Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment:
>
> Guido pointed out the problem with _fileobject.readline() being
> followed by socket.recv() if readline uses read buffering.
> xmlrpclib.py was attempting to directly use the underlying socket,
> although in actual fact it never did, (since HTTPConnectio had closed
> it when it returned the response from getresponse()) Never the less, it
> is prudent to make sure that we don't attempt this.
> There really should be no need to use the socket directly, a buffered
> read() call is just as efficient.
>
> Added file: http://bugs.python.org/file12145/xmlrpc.patch
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue4336>
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

I think we're making progress, but I'm still not sure about the new
httplib api.  My current worry is that endheaders() behaves very
differently when send_data is false.  My chief concern is that the
__state variable is going to indicate that the request has been sent
when we're really depending on the client to send the header.  In
general, I don't like the public send() method since it's exposing a
raw socket that could be called at any time regardless of the _state
of the object.

What if endheaders() takes body as an optional argument and sends it
along with the headers?  This accomplishes the same basic goal as
returning the header from endheaders(), but keeps the actual sending
of data encapsulated within the http connection.

Jeremy

On Tue, Nov 25, 2008 at 6:13 AM, Kristján Valur Jónsson
<[EMAIL PROTECTED]> wrote:
>
> Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment:
>
> I have addressed some issues mentioned:
> 1) I have retained the _send_output() method.
> 2) the endheaders() method now takes an optional argument, send_data
> that defaults to True.  It also returns any unsent data as a string.
> This simplifies any code wishing to send more data.
> 3) The old HTTP class needs no changes anymore.
> 4) I've fixed the test_xmlrpc.py test case to run all the tests on
> windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer
> valid.
> 5) concatenating the result from endheaders() with the request body is
> valid, in xmlrpclib, because the assumption has already been made in
> send_content() that request_body is a string (str(len(request_body)).
> However, in httplib's request() method, we now special case this.  I
> don't want to complicate the code for what appears to be a rare case.
>
> I chose not to mess with xmlrpclib and make it continue to use the old
> HTTP class in order to minimise the extent of this patch.  A simple and
> clear performance patch has in my experience a much greater chance of
> finding its way into the codebase than a more extensive rewrite :)
>
> You may have concerns regarding point 3 above, and I am open to
> suggestions.
>
> Now, what remains is the question of the read buffering for the socket
> fileobject.  Do you think that it is feasible to simply change the
> default read buffering for fileobjects to use buffering for readline()
> same as they do for read()?  Then we wouldn't need the second half of
> this patch and we could make a separate "socket" performance patch.
>
> Added file: http://bugs.python.org/file12127/xmlrpc.patch
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1208304] urllib2's urlopen() method causes a memory leak

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

Python 2.4 is now in security-fix-only mode. No new features are being
added, and bugs are not fixed anymore unless they affect the stability
and security of the interpreter, or of Python applications.
http://www.python.org/download/releases/2.4.5/

This bug doesn't rise to the level of making into a 2.4.6.

--
nosy: +jhylton
resolution:  -> wont fix
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1208304>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

Actually, the patch doesn't work :-).  The httplib API allows you to
pass a file or a string for the body of the request.  The
getheaderdata() + body case only works for the string.  Easy to fix,
but I worry that he still run into Nagle problems with the file case,
which was presumably added for efficiency.

Jeremy

On Mon, Nov 24, 2008 at 12:32 PM, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>
> Jeremy Hylton <[EMAIL PROTECTED]> added the comment:
>
> This patch makes sense in principle, but some of the details need to
> change.  The _send_output() method is used by some clients, merely
> because it can be used :-(.  It's fairly easy to preserve this API for
> backwards compatibility.
>
> I am also worried about this new api call getheaderdata().  It
> complicates the API.  Even if it were necessary, it needs a better name,
> because getheaderdata() doesn't sound like a method that changes the
> connection state or consumes buffered header data.
>
> I think it would be better to have the new behavior exposed only through
> HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility
> API(!).  We can make some small changes to xmlrpclib to use the newer
> API.  It would probably be a good change merely because py3k now uses
> the newer API.
>
> I've got a working local change, but it's still a little ugly.
>
> --
> assignee:  -> jhylton
> nosy: +jhylton
> status: open -> pending
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue4336>
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4327] Patch: simplify complex constant assignment statements

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I haven't thought about the code in a while, but what code that
modifies the AST are we worried about?  There are lots of
modifications in ast.c, since it is being created there.  The case we
really care about is sequences, where we want to modify the sequence.
The creation goes through macros like asdl_seq_SET(), so we could just
change the macro.  What are other cases we need to worry about?

Jeremy

On Mon, Nov 24, 2008 at 12:50 PM, David Turner <[EMAIL PROTECTED]> wrote:
>
> David Turner <[EMAIL PROTECTED]> added the comment:
>
> Sure, but that's an even bigger change.  Every piece of code which
> modifies the AST would now also have to modify parent pointers.  Having
> the pointers would make many things easier, but I didn't want to make a
> very invasive change like that without thinking it through thoroughly.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue4327>
> ___
>

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4327>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

Just wanted to mention that the best solution is to update as much code
as possible to use HTTPConnection instead of HTTP.  I'm not sure how
easy it is to do for xmlrpclib, since it exposes methods like
send_content().  I guess we can preserve those APIs somehow, but it
won't be pretty.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4336] Fix performance issues in xmlrpclib

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

This patch makes sense in principle, but some of the details need to
change.  The _send_output() method is used by some clients, merely
because it can be used :-(.  It's fairly easy to preserve this API for
backwards compatibility.

I am also worried about this new api call getheaderdata().  It
complicates the API.  Even if it were necessary, it needs a better name,
because getheaderdata() doesn't sound like a method that changes the
connection state or consumes buffered header data.

I think it would be better to have the new behavior exposed only through
HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility
API(!).  We can make some small changes to xmlrpclib to use the newer
API.  It would probably be a good change merely because py3k now uses
the newer API.

I've got a working local change, but it's still a little ugly.

--
assignee:  -> jhylton
nosy: +jhylton
status: open -> pending

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [issue4327] Patch: simplify complex constant assignment statements

[Jeremy Hylton]

On Mon, Nov 24, 2008 at 12:14 PM, David Turner <[EMAIL PROTECTED]> wrote:
>
> David Turner <[EMAIL PROTECTED]> added the comment:
>
> jhylton, keep in mind that this would require an additional "parent"
> argument to each function which takes a stmt.  Do you think this added
> complexity is worth it?

Or we could add parent pointers in the tree, right?

Jeremy

>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4327] Patch: simplify complex constant assignment statements

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

It seems generally useful to have a helper function to replace a range
of nodes in a sequence of statements with another sequence of nodes.  A
general API like that would allow you to insert or delete nodes as well
as replacing one node with a set of nodes.  It seems like that could be
implemented pretty independently of this patch, and would then simplify
it.  I don't think it's a good idea to add the Seq type just to simplify
the implementation.

--
nosy: +jhylton

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4327>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3347] urllib.robotparser doesn't work in Py3k

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

Committed revision 65118.

I applied a simple version of this patch and added a unittest.

--
assignee:  -> jhylton
nosy: +jhylton
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3347>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3377] Invalid child node access in ast.c

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

Committed revision 65064.

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3377>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3377] Invalid child node access in ast.c

[Jeremy Hylton]

Changes by Jeremy Hylton <[EMAIL PROTECTED]>:


--
assignee:  -> jhylton
nosy: +jhylton

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3377>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2885] Create the urllib package

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

Oops.  Let me look at this tomorrow.  It was down to one failing test
that last time I checked.

Jeremy

On Wed, Jun 11, 2008 at 10:10 PM, Barry A. Warsaw
<[EMAIL PROTECTED]> wrote:
>
> Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
>
> This didn't get done for the first beta.  Please try to do it asap after
> the beta releases.
>
> --
> nosy: +barry
> priority: release blocker -> critical
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2885>
> ___
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2885>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1348] httplib closes socket, then tries to read from it

[Jeremy Hylton]

Changes by Jeremy Hylton <[EMAIL PROTECTED]>:


--
nosy: +jhylton

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1348>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2775] Implement PEP 3108

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I think we should move robotparser into the urllib package.  Anyone
disagree?

Jeremy

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2775>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346238] A constant folding optimization pass for the AST

[Jeremy Hylton]

Changes by Jeremy Hylton <[EMAIL PROTECTED]>:


--
nosy: +jhylton

_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1346238>
_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2775] Implement PEP 3108

[Jeremy Hylton]

Jeremy Hylton <[EMAIL PROTECTED]> added the comment:

I'm working on the new urllib package.

--
nosy: +jhylton

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2775>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: sys.settrace closure interaction bug

[Jeremy Hylton]

Can you file a bug report for this?  I'm guessing that the trace code
has some bad interaction with LOAD_LOCALS, such that a free variable
passed through the class gets treated as local instead.  I can
reproduce this problem in Python 2.4, so it's a long-standing bug.

Also, as a matter of terminology, there is no currying going on.  It's
just a problem with closures.

Jeremy

On 10/1/06, Scott Marks <[EMAIL PROTECTED]> wrote:
> The code below exhibits different behavior depending on whether it invokes
> sys.settrace ('-t' option) or not.  This means that (in a more complicated
> case) debugging the code (which uses sys.settrace) makes it fail.  Any
> ideas?
>
> """ Demonstrace that tracing messes up curried class definitions """
>
>  # Some simple command line parsing: -t or --trace means trace, nothing
> means don't trace
>  import sys
>
> def usage( ):
>  print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
> sys.exit( 1 )
>
> if 1 == len( sys.argv ):
>  pass
> elif 2 == len( sys.argv ):
>  if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
> def trace ( frame, event, arg ):
> # print frame, event, arg
>  return trace
> sys.settrace( trace )
>  else:
> usage( )
>  else:
> usage( )
>
>
>
> # The test: define a class factory with a curried member function
>
> def the_factory( parm1 ):
>  class the_class( object ):
> def curried( self ): return parm1
>  return the_class
>
>  x = the_factory( 42 )
>
> y = x( )
>
> try:
> x.parm1
> print "Failure: x (the manufactured class) has attribute parm1?!"
>  except AttributeError:
> print "Success with the manufactured class!"
>
> try:
>  y.parm1
> print "Failure: y (the instance) has attribute parm1?!"
>  except AttributeError:
> print "Success with the instance!"
>
> assert y.curried( ) == 42, "Currying didn't work?!"
>
>
> ___
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
>
>
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement

[Jeremy Hylton]

I'm working on this bug now, but can't get an SF login to update the bug report.

Jeremy

On 10/3/06, SourceForge.net <[EMAIL PROTECTED]> wrote:
> Bugs item #1569998, was opened at 2006-10-03 14:04
> Message generated for change (Settings changed) made by gbrandl
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: Parser/Compiler
> Group: Python 2.5
> Status: Open
> Resolution: None
> >Priority: 8
> Submitted By: Nick Coghlan (ncoghlan)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: 2.5 incorrectly permits break inside try statement
>
> Initial Comment:
> The new AST compiler permits the break statement inside
> *any* frame block, rather than requiring that there be
> a loop somewhere on the block stack.
>
> Will add examples in a comment where SF shouldn't
> destroy the formatting.
>
> --
>
> Comment By: Nick Coghlan (ncoghlan)
> Date: 2006-10-03 14:05
>
> Message:
> Logged In: YES
> user_id=1038590
>
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> try:
> ... print 1
> ... break
> ... print 2
> ... finally:
> ... print 3
> ...
> SyntaxError: 'break' outside loop
>
> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
> bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.>>> try:
> ... print 1
> ... break
> ... print 2
> ... finally:
> ... print 3
> ...
> 1
> 3
>
> --
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470
> ___
> Python-bugs-list mailing list
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com