Matt Chaput added the comment:
I don't know what to tell you... to the best of my knowledge there's absolutely
no way for my code to kick off the entire test suite -- I always do that
through PyDev (which doesn't cause the bug, by the way). The closest thing is
the boilerplat
Matt Chaput added the comment:
If I do "c:\python27\python run_nose.py" it works correctly. If I do
"nosetests" I get the process explosion. Maybe the bug is in how distutils and
nose work from the command line? I'm confused.
--
_
Matt Joiner added the comment:
Why isn't this implemented to work with __int__ as well?
--
nosy: +anacrolix
___
Python tracker
<http://bugs.python.org/i
Matt Joiner added the comment:
Thanks Mark for clearing that up. I found this link to be useful in explaining
the purpose of __index__:
http://docs.python.org/release/2.5.1/whatsnew/pep-357.html
I think the choice of allowing only __index__ was the right choice
New submission from Matt Joiner :
The Format Specification Mini-Language is missing type 'i', generally the same
as 'd', and ubiquitous in the libraries from which the specification is
derived. See the 'd,i' conversion specifier in C:
http://linux.die.net/ma
Matt Joiner added the comment:
Is there any reason 'd' was chosen over 'i'? Is there a more appropriate place
I can find this out?
--
___
Python tracker
<http://bug
New submission from Matt Mulsow <[EMAIL PROTECTED]>:
On Windows, when a suprocess.Popen command is issued while
a socket connection is being handled the socket connection
will not close until the output of the subprocess is consumed.
The connection remains open even though the request
Matt Kern <[EMAIL PROTECTED]> added the comment:
Updated patch with numerous changes, which (hopefully) address the
issues you raised.
Added file: http://bugs.python.org/file10671/patch-20080620-1232.diff
___
Python tracker <[EMAIL PROTECTE
Matt Kern <[EMAIL PROTECTED]> added the comment:
Updated patch with further documentation fixes.
Added file: http://bugs.python.org/file10672/patch-20080620-1314.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
New submission from Matt Giuca <[EMAIL PROTECTED]>:
Three Unicode-related problems with urllib.parse.quote and
urllib.parse.unquote in Python 3.0. (Patch attached).
Firstly, unquote appears not to have been modified from Python 2, where
it is designed to output a byte string. In Python
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Point taken. But the RFC certainly doesn't say that ISO-8859-1 should be
used. Since we're outputting a Unicode string in Python 3, we need to
decode with some encoding, and UTF-8 seems the most sensible and
standardised.
(Even t
New submission from Matt Giuca <[EMAIL PROTECTED]>:
urllib.parse doesn't import sys, which is needed on line 368, in an
error condition for urlencode. This is only a problem when urlencode has
a TypeError.
Current behaviour:
>>> urllib.parse.urlencode("foo")
NameE
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK I've gone back over the patch and decided to add the "encoding" and
"errors" arguments from the str.encode/decode methods as optional
arguments to quote and unquote. This is a much bigger change than I
originally
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK well here are the necessary changes to the documentation (RST docs
and docstrings in the code).
As I said above, I plan to to extensive testing and add new cases, and I
don't recommend this patch is accepted until that
Matt Giuca <[EMAIL PROTECTED]> added the comment:
I was able to duplicate this, but it's an issue with Firefox, not
Python. webbrowser.open(url) just passes url as a command line argument
to the web browser; it doesn't do any manipulation.
Note that you get the exact same beha
Matt Giuca <[EMAIL PROTECTED]> added the comment:
You seem to be suggesting that a StopIteration raised in the body of a
for-loop should cause the loop to break. That isn't (as far as I know)
the point of StopIteration. StopIteration is only used to break the
for-loop when raised by t
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Setting Version back to Python 3.0. Is there a reason it was set to
Python 3.1? This proposal will certainly break a lot of code. It's *far*
better to do it in the big backwards-incompatible Python 3.0 release
than a la
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> 3.0b1 has been released, so no new features can be added to 3.0.
While my proposal is no doubt going to cause a lot of code breakage, I
hardly consider it a "new feature". This is very definitely a bug. As I
understand it,
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Since I got a complaint that my last reply was too long, I'll summarize it.
It's a bug report, not a feature request.
I can't get a simple web app to be properly Unicode-aware in Python 3,
which worked fine in Python 2. T
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK I spent awhile writing test cases for quote and unquote, encoding and
decoding various Unicode strings with different encodings. As a result,
I found a bunch of issues in my previous patch, so I've rewritten the
patches to bot
New submission from Matt Giuca <[EMAIL PROTECTED]>:
urllib.robotparser is broken in Python 3.0, due to a bytes object
appearing where a str is expected.
Example:
>>> import urllib.robotparser
>>> r =
urllib.robotparser.RobotFileParser('http://www.python.org/robots
New submission from Matt Giuca <[EMAIL PROTECTED]>:
The wsgiref "simple server" module has a demo server, which fails to
start in Python 3.0 for a bunch of reasons.
To verify this, just go into the Lib/wsgiref directory, and run:
python3.0 ./simple_server.py
(which launches
Matt Giuca <[EMAIL PROTECTED]> added the comment:
So today I grepped for "urllib" in the entire library in an effort to
track down every dependency on quote and unquote to see exactly how my
patch breaks other code. I've now investigated every module in the
library which u
New submission from Matt McCredie <[EMAIL PROTECTED]>:
The following session demonstrates the issue:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more i
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Are you saying the stream passed to _write SHOULD always be a binary
stream, and hence the test case is wrong, because it opens a text stream?
(I'm not sure where the stream comes from, but we should guarantee it's
a binary str
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Wow, I read the WSGI spec. That seems very strange that it says "HTTP
does not directly support Unicode, and neither does this interface."
Clearly HTTP *does* support Unicode, because it allows you to specify an
encoding.
I assu
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK after a long discussion on the mailing list, Guido gave this the OK,
with the provision that there are str->bytes and bytes->str versions of
these functions as well. So I've written those.
http://mail.python.org/pipermail/pyt
New submission from Matt Giuca <[EMAIL PROTECTED]>:
The documentation for the "struct" module still uses the term "string"
even though the struct module itself deals entirely in bytes objects in
Python 3.0.
I propose updating the documentation to reflect the 3.0 ter
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Hmm ... seems patch 6 I just checked in fails a test case! Sorry! (It's
minor, gives a harmless BytesWarning if you run with -b, which "make
test" does, so I only picked it up after submitting).
I've slightly chang
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Thanks for the props!
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3478>
___
___
Python
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Dear GvR,
New code review comments by mgiuca have been published.
Please go to http://codereview.appspot.com/2827 to read them.
Message:
Hi Guido,
Thanks very much for this very detailed review. I've replied to the
comments. I wi
Matt Giuca <[EMAIL PROTECTED]> added the comment:
A reply to a point on GvR's review, I'd like to open for discussion.
This relates to whether or not quote's "safe" argument should allow
non-ASCII characters.
> Using errors='ignore' seems like a mis
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> The important is that the defaults are safe. If users want to override
> the defaults and produce potentially invalid URIs, there is no reason to
> discourage them.
OK I think that's a fairly valid argument. I'm about
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Following Guido and Antoine's reviews, I've written a new patch which
fixes *most* of the issues raised. The ones I didn't fix I have noted
below, and commented on the review site
(http://codereview.appspot.com/2827/). Note
Matt Giuca <[EMAIL PROTECTED]> added the comment:
I'm also attaching a "metapatch" - diff from patch 7 to patch 8. This is
to give a rough idea of what I changed since the review.
(Sorry - This is actually a diff between the two patches, so it's pretty
hard to read. I
New submission from Matt Giuca <[EMAIL PROTECTED]>:
I haven't been able to find a way to encode a bytes object in
hexadecimal, where in Python 2.x I'd go "str.encode('hex')".
I recommend adding a bytes.tohex() method (in the same vein as the
existing bytes.f
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> I recommend to use binascii.hexlify.
Ah, see I did not know about this! Thanks for pointing it out.
* However, it is *very* obscure. I've been using Python for a year and I
didn't know about it.
* And, it requires import
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Bill, I had a look at your patch. I see you've decided to make
quote_as_string the default? In that case, I don't know why you had to
rewrite everything to implement the same basic behaviour as my patch.
(My latest few patches su
Matt Giuca <[EMAIL PROTECTED]> added the comment:
You did the 3.1 thing again! We can accept a new feature like this
before 3.0b3, can we not?
> Hmm. There are probably many modules that you haven't used yet.
Snap :)
Well, I didn't know about the community's prefe
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> Bill's main concern is with a policy decision; I doubt he would
> object to using your code once that is resolved.
But his patch does the same basic operations as mine, just implemented
differently and with the heap of issues
Matt Giuca <[EMAIL PROTECTED]> added the comment:
I've been thinking more about the errors="strict" default. I think this
was Guido's suggestion. I've decided I'd rather stick with errors="replace".
I changed errors="replace" to errors=
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Guido suggested that quote's "safe" parameter should allow any
character, not just ASCII range. I've implemented this now. It was a lot
messier than I imagined.
The problem is that in my older patches, both 's&#
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Made a bunch of requested changes (I've reverted the "all safe" patch
for now since it caused so much grief; see above).
* quote: Fixed encoding illegal % sequences (and lots of new test cases
to prove it).
* quote now thr
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> Except, when we look at the context. This is bytes class
> method returns a bytes or bytearray object, decoding the given
> string object.
> Do we require an opposite in the bytes class method? Where will
> we use it?
No,
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> Invalid user input? What if the query string comes from filling
> a form?
> For example if I search the word "numéro" in a latin1 Web site,
> I get the following URL:
> http://www.le-tigre.net/spip.php?page=re
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Oh, where's the information on those?
(A brief search of the peps and bug tracker shows nothing).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK thanks.
Well I still can't really see what transform/untransform are about. Is
it OK to keep this issue open (and listed as 3.1) until more information
becomes available on those methods?
___
Matt Giuca <[EMAIL PROTECTED]> added the comment:
So I assumed.
In that case, why is there a "fromhex"? (Was that put in there before
the notion of transform/untransform?) As I've been saying, it's weird to
have a fromhex but not a tohex.
Anyway, assuming we g
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Bill, this debate is getting snipy, and going nowhere. We could argue
about what is the "pure" and "correct" thing to do, but we have a
limited time frame here, so I suggest we just look at the important facts.
1
Matt Giuca <[EMAIL PROTECTED]> added the comment:
By the way, what is the current status of this bug? Is anybody waiting
on me to do anything? (Re: Patch 9)
To recap my previous list of outstanding issues raised by the review:
> Should unquote accept a bytes/bytearray as well
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> I have no strong opinion on the very remaining points you listed,
> except that IMHO encode_rfc2231 with charset=None should not try to
> use UTF8 by default. But someone with more mail protocol skills
> should comment :)
O
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> I'm OK with replace for unquote() ...
> For quote() I think strict is better
There's just an odd inconsistency there, but it's only a tiny "gotcha";
and I agree with all your other arguments. I'
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Ah cheers Antoine, for the tip on using defaultdict (I was confused as
to how I could access the key just by passing defaultfactory, as the
manual suggests).
___
Python tracker <[EMAIL PROTECTE
Matt Giuca <[EMAIL PROTECTED]> added the comment:
OK I implemented the defaultdict solution. I got curious so ran some
rough speed tests, using the following code.
import random, urllib.parse
for i in range(0, 10):
str = ''.join(chr(random.randint(0, 0x10)) f
New submission from Matt Giuca <[EMAIL PROTECTED]>:
The test suite breaks on the Lib/test/test_uuid.py, as of r65661. This
is because uuid3 and uuid5 now raise exceptions.
TypeError: new() argument 1 must be bytes or read-only buffer, not bytearray
The problem is due to the changes in t
Matt Giuca <[EMAIL PROTECTED]> added the comment:
New patch (patch10). Details on Rietveld review tracker
(http://codereview.appspot.com/2827).
Another update on the remaining "outstanding issues":
Resolved issues since last time:
> Should unquote accept a bytes/bytearray a
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Antoine:
> I think if you move the line defining "str" out of the loop, relative
> timings should change quite a bit. Chances are that the random
> functions are not very fast, since they are written in pure Pytho
Matt Giuca <[EMAIL PROTECTED]> added the comment:
So are you saying that if I had libopenssl (or whatever the name is)
installed and linked with Python, it would bypass the use of _md5 and
_sha1, and call the hash functions in libopenssl instead? And all the
buildbots _do_ have it linked?
New submission from Matt Giuca <[EMAIL PROTECTED]>:
Continuing the discussion from Issue 3552
(http://bugs.python.org/issue3552).
r65676 makes changes to Modules/md5module.c and Modules/sha1module.c, to
allow them to read mutable buffers.
There's a segfault in sha1module if given
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Confirmed in HEAD for Python 2.6 and 3.0, on Linux.
Python 2.6b2+ (trunk:65708, Aug 16 2008, 15:04:13)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Python 3.0b2+ (py3k:65708, Aug 16 2008, 15:09:19)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu
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 l
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 "ch
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 PROTE
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
arra
Changes by Matt Giuca <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11122/doc+bytesmethods.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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
___
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, the
New submission from Matt Giuca <[EMAIL PROTECTED]>:
The Python 2.6 version of Demo/embed/Makefile builds against
libpython2.5.a, which doesn't exist in this version.
Quick patch to let it build against libpython2.6.a.
Commit log:
Fixed Demo/embed/Makefile to build against lib
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Hi,
Sorry to bump this, but you (Guido) said you wanted this closed by
Wednesday. Is this patch committable yet? (There are no more unresolved
issues that I am aware of).
___
Python tracker <[EMAIL
Matt Giuca <[EMAIL PROTECTED]> added the comment:
These functions are for generic MIME headers and bodies, so are
applicable to CGI, HTTP, Email, and any other protocols based on MIME.
So I think having them in email.header makes about as much sense as
having them in cgi.
Isn't
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Hi Dmitry,
RE the method behaviour: I think it probably is correct to NOT accept a
string. Given that it's base64 encoding it, it only makes sense to
encode bytes, not arbitrary Unicode characters which have no
well-defined binary rep
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Thanks for pointing that out, Antoine. I just commented on that bug.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matt Giuca <[EMAIL PROTECTED]> added the comment:
> > it should be renamed to encodestring
> Huh ? It is already called that :)
Um ... yes. I mean encodebytes :)
> > Best we can do is document them.
> Oh well.
But I don't know the rules. People are saying thing
Matt Giuca <[EMAIL PROTECTED]> added the comment:
A similar issue came up in another bug
(http://bugs.python.org/issue3613), and Guido said:
"IMO it's okay to add encodebytes(), but let's leave encodestring()
around with a deprecation warning, since it's so late in th
New submission from Matt Aasted <[EMAIL PROTECTED]>:
In current, future and past documentation, the valid escape sequence \0
(equivalent to \x00) is missing from the list of possible escape
sequences in the documentation. As far as I can tell, it is not a case
covered by any of the
Matt Giuca <[EMAIL PROTECTED]> added the comment:
It seems like parse_multipart and parse_header are very strongly related
to parse_qs. (eg. if you want to process HTTP requests you'll want to
call parse_qs for x-www-form-urlencoded and parse_multipart for
multipart/form-data).
Shou
Matt Chisholm <[EMAIL PROTECTED]> added the comment:
Any progress on this? This patch is extremely straightforward (only
three lines of code), and should not break existing code.
The HttpOnly extension to cookies is now supported by IE, Firefox 3.0,
and Opera.
This article explai
Matt Giuca <[EMAIL PROTECTED]> added the comment:
Can I just remind people that I have a documentation patch ready here
(and has been for about a month)?
Of course the doc+bytesmethods.patch may be debatable and probably too
late to go in 3.0. But you should be able to commit doc-only
Matt Chisholm <[EMAIL PROTECTED]> added the comment:
I have updated the diff to use reST for the docs. I removed the link to
MSDN from the reST docs because it is broken and I could not find the
article that it was intended to point to. I also slightly re-worded the
paragraph desc
New submission from Matt Giuca <[EMAIL PROTECTED]>:
A missing blank line under the heading for __bool__ in datamodel.rst (in
Python 3.0 docs) causes the following line to appear in the output HTML.
".. index:: single: __len__() (mapping object method)"
Visible here:
http://doc
New submission from Matt Giuca <[EMAIL PROTECTED]>:
The "special method names" section of the Python 3.0 documentation still
mentions the __div__ method. I believe this method has been totally
removed in Python 3 in favour of __truediv__. (Perhaps I am mistaken,
but 'int
New submission from Matt Giuca <[EMAIL PROTECTED]>:
I've noticed that in Python 3.0, the <, >, <= and >= operators now raise
a TypeError when comparing objects of different types, rather than
ordering them "consistently but arbitrarily". The documentation doesn&#
New submission from Matt Joiner :
When reading from the fileobj passed in it's constructor, zipfile.ZipExtFile
passes a long into fileobj.read(). This is not normally an issue, except in
io.BytesIO, for which the source is in C, and throws TypeError for
type(bufsize) != int.
>From wh
New submission from Matt Bandy :
Using the Py_ADDRESS_IN_RANGE macro can result in a crash under certain
threading conditions. Since it is intentionally possible for
(POOL)->arenaindex to reference memory which is not under Python's control,
another thread may modify that mem
Matt Bandy added the comment:
Amaury is correct -- in the case I observed, the other thread had nothing to do
with Python and was not calling Python functions that would have required
obtaining the GIL at any time (again, I'm using an embedded Python interpreter
in a larger app, no
Matt Bandy added the comment:
You can't add a block without changing the way the macro is used -- it's
usually used like:
if (Py_ADDRESS_IN_RANGE(p, pool))
This won't work with your proposed change since you can't put a do {} loop into
the test expression
Matt Bandy added the comment:
It's a pretty major limitation on the embedding case if you can't allow other
threads that aren't related to Python to run at any time that another thread
may be in obmalloc, and one I haven't seen documented anywhere. The only other
fix tha
Matt Bandy added the comment:
That should probably be:
#define Py_ADDRESS_IN_RANGE(P, POOL)\
((x = (POOL)->arenaindex) < maxarenas &&\
(uptr)(P) - arenas[x].address < (uptr)ARENA_SIZE && \
arenas[x].address
Matt Bandy added the comment:
I tried this out in VC++ 2008 with the new temporary as both a global variable
and a local. At least for VC++, Amaury is correct -- the compiler is
generating the store to the global even though it is never read, so making it a
local instead does save an
Matt Bandy added the comment:
Sorry, I should have been more precise. I did use static for the variable I
declared at file scope. Looking at the disassembly again also reminded me of
something I should have mentioned in the original bug report: at least when
using Visual C++ 2008, in the
New submission from Matt Gattis :
If you do:
import io,mmap
b = io.BytesIO("abc")
m = mmap.mmap(-1,10)
m.seek(5)
b.readinto(m)
M is now:
'abc\x00\x00\x00\x00\x00\x00\x00'
Basically there is no way to readinto/recv_into an arbitary position in an mmap
object without c
New submission from Matt Gattis :
>>> view = memoryview(bytearray(bufsize))
>>> while len(view):
...view = view[sock.recv_into(view,1024):]
...
Traceback (most recent call last):
File "", line 2, in
TypeError: recv_into() argument 1 must be p
Matt Giuca added the comment:
I've finally gotten around to a complete analysis of this code. I have a
code/test/documentation patch which fixes the issue without any code breakage.
There is another bug in quote which I've found and fixed with this patch: If
the 'safe'
New submission from Matt Giuca :
urllib.unquote fails to decode a percent-escape with mixed case. To demonstrate:
>>> unquote("%fc")
'\xfc'
>>> unquote("%FC")
'\xfc'
>>> unquote("%Fc")
'%Fc'
>>> u
New submission from Matt Giuca :
The 'unquote' function has some very strange behaviour on Unicode input. My
proposed fix will, I am sure, be contentious, because it could change existing
behaviour (only on unicode strings), but I think it's worth it for a sane
unquote
Matt Giuca added the comment:
Alternative patch which fixes test cases and documentation without changing the
behaviour.
--
Added file: http://bugs.python.org/file16542/urllib-unquote-explain.patch
___
Python tracker
<http://bugs.python.
Changes by Matt Giuca :
Removed file: http://bugs.python.org/file16542/urllib-unquote-explain.patch
___
Python tracker
<http://bugs.python.org/issue8136>
___
___
Pytho
Matt Giuca added the comment:
New version of "explain" patch -- fixed comment linking to the wrong bug ID --
now links to this bug ID (#8136).
--
Added file: http://bugs.python.org/file16545/urllib-unquote-explain.patch
___
Python trac
Matt Giuca added the comment:
> Note: I've also backported the remainder of the 'unquote' test cases
> from Python 3 but I found another bug, so I will report that separately,
> with a patch.
Filed under issue #8136.
--
_
New submission from Matt Giuca :
urlparse contains a complete copy of the urllib.unquote function. This is
extremely nasty code duplication -- I have two patches pending on
urllib.unquote (#8135 and #8136) and I only just realised that I missed
urlparse.unquote!
The reason given for this is
101 - 200 of 595 matches
Mail list logo
