[ python-Bugs-1647037 ] cookielib.CookieJar does not handle cookies when port in url
Bugs item #1647037, was opened at 2007-01-29 12:31
Message generated for change (Comment added) made by tools-sts
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647037&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: Python Library
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: STS (tools-sts)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib.CookieJar does not handle cookies when port in url
Initial Comment:
In Python 2.5 the cookielib.CookieJar does not handle cookies (i.e., recognise
the Set-Cookie: header) when the port is specified in the URL.
e.g.,
import urllib2, cookielib
cookiejar = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
# add proxy to view results
proxy_handler = urllib2.ProxyHandler({'http':'127.0.0.1:8080'})
opener.add_handler(proxy_handler)
# Install opener globally so it can be used with urllib2.
urllib2.install_opener(opener)
# The ':80' will cause the CookieJar to never handle the
# cookie set by Google
request = urllib2.Request('http://www.google.com.au:80/')
response = opener.open(request)
response = opener.open(request) # No Cookie:
# But this works
request = urllib2.Request('http://www.google.com.au/')
response = opener.open(request)
response = opener.open(request)# Cookie: PREF=ID=d2de0..
--
>Comment By: STS (tools-sts)
Date: 2007-02-01 12:10
Message:
Logged In: YES
user_id=1693551
Originator: YES
You're right! I will close this now...Sorry about that. Also, thanks for
the logging/DEBUG code this will be very useful going forward.
--
Comment By: John J Lee (jjlee)
Date: 2007-02-01 00:17
Message:
Logged In: YES
user_id=261020
Originator: NO
This is not a bug. If you turn on cookielib logging (see below), you'll
see that Google sends back a cookie for google.com (not .com.au) on the
first request iff you add the port number. That cookie should not be sent
back to the server. My copy of Firefox 1.5.0.9 doesn't send back a cookie
here either.
(note they do send a .com.au cookie when you do a search, presumably
because the search button lands you at a URL without the :80 on the end.
It's probably just a minor oversight or an optimisation that they don't
send the .com.au cookie when you include the :80)
To turn on logging:
import sys, logging
logger = logging.getLogger("cookielib")
logger.addHandler(logging.StreamHandler(sys.stdout))
logger.setLevel(logging.DEBUG)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647037&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650053 ] decimals compare badly to floats
Bugs item #1650053, was opened at 2007-02-01 19:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Sutherland (jinty_)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimals compare badly to floats
Initial Comment:
This behaviour is so unexpected that I'm pretty sure it's a bug. If decimals
can't be compared to floats, at least it should error.
Found in python2.4 and 2.5 by at least 2 people:
Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> 1172837167.27 > Decimal("1172837136.0800")
False
>>> 1172837167.27 > Decimal("1")
False
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Thomas Heller (theller) Date: 2007-02-01 20:12 Message: Logged In: YES user_id=11105 Originator: NO Martin, -lgcc alone does not work, I had to specify library_dirs. Linking is done with 'ld -l' by default. How do I specify that gcc should be used for linking (and should I expect 'configure' to determine this correctly)? Is it a bug in 'configure'? Ok: when I export LDSHARED="gcc -shared", than do configure and make the missing symbol error disappears, even without using -lgcc. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-31 22:58 Message: Logged In: YES user_id=21627 Originator: NO Thomas, the libgcc problem might be a gcc installation problem. Just specifying -lgcc should be enough to get libgcc linked in. Furthermore, depending on how the linking is done (gcc -shared?), it shouldn't be necessary *at all* to provide -lgcc. This isn't so much a HPUX question but more a gcc question: if you link with gcc, it *ought* to work (if you link with ld(1), you are on your own). -- Comment By: Thomas Heller (theller) Date: 2007-01-31 22:00 Message: Logged In: YES user_id=11105 Originator: NO I did also try the Python 2.5 release tarball and could not reproduce the bug. Machine info: bash-3.00$ uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license bash-3.00$ gcc --version gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.00$ ./python Python 2.5 (r25:51908, Jan 31 2007, 15:56:22) [GCC 3.4.3] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> bash-3.00$ -- Comment By: Thomas Heller (theller) Date: 2007-01-31 21:15 Message: Logged In: YES user_id=11105 Originator: NO I finally found time (and energy) to try out the td176 HPUX host on HP testdrive. I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built it with the installed gcc 3.4.3. First, I got errors in the ctypes tests because the _ctypes_test extension/shared library could not be loaded because of a missing symbol __divsf3. Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html which mentions a GCC runtime library libgcc.a (see the link 'soft float library routines' on ths page). When this library is specified when building _ctypes_test.so, all ctypes unittests pass. Without any crash. It is strange, to link against the libgcc.a library it seems needed to specify the location of the library '/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX guru provide some insight? The attached patch to setup.py is what was needed, but it is a hack of course. File Added: setup.py.patch -- Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the failure when importing ctypes.test.test_cfuncs it seems that a library (?) is missing that _ctypes_test.so requires. Any idea? (I know that HP offers shell access to HPUX boxes, but I hesitate to try that out...). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 03:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x200079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/M
[ python-Bugs-1650090 ] doctest doesn't find nested functions
Bugs item #1650090, was opened at 2007-02-01 20:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Brown (danb37)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest doesn't find nested functions
Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
'''
>>> 'a'
'a'
'''
def g():
'''
>>> 'a'
'b'
'''
pass
pass
}}}
DocTestFinder will only find f's doctest and won't recurse to find g's,
surprising the programmer when they (hopefully) discover that their inner
doctest is incorrect!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-01 20:54 Message: Logged In: YES user_id=21627 Originator: NO configure.in sets LDSHARED to "ld -b" around line 1477. Whether this is a bug, I don't know - there may have been HP-UX systems where this was the proper way of doing things. These days, on most systems (not sure whether this includes HP-UX), direct linking with ld is discouraged; one should use the C compiler for linking. Unless somebody steps in and can tell the full story, I would advise to use $(CC) for linking on HPUX if the compiler is gcc (see SunOS processing as to how to determine gcc). -- Comment By: Thomas Heller (theller) Date: 2007-02-01 20:12 Message: Logged In: YES user_id=11105 Originator: NO Martin, -lgcc alone does not work, I had to specify library_dirs. Linking is done with 'ld -l' by default. How do I specify that gcc should be used for linking (and should I expect 'configure' to determine this correctly)? Is it a bug in 'configure'? Ok: when I export LDSHARED="gcc -shared", than do configure and make the missing symbol error disappears, even without using -lgcc. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-31 22:58 Message: Logged In: YES user_id=21627 Originator: NO Thomas, the libgcc problem might be a gcc installation problem. Just specifying -lgcc should be enough to get libgcc linked in. Furthermore, depending on how the linking is done (gcc -shared?), it shouldn't be necessary *at all* to provide -lgcc. This isn't so much a HPUX question but more a gcc question: if you link with gcc, it *ought* to work (if you link with ld(1), you are on your own). -- Comment By: Thomas Heller (theller) Date: 2007-01-31 22:00 Message: Logged In: YES user_id=11105 Originator: NO I did also try the Python 2.5 release tarball and could not reproduce the bug. Machine info: bash-3.00$ uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license bash-3.00$ gcc --version gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.00$ ./python Python 2.5 (r25:51908, Jan 31 2007, 15:56:22) [GCC 3.4.3] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> bash-3.00$ -- Comment By: Thomas Heller (theller) Date: 2007-01-31 21:15 Message: Logged In: YES user_id=11105 Originator: NO I finally found time (and energy) to try out the td176 HPUX host on HP testdrive. I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built it with the installed gcc 3.4.3. First, I got errors in the ctypes tests because the _ctypes_test extension/shared library could not be loaded because of a missing symbol __divsf3. Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html which mentions a GCC runtime library libgcc.a (see the link 'soft float library routines' on ths page). When this library is specified when building _ctypes_test.so, all ctypes unittests pass. Without any crash. It is strange, to link against the libgcc.a library it seems needed to specify the location of the library '/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX guru provide some insight? The attached patch to setup.py is what was needed, but it is a hack of course. File Added: setup.py.patch -- Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the fail
[ python-Bugs-1650053 ] decimals compare badly to floats
Bugs item #1650053, was opened at 2007-02-01 13:20
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&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: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Sutherland (jinty_)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: decimals compare badly to floats
Initial Comment:
This behaviour is so unexpected that I'm pretty sure it's a bug. If decimals
can't be compared to floats, at least it should error.
Found in python2.4 and 2.5 by at least 2 people:
Python 2.5 (release25-maint, Dec 9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> 1172837167.27 > Decimal("1172837136.0800")
False
>>> 1172837167.27 > Decimal("1")
False
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 15:24
Message:
Logged In: YES
user_id=80475
Originator: NO
It was intended that Decimals not be compared to floats, but I think we
can do better than returning a useless result
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648179 ] set update problem with class derived from dict
Bugs item #1648179, was opened at 2007-01-30 15:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&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: None Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: duncan (urubu147) Assigned to: Raymond Hettinger (rhettinger) Summary: set update problem with class derived from dict Initial Comment: Class derived from dict with __iter__ method returning itervalues() has keys (rather than values) added to set when using set update method. Works as expected in 2.4. Windows XP (Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32). Unsure of platform for Peter Otten's minimal example in (hopefully) attached file. Duncan Smith -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-02-01 16:04 Message: Logged In: YES user_id=80475 Originator: NO Fixed. See versions 53616 and 53617. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574217 ] isinstance swallows exceptions
Bugs item #1574217, was opened at 2006-10-09 21:55
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Brian Harring (ferringb)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: isinstance swallows exceptions
Initial Comment:
Attached is a simple example; yes, a bit contrived, but
it's exactly what bit me in the ass for a week or two :)
nestled within abstract.c's recursive_isinstance, is
this lil nugget-
icls = PyObject_GetAttr(inst, __class__);
if (icls == NULL) {
PyErr_Clear();
retval = 0;
}
else {
No surrouding comments to indicate *why* it's
swallowing exceptions, but best explanation I've heard
was that it was attempting to swallow just
AttributeError... which would make sense.
So the question is, whats the purpose of it swallowing
exceptions there? Bad form of AttributeError catching,
or some unstated reason?
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 16:05
Message:
Logged In: YES
user_id=80475
Originator: NO
Neal, do you have time to look at this one?
--
Comment By: Brian Harring (ferringb)
Date: 2006-11-04 23:06
Message:
Logged In: YES
user_id=874085
quicky patch for this; basically, wipe the exception only if
it's AttributeError, else let it bubble it's way up.
--
Comment By: Brian Harring (ferringb)
Date: 2006-10-09 21:56
Message:
Logged In: YES
user_id=874085
addition note; this is both 2.5 and 2.4, probably stretches
bit further back also.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574217 ] isinstance swallows exceptions
Bugs item #1574217, was opened at 2006-10-09 19:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Brian Harring (ferringb)
Assigned to: Neal Norwitz (nnorwitz)
Summary: isinstance swallows exceptions
Initial Comment:
Attached is a simple example; yes, a bit contrived, but
it's exactly what bit me in the ass for a week or two :)
nestled within abstract.c's recursive_isinstance, is
this lil nugget-
icls = PyObject_GetAttr(inst, __class__);
if (icls == NULL) {
PyErr_Clear();
retval = 0;
}
else {
No surrouding comments to indicate *why* it's
swallowing exceptions, but best explanation I've heard
was that it was attempting to swallow just
AttributeError... which would make sense.
So the question is, whats the purpose of it swallowing
exceptions there? Bad form of AttributeError catching,
or some unstated reason?
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-01 17:00
Message:
Logged In: YES
user_id=33168
Originator: NO
Possibly in a week or so. It's unlikely I'll get to it sooner.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 13:05
Message:
Logged In: YES
user_id=80475
Originator: NO
Neal, do you have time to look at this one?
--
Comment By: Brian Harring (ferringb)
Date: 2006-11-04 20:06
Message:
Logged In: YES
user_id=874085
quicky patch for this; basically, wipe the exception only if
it's AttributeError, else let it bubble it's way up.
--
Comment By: Brian Harring (ferringb)
Date: 2006-10-09 19:56
Message:
Logged In: YES
user_id=874085
addition note; this is both 2.5 and 2.4, probably stretches
bit further back also.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
