Christoph Burgmer added the comment:
Here's a test case and a fix for get_matching_blocks() to return the same
content on subsequent calls.
--
keywords: +patch
nosy: +christoph
Added file: http://bugs.python.org/file19084/get_matching_blocks
Christoph Burgmer added the comment:
BTW, here's the commit that broke the behavior in the first place:
http://svn.python.org/view/python/trunk/Lib/difflib.py?r1=54230&r2=59907
--
___
Python tracker
<http://bugs.python.o
New submission from Christoph Burgmer :
'PRAGMA database.table_info("SOME_TABLE_NAME")' will report table metadata for
the given database. The main database called 'main', can be extended by
attaching further databases via 'ATTACH DATABASE'. The above PR
New submission from Christoph Burgmer <[EMAIL PROTECTED]>:
Python seems to have problems when an exception is thrown that
contains non-ASCII text as a message and is converted to a string.
>>> try:
... raise Exception(u'Error when printing ü')
... except Exce
Christoph Burgmer <[EMAIL PROTECTED]> added the comment:
To be more precise: I see no way to convert the encapsulated non-ASCII
data from the string in an easy way.
Taking e from my last post none of the following will work:
str(e) # UnicodeDecodeError
e.__str__() # UnicodeDecodeE
Christoph Burgmer <[EMAIL PROTECTED]> added the comment:
Thanks, this does work.
But, where can I find the piece of information you just gave to me in
the docs? I couldn't find any interface definition for Exceptions.
Further more will this be regarded as a bug?
>From [1] I u
Christoph Burgmer <[EMAIL PROTECTED]> added the comment:
Though I welcome the reopening of the bug for Python 3.0 I must say
that plans of not fixing a core element rather surprises me.
I never believed Python to be a programming language with good Unicode
integration. Several point
Christoph Burgmer <[EMAIL PROTECTED]> added the comment:
JFTR:
> print unicode(e.message).encode("utf-8")
only works for Python 2.5, not downwards.
__
Tracker <[EMAIL PROTECTED]>
<http
Christoph Burgmer added the comment:
Casing algorithms should follow Section 3.13 "Default Case Algorithms"
in the standard itself, not UTR#21.
See
http://www.unicode.org/Public/5.2.0/ucd/DerivedCoreProperties-5.2.0d11.
Unicode 5.2. A nice mail on the Unicode mail list has a bit expl
New submission from Christoph Burgmer :
pydoc fails with a UnicodeEncodeError for properly specified Unicode
docstrings (u"""...""") on the command line interface.
See attached patch that encodes the output with the system's encoding.
--
Christoph Burgmer added the comment:
Here is a diff for test/test_pydoc.py (against Python2.6) which though
doesn't trigger due to how Python handles output encoding. This test
here will pass, but pydoc will still fail:
$ pydoc test/pydoc_mod.py > /dev/null
Traceback (most recent c
New submission from Christoph Burgmer :
locale.format_string doesn't return same result as a normal
"string" % format
directive, but raises a TypeError. See attached test case for Python
2.6.
>>> locale.format_string('%f%%', 1.0)
Traceback (most recent call la
Christoph Burgmer added the comment:
This patch removes '%%' entities from the regex results and only
replaces other matches with '%s' which later then get replaced by
localized versions so that escaped percentage entities don't show up in
localized parsing anymore.
Re
Christoph Burgmer added the comment:
Implementing full patch solving it the old way (UTR#21).
The correct way for the latest Unicode version would be to implement
the word breaking algorithm described in (UAX#29) [1] first.
[1] http://www.unicode.org/reports/tr29/#Word_Boundaries
Christoph Burgmer added the comment:
I should add that I didn't include the two header files generated by
Tools/unicode/makeunicodedata.py
--
___
Python tracker
<http://bugs.python.org/i
Christoph Burgmer added the comment:
> * U+0027 APOSTROPHE
hardcoded (see below)
> * U+00AD SOFT HYPHEN (SHY)
has the "Format (Cf)" property and thus is included automatically
> * U+2019 RIGHT SINGLE QUOTATION MARK
hardcoded (see below)
I hardcoded some characters
Christoph Burgmer added the comment:
I admit I don't fully understand the semantics of capwords(). But from
what I believe what it should do, this function could be happily
replaced by the word-breaking algorithm as defined in
http://www.unicode.org/reports/tr29/.
This algorithm shou
Christoph Burgmer added the comment:
New patch
- updated comments to reflect needed integration of
DerivedCoreProperties.txt
- cleaned up if(...) construct
- updated (from issue7008) and integrated testcase
When applying this patch, run Tools/unicode/makeunicodedata.py to
regenerate the
Christoph Burgmer added the comment:
Antoine Pitrou wrote:
> capwords() itself could be deprecated, since it's an obvious one-
> Replacing in with another method, however, will just confuse and
annoy
> existing users.
Yes, sorry, I meant the semantics, where as you are right fo
Christoph Burgmer added the comment:
OutputChecker.check_output() seems to be responsible for comparing
'example.want' and 'got' literals and this is obviously done literally.
So as "u'1'" is different to "'1'" this is reflected in the
Christoph Burgmer added the comment:
This problem seems more severe as the appended test case shows.
That gives me:
Expected:
u'ī'
Got:
u'\u012b'
Both literals are the same.
Unicode literals in doc strings are not treated as other escaped
characters:
>
Christoph Burgmer added the comment:
See attached patch which works for error reporting and verbose output.
--
keywords: +patch
nosy: +christoph
Added file: http://bugs.python.org/file14407/doctest.unicode.patch
___
Python tracker
<h
Christoph Burgmer added the comment:
My last patch only changed the encoding used in DocTestRunner.run().
This new patch will apply the same to DocTestCase.runTest().
--
Added file: http://bugs.python.org/file14422/doctest.unicode.patch
___
Python
Christoph Burgmer added the comment:
JFTR: To yield the results of my last comment, you need to apply the
patch posted in http://bugs.python.org/issue1293741
--
___
Python tracker
<http://bugs.python.org/issue3
New submission from Christoph Burgmer :
Titlecase, i.e. istitle() and title(), is buggy when the string
includes combining diacritical marks.
>>> u'H\u0301ngh'.istitle()
False
>>> u'H\u0301ngh'.title()
u'H\u0301Ngh'
>>>
The string give
Christoph Burgmer added the comment:
Adding a incomplete patch in need of a function
Py_UNICODE_ISCASEIGNORABLE defining the case-ignorable class.
I don't want to touch capitalize() as I don't fully understand the
semantics, where it is different to title(). It seems though follow
Christoph Burgmer added the comment:
Will this bug be tackled or Python2.7?
And is there a way to get hold of the access denied error?
Here are my steps to reproduce:
I started the console with "cmd /u /k chcp
Christoph Burgmer added the comment:
@Terry
How is the behavior changed? To me it seems the same to as initially reported.
The results are consistent but nonetheless wrong. It's not about whether your
agree with the result, but rather about following the Unicode sta
28 matches
Mail list logo
