[ python-Bugs-1696025 ] codecs.EncodedFile() - the same data and file encodings
Bugs item #1696025, was opened at 2007-04-07 14:40 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696025&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: Out of Date Priority: 5 Private: No Submitted By: Alexandr V. Demeshko (adem) Assigned to: Nobody/Anonymous (nobody) Summary: codecs.EncodedFile() - the same data and file encodings Initial Comment: Python version: 2.5 for MS Windows In Lib/codecs.py in lines 827-829 instead of: info = lookup(data_encoding) sr = StreamRecoder(file, info.encode, info.decode, info.streamreader, info.streamwriter, errors) should be something like: data_info = lookup(data_encoding) file_info = lookup(file_encoding) sr = StreamRecoder(file, data_info.encode, data_info.decode, file_info.streamreader, file_info.streamwriter, errors) -- >Comment By: Walter Dörwald (doerwalter) Date: 2007-04-08 09:40 Message: Logged In: YES user_id=89016 Originator: NO This has already been fixed in svn (r52517/r52518). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696025&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696390 ] Strange performance with unicode and lists
Bugs item #1696390, was opened at 2007-04-08 15:44
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=1696390&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vsevolod (sv75)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Strange performance with unicode and lists
Initial Comment:
I found some strange error (?) when using list of unicodes. Here is a small
sample:
# Alex in Russian
l = [u'\u0410\u043b\u0435\u043a\u0441']
# print method 1
for s in l:
print s.encode("utf-8")
# print method 2
print [s.encode("utf-8") for s in l]
Output is:
Алекс
['\xd0\x90\xd0\xbb\xd0\xb5\xd0\xba\xd1\x81']
I suppose than output of both methods should be equal. Or maybe I'm wrong?
Python versions: 2.4.4, 2.5 (both version)
OS: Ubuntu 6.10, Debian Etch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696390&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696390 ] Strange performance with unicode and lists
Bugs item #1696390, was opened at 2007-04-08 11:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696390&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: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Vsevolod (sv75)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Strange performance with unicode and lists
Initial Comment:
I found some strange error (?) when using list of unicodes. Here is a small
sample:
# Alex in Russian
l = [u'\u0410\u043b\u0435\u043a\u0441']
# print method 1
for s in l:
print s.encode("utf-8")
# print method 2
print [s.encode("utf-8") for s in l]
Output is:
Алекс
['\xd0\x90\xd0\xbb\xd0\xb5\xd0\xba\xd1\x81']
I suppose than output of both methods should be equal. Or maybe I'm wrong?
Python versions: 2.4.4, 2.5 (both version)
OS: Ubuntu 6.10, Debian Etch
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-04-08 12:34
Message:
Logged In: YES
user_id=849994
Originator: NO
No, the output is correct. The __str__() of a list does a __repr__() of
its contents,
to avoid confusion e.g. in this situation:
>>> l = ["a, b, c", "d, e, f"]
If list.__str__ did __str__ on its items, it would look like this:
>>> print l
[a, b, c, d, e, f]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696390&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695718 ] PEP 302 broken
Bugs item #1695718, was opened at 2007-04-06 16:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&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: Closed >Resolution: Wont Fix Priority: 6 Private: No Submitted By: phil (philipdumont) Assigned to: Georg Brandl (gbrandl) Summary: PEP 302 broken Initial Comment: The product I'm working on uses a PEP 302 importer hook. It's a home-grown ltihooks clone. (We don't use ltihooks because it's GPLed, and we don't want to be.) Our importer worked on 2.4.3, is broken on 2.5.0. What's broken is that if the hook's find_module() method returns None for a given module name, say 'spam', then that is supposed to cause the import machinery to fall back on the regular unhooked import behavior -- that is, find 'spam.py' (or 'spam.pyc', 'spam.pyo') in the directory in question. This used to be what happened, but no longer. Tracing through the code, the problem seems to be occurring due to the 'continue' at line 1289 (in the 2.5 tarball) of Python/import.c. Slogging through SVN (aside: this would have been easier if your ViewSVN supported annotate/blame -- any chance you could add that?), it appears that the offending continue statement was added in revision 46372, whose checkin comment claims that it was done for performance reasons. I'm all for performance improvements, but not at the expense of breakage. Attached is a tarball with some files that reproduce the problem. (The LibtoolImporter.py file is a stripped-down toy version of what we are really using.) Unwind the tarball, cd to the directory, and run script.py. Here's what I get: shell prompt> pwd /home/phil/pep302_bug shell prompt> ls -CF eggs.la LibtoolImporter.py script.py* spam.py shell prompt> python2.4.3 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug module spam loaded shell prompt> python2.5 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug Traceback (most recent call last): File "script.py", line 4, in import spam ImportError: No module named spam shell prompt> -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-08 12:58 Message: Logged In: YES user_id=849994 Originator: NO You're correct, Brett. I found the implicit fallback at the Iceland sprint and we decided to change that in 2.5: http://mail.python.org/pipermail/python-dev/2006-May/065174.html PEP 302 has even been edited to say: [...] Note that if the callable returns an importer object for a specific sys.path entry, the builtin import machinery will not be invoked to handle that entry any longer, even if the importer object later fails to find a specific module. Closing as "Won't fix", if more need for discussion arises, please take this to python-dev. -- Comment By: Brett Cannon (bcannon) Date: 2007-04-08 04:55 Message: Logged In: YES user_id=357491 Originator: NO I don't agree with this interpretation of PEP 302 for this instance. If you read the PEP there is no explicit mention that if an importer for an entry on sys.path fails that it falls back on the default import behaviour. The only mention of using the default behaviour is if a value of None is stored in sys.path_importer_cache (which also occurs when no entry on sys.path_hooks returns a usable importer). In my interpretation of PEP 302 (and how I implemented it for my pure Python import implementation), if an importer exists for an entry on sys.path then it essentially "owns" that entry. The default import semantics only kick in for unclaimed sys.path entries in my view. Now I could be wrong and if I am I hope Phil can point out where in PEP 302 I am wrong. Otherwise we have either undocumented behaviour that changed (and that is always messy) or implied semantics that got fixed. In other words, this probably needs to go to python-dev if Phil can't point out exactly where PEP 302 says the semantics he is expecting is supposed to be that way. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-06 19
[ python-Bugs-1695948 ] logging.handlers.SocketHandler.makeSocket() blocks app
Bugs item #1695948, was opened at 2007-04-06 23:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695948&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: jtdeng (jtdeng) >Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.SocketHandler.makeSocket() blocks app Initial Comment: Python Version: === Any Python Version OS Platform: Debian Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux Windows XP SP2 Problem: Member function makeSocket() of logging.handlers.SocketHandler creates a socket with no default timeout, and this may block the app on Linux. def makeSocket(self): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((self.host, self.port)) return s if the log receiver on the destination host is not running, the log sender will block the app on socket.connect(), but on windows, socket.connect() will return immediately. So I propose to provide a default timeout value for makeSocket() like below: def makeSocket(self, timeout=1): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) s.connect((self.host, self.port)) return s -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-08 22:56 Message: Logged In: YES user_id=33168 Originator: NO Vinay, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696740 ] README is referencing obsolete? http://starship.python.net
Bugs item #1696740, was opened at 2007-04-09 07:58 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=1696740&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jiri Navratil (plavcik) Assigned to: Nobody/Anonymous (nobody) Summary: README is referencing obsolete? http://starship.python.net Initial Comment: In README file obtained 09.04.2004 from Python SVN HEAD via svn is referenced There's also a Python community web site at http://starship.python.net/. I can't open this site. I'm getting unable to find IP address for starship.python.net Is this information obsolete? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696740&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
