[issue1432] Strange behavior of urlparse.urljoin

[Senthil]

Senthil added the comment:

If we observe carefully in the urlparse.py and test_urlparse.py, over
the releases from Python 2.3 to Python 2.6, the changes required for
supporting RFC2396 has been implemented. (RFC2396 replaced 1808 in URL
Specification.)
But the header of urlparse.py still says it is according to RFC1808
only. *This needs to be changed.*
In the test_urlparse.py we find test cases for RFC2396 compliance as well.

In this specific bug report, we are upon a case where the later
Specification is not compatible with older one.

As per RFC1808
Base: http://a/b/c/d;p?q#f>

Relative URL resolution:
?y = http://a/b/c/d;p?y>
;x = http://a/b/c/d;x>

As per RFC2396
Base: http://a/b/c/d;p?q

Relative URLS:
?y=  http://a/b/c/?y
;x=  http://a/b/c/;x

Do you see the difference?
urlparse.py has been made RFC2396 compliance, so that above incompatible
test has been removed as well.

Now, even RFC2396 is obsolete and has been superseded by RFC3986
which advertises thus:

Base: http://a/b/c/d;p?q

Relative URL:

"?y"=  "http://a/b/c/d;p?y";
";x"=  "http://a/b/c/;x";

this is crazy, the first ?y goes for  older RFC1808 result and second ;x
is in the later RFC2396.

For the just this issue my take would be:
1) Make the current urlparse.py compliant with RFC2396. Remove the claim
that it is compliant with 1808 only. Which is a documentation fix (patch
attached)

Overall and the best solution will be RFC3986 compliance, which is a
separate effort.

Added file: http://bugs.python.org/file9035/urlparse.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Lib/test/test_urlparse.py
===
--- Lib/test/test_urlparse.py	(revision 59600)
+++ Lib/test/test_urlparse.py	(working copy)
@@ -164,6 +164,12 @@
 #self.checkJoin(RFC1808_BASE, 'http:g', 'http:g')
 #self.checkJoin(RFC1808_BASE, 'http:', 'http:')
 
+# RFC 2396 has different behaviour for the following.
+# So RFC 1808 compliance for these cases is not present, but rather
+# RFC 2396 specification is followed (see the tests under 2396)
+# self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/d;p?y')
+# self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/d;x')
+
 def test_RFC2396(self):
 # cases from RFC 2396
 
Index: Lib/urlparse.py
===
--- Lib/urlparse.py	(revision 59600)
+++ Lib/urlparse.py	(working copy)
@@ -2,6 +2,14 @@
 
 See RFC 1808: "Relative Uniform Resource Locators", by R. Fielding,
 UC Irvine, June 1995.
+
+Update: The module has also been updated to satisfy the changes suggested
+in RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax", 
+August, 1998.
+
+Changes specified in RFC 3986:"Uniform Resource Identifiers (URI): Generic
+Syntax", January 2005 not implemented yet.
+
 """
 
 __all__ = ["urlparse", "urlunparse", "urljoin", "urldefrag",
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2

[Vlastimil Brom]

Vlastimil Brom added the comment:

First sorry about a delayed response, but moreover, I fear, preparing a 
patch would be far beyond my programming competence; sorry about that.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1699] unconditional definiton of _BSD_SOURCE breaks builds with g++-4.3

[Martin v. Löwis]

Martin v. Löwis added the comment:

I opted for conditionalizing it to OpenBSD; it was wrong on Linux,
anyway, as _BSD_SOURCE has a different meaning there.

Fixed in r59610 and r59611.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue1706] Force WINVER 0x0500 (Windows 2000)

[Martin v. Löwis]

Martin v. Löwis added the comment:

"The macros don't restrain us to Win2k but they prevent us from using
APIs which are not compatible with Windows 2000." --- That's what I
meant by "constrain"/restrain: we can't use API that was added in XP
directly. For functions, that is a good thing, because the binary
wouldn't work on W2k. For enumeration values and structure definition,
it's a bad thing, as we would need to duplicate them if we wanted to
call the functions dyanmically that take such values.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1704] possible bug in randint

[Rich Marinaccio]

Rich Marinaccio added the comment:

What was happening before was I was getting an index out of range error 
every so often, so then I put in the ValueError catch to see what was 
going on. I was surprised to see that randIndex was the same as len
(preshuffle). I have some further catches in place now that might tell 
me more. It must have to do with deleting items from the list in the 
loop and not getting the right length from len immediately after, but 
then again I use this algorithm in several places in my module with no 
trouble, though with smaller lists. Go ahead and close this, and when I 
have more information I can open it some other time. This bug I'm 
seeing is extremely intermittant.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1704] possible bug in randint

[Raymond Hettinger]

Raymond Hettinger added the comment:

Attaching the whole file isn't a step in the right direction.  The 
preferred approach is to isolate the problem as tightly as possible.

This report is dubious because, I can't get the following to fail:

from random import seed, randint
seed('mystart')
while 1:
   assert 0 <= randint(0, 1452) <= 1452

There is also no failure with:

preshuffle = [None] * 1453
while 1:
   assert 0 <= randint(0, len(preshuffle)-1) <= 1452

Make sure that PWRand.randint() really does call randint() and not 
randrange() and that it doesn't adjust the range of inputs.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1704] possible bug in randint

[Rich Marinaccio]

Rich Marinaccio added the comment:

To be clear, I am not using multi-threading in my particular module. I 
can't explain this behavior with my code alone. The issue is 
complicated by the fact that my module is called by Civ IV, and I have 
no idea what the game is doing behind the scenes. I also don't know 
exactly what happens when 'del myList[index]' is called. You would 
think that len(preshuffle) would have the same value for the randint 
call that it does for the print statement. I have an idea for another 
test I would like to try.

This is my first issue that I've reported in Python. Would it help for 
me to attach the whole file?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1706] Force WINVER 0x0500 (Windows 2000)

[Christian Heimes]

Christian Heimes added the comment:

The macros don't restrain us to Win2k but they prevent us from using
APIs which are not compatible with Windows 2000. It's a compile time
option to conditionally exclude new features from the header files.

#ifndef NTDDI_VERSION
#define NTDDI_VERSION NTDDI_WIN2KSP4
#endif
#ifndef WINVER
#define WINVER 0x0500
#endif
#ifndef _WIN32_WINNT
#define _WIN32_WINNT WINVER
#endif

__
Tracker <[EMAIL PROTECTED]>

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