[ python-Bugs-1448490 ] Convertion error for latin1 characters with iso-2022-jp-2
Bugs item #1448490, was opened at 2006-03-13 06:57 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448490&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Francois Duranleau (duranlef) >Assigned to: Hye-Shik Chang (perky) Summary: Convertion error for latin1 characters with iso-2022-jp-2 Initial Comment: It seems like there are some errors while reading a text file encoded with ISO-2022-JP-2 using the codecs module. In all my test cases, all latin1 characters with an accent (e.g. e acute) do not appear in the output string. However, if I convert the file manually using iconv, I get everything right. Here is a simple script that will illustrate the problem: ### import codecs import pygtk import gtk f = codecs.open( "test.iso-2022-jp-2" , "r" , \ "iso-2022-jp-2" ) s1 = f.readline().strip() f.close() f = open( "test.utf-8" , "r" ) s2 = f.readline().strip() pack = gtk.VBox() pack.pack_start( gtk.Label( s1 ) ) pack.pack_start( gtk.Label( s2 ) ) window = gtk.Window( gtk.WINDOW_TOPLEVEL ) window.add( pack ) window.show_all() def event_destroy( widget , event , data ) : gtk.main_quit() return 0 window.connect( "delete_event" , \ lambda w,e,d: False , None ) window.connect( "destroy" , event_destroy , None ) gtk.main() ### I put the file "test.iso-2022-jp-2" in attachment. To create the UTF-8 version of the file, I used the following shell command: iconv -f ISO-2022-JP-2 -t UTF-8 \ test.iso-2022-jp-2 > test.utf-8 When running this script, I would actually expect a window with two times the same label. However, the first one is missing the e acute. -- Francois -- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-13 19:27 Message: Logged In: YES user_id=55188 Fixed in SVN (trunk:r42989, release24-maint:42991). Thank you for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448804 ] Subscript operations generating incorrect code
Bugs item #1448804, was opened at 2006-03-13 22:09 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=1448804&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: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nick Coghlan (ncoghlan) Summary: Subscript operations generating incorrect code Initial Comment: As noted by Travis Oliphant on python-dev, subscript operations on the HEAD are not always generating the actual subscript operation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448804 ] Subscript operations generating incorrect code
Bugs item #1448804, was opened at 2006-03-13 22:09 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448804&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nick Coghlan (ncoghlan) Summary: Subscript operations generating incorrect code Initial Comment: As noted by Travis Oliphant on python-dev, subscript operations on the HEAD are not always generating the actual subscript operation. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-13 22:32 Message: Logged In: YES user_id=1038590 Fixed (and test added) in SVN rev 42998 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448934 ] urllib2+https+proxy not working
Bugs item #1448934, was opened at 2006-03-13 15:55 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=1448934&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: 5 Submitted By: Rui Martins (ruibmartins) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2+https+proxy not working Initial Comment: Using urllib2 to access an https site using a proxy doesn't work. It always returns " " I've been looking around for bug reports on this and code samples, but all that I've got were emails/forum posts dating back to 2003 warning that the HTTPS over Proxy in urllib2 isn't implemented in Python! Is this true? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448934&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Bugs item #1448640, was opened at 2006-03-13 04:54 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.__init__ cannot be overridden Initial Comment: Hi The following code does not work properly: #!/usr/bin/env python """ Test overriding constructor of datetime classes. """ import sys, datetime class MyDate(datetime.date): def __init__( self, year, month, day ): print >> sys.stderr, 'lose data' d = MyDate(2006, 11, 29) print d class MyDate(datetime.date): def __new__( self, year, month, day ): print 'lose data' def __init__( self, year, month, day ): print 'lose data again' d = MyDate(2006, 11, 29) print d The output is: lose data 2006-11-29 lose data None The problem is that the initialization of the object is done in its time_new() method which is registered for __new__ rather than using an __init__ method. This prevent one from overriding the date/datetime/time constructors. cheers, -- Comment By: splitscreen (splitscreen) Date: 2006-03-13 15:40 Message: Logged In: YES user_id=1126061 Isn't this an abuse of __new__ ? Taken from the documentation: "__new__ must return an object. There's nothing that requires that it return a new object that is an instance of its class argument, although that is the convention. If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called. If you forget to return something, Python will unhelpfully return None, and your caller will probably be very confused." So, you're actually calling __init__ with None? Or have i misunderstood? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Bugs item #1448640, was opened at 2006-03-13 04:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin Blais (blais) >Assigned to: Michael Hudson (mwh) Summary: datetime.__init__ cannot be overridden Initial Comment: Hi The following code does not work properly: #!/usr/bin/env python """ Test overriding constructor of datetime classes. """ import sys, datetime class MyDate(datetime.date): def __init__( self, year, month, day ): print >> sys.stderr, 'lose data' d = MyDate(2006, 11, 29) print d class MyDate(datetime.date): def __new__( self, year, month, day ): print 'lose data' def __init__( self, year, month, day ): print 'lose data again' d = MyDate(2006, 11, 29) print d The output is: lose data 2006-11-29 lose data None The problem is that the initialization of the object is done in its time_new() method which is registered for __new__ rather than using an __init__ method. This prevent one from overriding the date/datetime/time constructors. cheers, -- >Comment By: Michael Hudson (mwh) Date: 2006-03-13 16:42 Message: Logged In: YES user_id=6656 datetime.date objects are immutable, so this is the same as not being able to override __init__ in a subclass of int. Override __new__ instead. -- Comment By: splitscreen (splitscreen) Date: 2006-03-13 15:40 Message: Logged In: YES user_id=1126061 Isn't this an abuse of __new__ ? Taken from the documentation: "__new__ must return an object. There's nothing that requires that it return a new object that is an instance of its class argument, although that is the convention. If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called. If you forget to return something, Python will unhelpfully return None, and your caller will probably be very confused." So, you're actually calling __init__ with None? Or have i misunderstood? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Bugs item #1436428, was opened at 2006-02-22 07:03 Message generated for change (Comment added) made by shadowmorpher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: 5 Submitted By: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan -- Comment By: Koen van de Sande (shadowmorpher) Date: 2006-03-13 20:19 Message: Logged In: YES user_id=270334 Why should the URL lib module support opening of local files? It already does so through the file: protocol prefix, and do not see why it should support automatic detection of Windows filenames. AFAIK it does not do automatic detection of Unix filenames (one could recognize it from /home/ something), so why would Windows work differently? I'm not an expert or anything, so I might be wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Bugs item #1448640, was opened at 2006-03-13 04:54 Message generated for change (Comment added) made by blais You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Michael Hudson (mwh) Summary: datetime.__init__ cannot be overridden Initial Comment: Hi The following code does not work properly: #!/usr/bin/env python """ Test overriding constructor of datetime classes. """ import sys, datetime class MyDate(datetime.date): def __init__( self, year, month, day ): print >> sys.stderr, 'lose data' d = MyDate(2006, 11, 29) print d class MyDate(datetime.date): def __new__( self, year, month, day ): print 'lose data' def __init__( self, year, month, day ): print 'lose data again' d = MyDate(2006, 11, 29) print d The output is: lose data 2006-11-29 lose data None The problem is that the initialization of the object is done in its time_new() method which is registered for __new__ rather than using an __init__ method. This prevent one from overriding the date/datetime/time constructors. cheers, -- >Comment By: Martin Blais (blais) Date: 2006-03-13 21:45 Message: Logged In: YES user_id=10996 H... that's not quite true. If I derive from datetime in order to add new data members (e.g. in my case I add "seq" which is used as a sequence number on top of datetime for storing the names of photographs, the sequence number is in case I have a panorama or multiple photographs in burst mode--all within one second), I might want a different constructor. I tried overriding __new__ and had some troubles, cannot remember what exactly, will reproduce and send code soon. -- Comment By: Michael Hudson (mwh) Date: 2006-03-13 16:42 Message: Logged In: YES user_id=6656 datetime.date objects are immutable, so this is the same as not being able to override __init__ in a subclass of int. Override __new__ instead. -- Comment By: splitscreen (splitscreen) Date: 2006-03-13 15:40 Message: Logged In: YES user_id=1126061 Isn't this an abuse of __new__ ? Taken from the documentation: "__new__ must return an object. There's nothing that requires that it return a new object that is an instance of its class argument, although that is the convention. If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called. If you forget to return something, Python will unhelpfully return None, and your caller will probably be very confused." So, you're actually calling __init__ with None? Or have i misunderstood? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Bugs item #1436428, was opened at 2006-02-21 22:03 Message generated for change (Comment added) made by dpeastman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: 5 Submitted By: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan -- >Comment By: Donovan Eastman (dpeastman) Date: 2006-03-13 17:56 Message: Logged In: YES user_id=757799 Reasons why urllib should open local files: 1) This allows you to write code that handles local files and Internet files equally well -- without having to do any special magic of your own. 2) The docs all say that it should. I believe this would work just fine under Unix. In URLopener.open() it looks for the protocol prefix and if it can't find one, it assumes that it is a local file. The problem on Windows is that you have these pesky drive letters. The form 'C:\location' ends up looking a lot like the form 'http://location'. Therefore it looks for a protocol called 'c' -- which obviously isn't going to work. -- Comment By: Koen van de Sande (shadowmorpher) Date: 2006-03-13 11:19 Message: Logged In: YES user_id=270334 Why should the URL lib module support opening of local files? It already does so through the file: protocol prefix, and do not see why it should support automatic detection of Windows filenames. AFAIK it does not do automatic detection of Unix filenames (one could recognize it from /home/ something), so why would Windows work differently? I'm not an expert or anything, so I might be wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPES_ACTIONS
Bugs item #1449311, was opened at 2006-03-13 18:07
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=1449311&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse: extending actions missing ALWAYS_TYPES_ACTIONS
Initial Comment:
http://docs.python.org/lib/optparse-adding-new-actions.
html
This page of docs should include the ALWAYS_TYPED_
ACTIONS list from optparse.py. In the example, unless
you add the following line:
ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS
+ ("dict",)
, then the "Value" variable gets no value unless you
explicitly pass "type='string'" to parser.add_option().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Bugs item #1436428, was opened at 2006-02-21 22:03 Message generated for change (Comment added) made by dpeastman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: 5 Submitted By: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan -- >Comment By: Donovan Eastman (dpeastman) Date: 2006-03-13 18:32 Message: Logged In: YES user_id=757799 OK - Here's my suggested fix: This can be fixed with a single if statement (and a comment to explain it to confused unix programmers). In splittype(), right after the line that reads: scheme = match.group(1) add the following: #ignore single char schemes to avoid confusion with win32 drive letters if len(scheme) > 1: ...and indent the next line. Alternatively, the if statement could read: if len(scheme) > 1 or sys.platform != 'win32': ...which would allow single letter scheme names on non-Windows systems. I would argue that it is better to be consistent and have it work the same way on all OS's. -- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-13 17:56 Message: Logged In: YES user_id=757799 Reasons why urllib should open local files: 1) This allows you to write code that handles local files and Internet files equally well -- without having to do any special magic of your own. 2) The docs all say that it should. I believe this would work just fine under Unix. In URLopener.open() it looks for the protocol prefix and if it can't find one, it assumes that it is a local file. The problem on Windows is that you have these pesky drive letters. The form 'C:\location' ends up looking a lot like the form 'http://location'. Therefore it looks for a protocol called 'c' -- which obviously isn't going to work. -- Comment By: Koen van de Sande (shadowmorpher) Date: 2006-03-13 11:19 Message: Logged In: YES user_id=270334 Why should the URL lib module support opening of local files? It already does so through the file: protocol prefix, and do not see why it should support automatic detection of Windows filenames. AFAIK it does not do automatic detection of Unix filenames (one could recognize it from /home/ something), so why would Windows work differently? I'm not an expert or anything, so I might be wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Bugs item #1448058, was opened at 2006-03-11 15:19 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: aix-d (aix-d) Assigned to: Nobody/Anonymous (nobody) Summary: problems with too many sockets in FreeBSD Initial Comment: When there are about 200 sockets, or so, i'm getting errors: "unable to select on socket" We are running multithread application, for each thread there is one socket. TRACEBACK contains: r = self.connection.recv(1024) error: unable to select on socket. This error appeared after fixing this problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470 Python version: 2.5a0 (trunk, Mar 8 2006, 18:28:30) OS version: FreeBSD 6.1-PRERELEASE Soon we will make program that will reproduce this error if needed. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-13 23:37 Message: Logged In: YES user_id=33168 What is the value of FD_SETSIZE? Perhaps you should increase this value before including any headers on FreeBSD? If you are using a lot of sockets, you may prefer to use poll() instead of select() as poll() doesn't have the FD_SETSIZE limitation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449397 ] urllib2+https+proxy not working
Bugs item #1449397, was opened at 2006-03-14 07:50 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=1449397&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: 5 Submitted By: Rui Martins (ruibmartins) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2+https+proxy not working Initial Comment: Using urllib2 to access an https site using a proxy doesn't work. It always returns " " I've been looking around for bug reports on this and code samples, but all that I've got were emails/forum posts dating back to 2003 warning that the HTTPS over Proxy in urllib2 isn't implemented in Python! Is this true? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449397&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449397 ] urllib2+https+proxy not working
Bugs item #1449397, was opened at 2006-03-14 07:50 Message generated for change (Settings changed) made by ruibmartins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449397&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: Deleted Resolution: None Priority: 5 Submitted By: Rui Martins (ruibmartins) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2+https+proxy not working Initial Comment: Using urllib2 to access an https site using a proxy doesn't work. It always returns " " I've been looking around for bug reports on this and code samples, but all that I've got were emails/forum posts dating back to 2003 warning that the HTTPS over Proxy in urllib2 isn't implemented in Python! Is this true? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449397&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
