[issue2647] XML munges apos entity in tag content
Martin v. Löwis [EMAIL PROTECTED] added the comment: That's not a bug. The two XML documents are completely equivalent. If you rely on the lexical representation of specific characters, you should reconsider your usage of XML. toxml could have chosen to represent as #60;, and that still would have been correct (IOW, it doesn't even know anymore that you represented it as lt; in the input). -- nosy: +loewis resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2647 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2646] Python does not accept unicode keywords
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- versions: +Python 2.6 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2646 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Raymond Hettinger [EMAIL PROTECTED] added the comment: No need to get hung-up on the hash function. I can fix that up after a checkin and use something simple like: hashvalue = (start*prime1+seqlen) *prime2+step. That doesn't involve object creation and it produces the same hash value for range(5,10,2) and range(5,9,2) which are equivalent. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: It produces the same hash value for range(5,10,2) and range(5,9,2) which are equivalent. If equivalent means __eq__, they are not. This does not invalidate your formula, of course: different objects may have the same hash. It is also simple to understand: just mix the numbers together. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Raymond Hettinger [EMAIL PROTECTED] added the comment: That was a typo. The pair was range(5,10,2)--[5, 7, 9] and range (5,11,2)--[5, 7, 9]. The formula works because the it uses seqlen instead of a stop value. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2648] decimal receipe moneyfmt suppress leading 0
New submission from Carsten Grohmann [EMAIL PROTECTED]: The current version of the receipe moneyfmt doesn't have a leading 0 for 1 value -1. The attached patch adds a new parameter zero. The parameter is empty per default and can set to 0 print a leading 0. The examples are updated also. Possibly the new option should be 0 per default. Regards, Carsten -- assignee: georg.brandl components: Documentation files: moneyfmt.diff keywords: patch messages: 65581 nosy: cgrohmann, georg.brandl severity: normal status: open title: decimal receipe moneyfmt suppress leading 0 versions: Python 2.5 Added file: http://bugs.python.org/file10046/moneyfmt.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2648 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1222] locale.format bug if thousand separator is space (french separator as example)
Antoine Pitrou [EMAIL PROTECTED] added the comment: I see that http://wiki.python.org/moin/PythonBugDay says need to test on non-MacOS platform. Actually, I've tested the patch under Mandriva and Debian Linux. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1222 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2648] decimal receipe moneyfmt suppress leading 0
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- assignee: georg.brandl - rhettinger nosy: +rhettinger type: - feature request versions: +Python 2.6 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2648 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2648] decimal receipe moneyfmt suppress leading 0
Raymond Hettinger [EMAIL PROTECTED] added the comment: Thanks for the contribution. Changed to be non-optional and applied as r62364 but not backported. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2648 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2649] poss. patch for fnmatch.py to add {.htm, html} style globbing
New submission from Mark Summerfield [EMAIL PROTECTED]:
At the moment fnmatch.py (and therefore glob.py) support:
* . [chars] [!chars]
The attached version of fnmatch.py extends this to:
* . [chars] [!chars] {one,two,...}
There are 2 changes from the original fnmatch.py file:
(1) The documentation for the fnmatch() function has been updated to
reflect the new functionality
(2) The translate() function has been completely replaced.
I ran test_fnmatch.py and test_glob.py and both ran without errors.
--
components: Library (Lib)
files: fnmatch.py
messages: 65584
nosy: mark
severity: normal
status: open
title: poss. patch for fnmatch.py to add {.htm,html} style globbing
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10047/fnmatch.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2649
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
New submission from Russ Cox [EMAIL PROTECTED]: import re print re.escape(_) Prints \_ but should be _. This behavior differs from Perl and other systems: _ is an identifier character and as such does not need to be escaped. -- messages: 65585 nosy: rsc severity: normal status: open title: re.escape should not escape underscore type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Changes by Russ Cox [EMAIL PROTECTED]: -- components: +Regular Expressions __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Changes by Guido van Rossum [EMAIL PROTECTED]: -- keywords: +easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Changes by Guido van Rossum [EMAIL PROTECTED]: -- versions: +Python 2.6, Python 3.0 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
New submission from Rick Harris [EMAIL PROTECTED]: Here is a bug in Python 2.5 which would be nice to fix for Py3k (since we are already breaking compatibility): Take a string: s = Hello Create a KeyError exception with that string: e = KeyError(s) Counterintuitively, casting the exception to a string doesn't return the same string: str(e) != s Instead, when KeyError is cast to a string it affixes single-quotes around the string. I have create a test which shows that the other built-in exceptions (except for 3 Unicode Errors which seem to be unusual in that they don't accept just a string), do indeed round-trip the string unaltered. This actually caused a bug (in an old version of zope.DocumentTemplate). I am including the test case I wrote for now; I will begin looking into a solution shortly and hopefully whip up a patch. -- components: Interpreter Core files: testExceptionStringRoundTrip.py messages: 65586 nosy: rharris severity: normal status: open title: Strings passed to KeyError do not round trip type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10048/testExceptionStringRoundTrip.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2651 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Here is a relevant comment inside the KeyError_str function:
/* If args is a tuple of exactly one item, apply repr to args[0].
This is done so that e.g. the exception raised by {}[''] prints
KeyError: ''
rather than the confusing
KeyError
alone. The downside is that if KeyError is raised with an
explanatory
string, that string will be displayed in quotes. Too bad.
If args is anything else, use the default BaseException__str__().
*/
Why is it so important to round trip?
--
nosy: +amaury.forgeotdarc
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2651
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows
Changes by Trent Nelson [EMAIL PROTECTED]: -- nosy: +Trent.Nelson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2643 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Rick Harris [EMAIL PROTECTED] added the comment: I think it is important to round-trip for at least two reasons: 1) Consistency. Other built-in exceptions behave this way, why should KeyError be any different? Okay, technically 3 UnicodeErrors don't allow just strings to be passed in (perhaps they should :-); but for common exception classes, they all behave the same way. To quote PEP-20: Special cases aren't special enough to break the rules 2) Intuitiveness. Decorating the string with quotes is unexpected; it has already caused at least one bug and could cause more. Ensuring intuitive round-trip behavior is an important enough issue that is explicitly discussed in PEP 327 for the decimal type. Why can't intuitiveness be restored to KeyError in Py3K? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2651 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: Based on the discussion on python-dev I've worked up a patch and tests for repr of dict_items, dict_keys, and dict_values. I've also modified the patch and test for str of the range object. (If there was a way to get the str(range(10)) to automatically display in the interactive shell that would be ideal. I assume one combined patch for all of this is OK since its been part of the same discussion. Brad Added file: http://bugs.python.org/file10049/dv_range.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- title: string representation of range - string representation of range and dictionary views __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Benjamin Peterson [EMAIL PROTECTED] added the comment: It seems that escape is pretty dumb. The documentations says that re.escape escapes all non-alphanumeric characters, and it does that faithfully. It would seem more useful to have a list of meta-characters and just escape those. This is more true in Py3k when str can have thousands of possible characters that could be considered alphanumeric. -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Some review of dv_range.patch:
- repr(d.keys()) depends on the internal ordering of items, their hash
values, the insertion order... the test seems fragile.
Or you may rely on the fact that ints are their own hash values, so a
small dict containing small keys will appear ordered. I suggest
something like {6: 1.2, 1: 'A', 7: 42, 4: None}
- empty dicts or empty ranges will display:
range:
dict_items:
Isn't there a better repr? At least this should appear in the tests.
--
nosy: +amaury.forgeotdarc
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2610
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller [EMAIL PROTECTED] added the comment:
On Apr 17, 2008, at 4:26 PM, Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Some review of dv_range.patch:
- repr(d.keys()) depends on the internal ordering of items, their hash
values, the insertion order... the test seems fragile.
Or you may rely on the fact that ints are their own hash values, so a
small dict containing small keys will appear ordered. I suggest
something like {6: 1.2, 1: 'A', 7: 42, 4: None}
I wondered about that, but my assumption was that the hash function
for strings and ints was equally unlikely to change. I can go with
all ints if that is really a safer assumption.
- empty dicts or empty ranges will display:
range:
dict_items:
Isn't there a better repr? At least this should appear in the tests.
I'm not sure how to represent that better.
range: None
dict_items: None -- These seem misleading
range: empty
dict_items: empty -- I'm not sure that is better than
dict_items: and empty may not mean anything to non-english speakers
I'll be happy to add the test for the empty case after once I know
what it should look like.
--
nosy: +amaury.forgeotdarc
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2610
__
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2610
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Benjamin Peterson [EMAIL PROTECTED] added the comment: Attaching a new patch with a few improvements. I tried to implemented Raymond's hash function (I think this is how the math should be done.). The rich compare function now short-circuits when a value isn't equal. Also, I made ranges with the same set of integers equal even if the stop is different. Added file: http://bugs.python.org/file10050/range_eq7.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: I am very sorry to report (at least for me) that as of this moment, item 9), although not yet complete, is stable and able to pass all the existing python regexp tests. Because these tests are timed, I am using the timings from the first suite of tests to perform a benchmark of performance between old and new code. Based on discussion with Andrew Kuchling, I have decided for the sake of simplicity, the timing of each version is to be calculated by the absolute minimum time to execute observed because it is believed this execution would have had the most continuous CPU cycles and thus most closely represents the true execution time. It is this current conclusion that greatly saddens me, not that the effort has not been valuable in understanding the current engine. Indeed, I understand the current engine now well enough that I could proceed with the other modifications as-is rather than implementing them with the new engine. Mind you, I will likely not bring over the copious comments that the new engine received when I translated it to a form without C_Macros and gotos, as that would require too much effort IMHO. Anyway, all that being said, and keeping in mind that I am not 100% satisfied with the new engine and may still be able to wring some timing out of it -- not that I will spend much more time on this -- here is where we currently stand: Old Engine: 6.574s New Engine: 7.239s This makes the old Engine 665ms faster over the entire first test_re.py suite, or 9% faster than the New Engine. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1184112] Missing trailing newline with comment raises SyntaxError
Inyeol Lee [EMAIL PROTECTED] added the comment: Missing trailing newline still triggers error as of 2.5.1: import parser parser.suite(pass\n ) IndentationError: unexpected indent parser.suite(if True:\n pass\n ) SyntaxError: invalid syntax -- nosy: +inyeollee _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1184112 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2652] 64 bit python memory leak usage
New submission from kevin [EMAIL PROTECTED]:
For the code below.. memory usage keeps increasing continuously.. This
does not happen in a 32-bit machine python build. i think it might be
the datetime module where the problem might be..
linux kernel version (both on 32-bit and 64 bit machine)
linux - 2.6.24.4-64.fc8
python version (both on 32-bit and 64 bit machine)
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)
now = datetime.datetime.now()
oneday = datetime.timedelta(days=1)
def birthdaycompare(a, b):
if a is None and b:
return 1
if a and b is None:
return -1
if a is None and b is None:
return 0
if ab:
return -1
elif a==b:
return 0
else:
return 1
def compare_by(fieldname):
def comparedict(a,b):
return birthdaycompare(a[fieldname], b[fieldname])
return comparedict
def getbirthdays(friend_details):
new_f = []
birthday = None
birthday_dt = None
for f in friend_details:
if f.has_key('birthday'):
birthday = f['birthday']
if birthday and birthday !='':
birthday_split = birthday.split(',')[0]
if birthday_split == 'February 29':
birthday = 'February 28'
try:
birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year) , '%B
%d, %Y')
if birthday_dt (now - oneday):
birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year+1) ,
'%B %d, %Y')
except:
birthday=None
birthday_dt=None
f['birthday'] = birthday
f['birthday_dt'] = birthday_dt
new_f.append(f)
new_f.sort(compare_by('birthday_dt'))
--
files: data.log
messages: 65596
nosy: kevin3210
severity: normal
status: open
title: 64 bit python memory leak usage
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10051/data.log
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2652
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2621] rename test_support to support
Benjamin Peterson [EMAIL PROTECTED] added the comment: Brett, comments? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2652] 64 bit python memory leak usage
Changes by Gregory P. Smith [EMAIL PROTECTED]: -- nosy: +gregory.p.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2652 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2621] rename test_support to support
Brett Cannon [EMAIL PROTECTED] added the comment: I am going to assign this to me, but wait until Guido pronounces on PEP 3108 before moving forward with a review. -- assignee: - brett.cannon __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Russ Cox [EMAIL PROTECTED] added the comment: It seems that escape is pretty dumb. The documentations says that re.escape escapes all non-alphanumeric characters, and it does that faithfully. It would seem more useful to have a list of meta-characters and just escape those. This is more true in Py3k when str can have thousands of possible characters that could be considered alphanumeric. The usual convention is to escape everything that is ASCII and not A-Za-z0-9_, in case other punctuation becomes special in the future. But I agree -- escaping just the actual special characters makes the most sense. Russ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
