[ python-Feature Requests-1599329 ] urllib(2) should allow automatic decoding by charset
Feature Requests item #1599329, was opened at 2006-11-19 20:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: urllib(2) should allow automatic decoding by charset Initial Comment: Currently, urllib.urlopen(...).read() returns a string, not a unicode object. Ditto for urllib2. No attempt is made to decode the data using the charset encoding specified in the header info()['Content-Type']. Is it fair to assume that, in Python 3K, urllibread() will return (Unicode) strings instead of bytes, automatically decoding according to the charset? Do you think we could expose this futuristic functionality in Python 2? I doubt we could change read() without breaking a lot of existing code that already does this decoding (e.g., http://zesty.ca/python/scrape.py), but perhaps a 'uread()' method could return a unicode object instead of a string. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-22 07:57 Message: Logged In: YES user_id=21627 Originator: NO I don't think urlopen(...).read() should return strings in Py3k, but instead it should return bytes - in general, resources retrieved are byte sequences (many are application/octet-stream). Making the return type depend on the resource being fetched is also unintuitive. It might be reasonable to have the user specified "binary" or "text" on urlopen() (just like regular open()). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically
Bugs item #1600860, was opened at 2006-11-22 01:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-22 08:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
