[ python-Bugs-1696025 ] codecs.EncodedFile() - the same data and file encodings
Bugs item #1696025, was opened at 2007-04-07 15:40 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=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: Open Resolution: None 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) -- 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-1696199 ] Add collections.counts()
Bugs item #1696199, was opened at 2007-04-07 15:38 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=1696199&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Add collections.counts() Initial Comment: As suggested in http://mail.python.org/pipermail/python-list/2007-April/433986.html this is a patch to add a counts() function to the collections module. Usage looks like: >>> items = 'acabbacba' >>> item_counts = counts(items) >>> for item in 'abcd': ... print item, item_counts[item] ... a 4 b 3 c 2 d 0 Yes, it's only a 4-line function, but it's a frequently re-written 4-line function. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696199 ] Add collections.counts()
Bugs item #1696199, was opened at 2007-04-07 17:38 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Add collections.counts() Initial Comment: As suggested in http://mail.python.org/pipermail/python-list/2007-April/433986.html this is a patch to add a counts() function to the collections module. Usage looks like: >>> items = 'acabbacba' >>> item_counts = counts(items) >>> for item in 'abcd': ... print item, item_counts[item] ... a 4 b 3 c 2 d 0 Yes, it's only a 4-line function, but it's a frequently re-written 4-line function. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 19:39 Message: Logged In: YES user_id=6380 Originator: NO Does it have to be a defaultdict? I.e. is it important that item_counts['d'] not raise KeyError? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696199 ] Add collections.counts()
Bugs item #1696199, was opened at 2007-04-07 15:38 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Add collections.counts() Initial Comment: As suggested in http://mail.python.org/pipermail/python-list/2007-April/433986.html this is a patch to add a counts() function to the collections module. Usage looks like: >>> items = 'acabbacba' >>> item_counts = counts(items) >>> for item in 'abcd': ... print item, item_counts[item] ... a 4 b 3 c 2 d 0 Yes, it's only a 4-line function, but it's a frequently re-written 4-line function. -- >Comment By: Steven Bethard (bediviere) Date: 2007-04-07 17:48 Message: Logged In: YES user_id=945502 Originator: YES I think it's okay if it's not a defaultdict. That was the simplest implementation, but I certainly have no problem calling d.get() when necessary. Should I change the implementation to use a dict()? -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 17:39 Message: Logged In: YES user_id=6380 Originator: NO Does it have to be a defaultdict? I.e. is it important that item_counts['d'] not raise KeyError? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696199 ] Add collections.counts()
Bugs item #1696199, was opened at 2007-04-07 17:38 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Add collections.counts() Initial Comment: As suggested in http://mail.python.org/pipermail/python-list/2007-April/433986.html this is a patch to add a counts() function to the collections module. Usage looks like: >>> items = 'acabbacba' >>> item_counts = counts(items) >>> for item in 'abcd': ... print item, item_counts[item] ... a 4 b 3 c 2 d 0 Yes, it's only a 4-line function, but it's a frequently re-written 4-line function. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 20:23 Message: Logged In: YES user_id=6380 Originator: NO I guess it's simplicity of implementation vs. simplicity of use. And I'm not even sure which is easier to use. It's just that defaultdicts are a very new thing and still feel "weird" -- even though I pushed for the implementation based on popular demand I'm not a user myself. Perhaps ask around on python-dev? -- Comment By: Steven Bethard (bediviere) Date: 2007-04-07 19:48 Message: Logged In: YES user_id=945502 Originator: YES I think it's okay if it's not a defaultdict. That was the simplest implementation, but I certainly have no problem calling d.get() when necessary. Should I change the implementation to use a dict()? -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 19:39 Message: Logged In: YES user_id=6380 Originator: NO Does it have to be a defaultdict? I.e. is it important that item_counts['d'] not raise KeyError? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&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: Fixed
Priority: 5
Private: No
Submitted By: Adam Monsen (meonkeys)
Assigned to: Brett Cannon (bcannon)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-04-07 21:18
Message:
Logged In: YES
user_id=357491
Originator: NO
r54646 (along with a fix for the test in r54647) has the change. This is
in the trunk. I went with my test since if that test is wrong my whole
understanding of how time.strptime works is wrong in terms of caching. =)
I will backport to the 2.5 branch once 2.5.1 is done since I missed the
deadline. Thanks, Kovar, for all the help.
--
Comment By: Brett Cannon (bcannon)
Date: 2007-03-29 13:03
Message:
Logged In: YES
user_id=357491
Originator: NO
The test was checking that the TimeRE instance is recreated when the
locale changes. You do have a valid point about the 'if' check; should
have put the setlocale call in an try/except block and just returned if an
exception was raised.
As for the %d usage of strptime, that is just to force a call into
strptime and thus trigger the new instance of TimeRE. That is why the test
checks the id of the objects; don't really care about strptime directly
failing. Did the test not fail properly even when you removed the 'if' but
left everything else alone?
--
Comment By: Javier Sanz (kovan)
Date: 2007-03-29 09:53
Message:
Logged In: YES
user_id=1426755
Originator: NO
I've been looking at the test case, and I noticed that isn't actually
checking anything, because locale.getlocale(locale.LC_TIME) is returning
(None,None), which is ok and just means that the default locale (which is
the C locale, not the system locale) is being used.
After removing that 'if' I also changed de_DE by es_ES to fit my system,
and strptime('10', '%d') by strptime('Fri', '%a') and strptime('vie','%a');
because '10' is '10' in all -occidental- languages, and the test would not
fail when the wrong locale is being used.
Once I made these changes to the test case, it successfully failed when
using the non-patched _strptime.py, AND ran ok when using the patched
version.
This is the test case I ended up using:
def test_TimeRE_recreation(self):
# The TimeRE instance should be recreated upon changing the
locale.
locale_info = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, ('en_US', 'UTF8'))
try:
_strptime.strptime('Fri', '%a')
first_time_re_id = id(_strptime._TimeRE_cache)
locale.setlocale(locale.LC_TIM
[ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file
Bugs item #1569057, was opened at 2006-10-01 21:49
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: andrei kulakov (rainy)
Assigned to: Brett Cannon (bcannon)
Summary: Using .next() on file open in write mode writes junk to file
Initial Comment:
When you open a file in write mode and use .next(), it
prints an error and writes many lines of junk to file.
I tested on windows and python 2.5:
>>> f = open('test', 'w')
>>> f.fileno()
4
>>> f.write('1\n')
>>> f.write('2\n3\n4\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
'2\n'
>>> f.next()
'3\n'
>>> f.next()
'4\n'
>>> f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00
...many more lines of junk...'
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-04-07 21:30
Message:
Logged In: YES
user_id=357491
Originator: NO
r54712 has the documentation note.
--
Comment By: Brett Cannon (bcannon)
Date: 2007-03-20 17:44
Message:
Logged In: YES
user_id=357491
Originator: NO
I think the docs should just say switching is undefined and leave it at
that. Calling 'next' on a file open for writing just makes no sense
anyway. And who knows what the OS will do if you try to misuse a file
descriptor.
Other option is to raise an exception when 'next' is called on a file
opened for writing (TypeError?). I think that makes more sense.
Unfortunately having to check the mode every time you call 'next' might be
considered unacceptable. Anyone have an opinion?
Either way I will go with one of the two solutions.
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-07 09:04
Message:
Logged In: YES
user_id=511010
I tried it on win2k sp4 running python 2.5 and right now
tried it on winXP running python 2.4 - same error. Also, at
least one user on python newsgroup tried it and got a
slightly different result: he did not get the error on
.next() but the junk was written to the file. I paste my
latest attempt right out of IDLE, without any modification
(my first paste was also straight from idle). Except that I
trim the junk characters, because there's more than a
screen of 'em.
IDLE 1.1.2
>>> f = open('test', 'w')
>>> f.write('1\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in -toplevel-
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
"\x95\x00\xc8\xe ..."
Please let me know if you need to know anything else...
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 03:38
Message:
Logged In: YES
user_id=44345
Works for me. (Nearly current build from SVN.) I find it implausible that
your
explanation of failing to flush the file is the cause of the problem since
closing
the file will cause it to be flushed. You didn't open the file for "w+"
so there's no
opportunity to switch between writing and reading.
What platform are you using?
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-03 18:23
Message:
Logged In: YES
user_id=511010
Python newsgroup folks said that this is normal because when
switching between write/read modes without doing flush()
first, result is undefined. There was a suggestion from
Terry Ready to add this to documentation on file methods:
"When switching from reading or writing (or vice versa),
call flush(), or
the result will be undefined."
thx, -andrei
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&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 09:32 Message generated for change (Comment added) made by bcannon 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: Open Resolution: None 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: Brett Cannon (bcannon) Date: 2007-04-07 21: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 12:21 Message: Logged In: YES user_id=80475 Originator: NO Georg, I believe this was your checkin. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1696199 ] Add collections.counts()
Bugs item #1696199, was opened at 2007-04-07 16:38 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add collections.counts() Initial Comment: As suggested in http://mail.python.org/pipermail/python-list/2007-April/433986.html this is a patch to add a counts() function to the collections module. Usage looks like: >>> items = 'acabbacba' >>> item_counts = counts(items) >>> for item in 'abcd': ... print item, item_counts[item] ... a 4 b 3 c 2 d 0 Yes, it's only a 4-line function, but it's a frequently re-written 4-line function. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 19:23 Message: Logged In: YES user_id=6380 Originator: NO I guess it's simplicity of implementation vs. simplicity of use. And I'm not even sure which is easier to use. It's just that defaultdicts are a very new thing and still feel "weird" -- even though I pushed for the implementation based on popular demand I'm not a user myself. Perhaps ask around on python-dev? -- Comment By: Steven Bethard (bediviere) Date: 2007-04-07 18:48 Message: Logged In: YES user_id=945502 Originator: YES I think it's okay if it's not a defaultdict. That was the simplest implementation, but I certainly have no problem calling d.get() when necessary. Should I change the implementation to use a dict()? -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-07 18:39 Message: Logged In: YES user_id=6380 Originator: NO Does it have to be a defaultdict? I.e. is it important that item_counts['d'] not raise KeyError? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1696199&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
