[issue14200] Idle shell crash on printing non-BMP unicode character

Vlastimil Brom added the comment: Sorry for mixing the different problems, these were somehow things I noticed "at once" in the new python version, but I should have noticed the different domains myself. I still might not understand the term "crash" properly - I just m

[issue14200] Idle shell crash on printing non-BMP unicode character

Vlastimil Brom added the comment: I'd like to add some further observations to the mentioned issue; it seems, that the crash is indeed not specific to idle. In a sample tkinter app, where I just display e.g. chr(66352) in an Entry widget, I also get the same immediate crash via pythonw.ex

[issue14200] Idle shell crash on printing non-BMP unicode character

Vlastimil Brom added the comment: Hi, thanks for the pointer, after invoking idle using python.exe, I don't see the crash mentioned in the report: Python 3.3.0a1 (default, Mar 4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits"

[issue14200] Idle shell crash on printing non-BMP unicode character

New submission from Vlastimil Brom : Hi, while testing python 3.3a1 a bit, especially the new string handling of non-BMP characters, I noticed a problem in Idle in this regard: Python 3.3.0a1 (default, Mar 4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on win32 ... [using win XPp SP3 Czech

[issue2636] Adding a new regex module (compatible with re)

Vlastimil Brom added the comment: Not that it matters in any way, but if the regex semantics has to be distinguished via "non-standard" custom flags; I would prefer even less wordy flags, possibly such that the short forms for the in-pattern flag setting would be one-letter (such

[issue2636] Adding a new regex module (compatible with re)

Vlastimil Brom added the comment: I'd agree with Steven ( msg143377 ) and others, that there probably shouldn't be a large library-specific set of new tags just for "housekeeping" purposes between re and regex. I would personally prefer, that these tags also be set

[issue11744] re.LOCALE doesn't reflect locale.setlocale(...)

Vlastimil Brom added the comment: Thanks for the comment for string.letters and further reference. Given, that Mr. Barnett mentioned in his tracker to regex ( http://code.google.com/p/mrab-regex-hg/issues/detail?id=6 ), that he only supports the LOCALE flag because of the compatibility with

[issue11744] re.LOCALE doesn't reflect locale.setlocale(...)

New submission from Vlastimil Brom : Hi, I just noticed a behaviour of the re.LOCALE flag I can't understand; I first reported this to the new regex implementation, which, however, only mimics the standard lib re in this case: http://code.google.com/p/mrab-regex-hg/issues/detail?id=6 I

[issue10459] missing character names in unicodedata (CJK...)

Changes by Vlastimil Brom : -- components: +Library (Lib), Unicode type: -> behavior ___ Python tracker <http://bugs.python.org/issue10459> ___ ___ Python-

[issue10459] missing character names in unicodedata (CJK...)

New submission from Vlastimil Brom : I just noticed an ommision of come character names in unicodedata module. These are some CJK - Ideographs: 龼 (0x9fbc) - 鿋 (0x9fcb) (CJK Unified Ideographs [19968-40959] [0x4e00-0x9fff]) 𪜀 (0x2a700) - 𫜴 (0x2b734) (CJK Unified Ideographs Extension C

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thank you very much! a quick test with my custom unicodedata with 6.0 on py 2.7 seems ok. I hope, there won't be problems with "cooperation" of the more recent internal data with the original 5.2 database in python 2.x

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I'd have liked to suggest updating the underlying unicode data to the latest standard 6.0, but it turns out, it might be problematic with the cross-version compatibility; according to the clarification in http://bugs.python.org/issue10400 the 3... ver

[issue10400] updating unicodedata to Unicode 6

Vlastimil Brom added the comment: Thanks for the clarification; I obviously looked in an inappropriate branch before. Sorry for the noise... vbr -- ___ Python tracker <http://bugs.python.org/issue10

[issue10400] updating unicodedata to Unicode 6

New submission from Vlastimil Brom : I'd like to suggest updating the unicodedata module according to the recent Unicode standard 6.0 http://www.unicode.org/versions/Unicode6.0.0/ I'm sorry to bother, in case this is planned automatically, I just wasn't able to find the respect

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Maybe I am missing something, but the result in regex seem ok to me: \A is treated like A in a character set; when the test string is changed to "A b c" or in the case insensitive search the A is matched. [\A\s]\w doesn't match the starting &q

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Sorry for the noise, please, forgot my previous msg120215; I somehow managed to keep an older version of _regex_core.py along with the new regex.py in the Lib directory, which are obviously incompatible. After updating the files correctly, the mentioned

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: There seems to be a bug in the handling of numbered backreferences in sub() in issue2636-20101102.zip I believe, it would be a fairly new regression, as it would be noticed rather soon. (tested on Python 2.7; winXP) >>> re.sub("([xy])", &qu

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Sorry for the noise, it seems, I can go back to the 32-bit python for now then... vbr -- ___ Python tracker <http://bugs.python.org/issue2

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Well, it seemed to me too, I happened to read the last post from Matthew, msg118243, in the sense that he made some updates which need testing on a 64 bit system (I am unsure, whether hardware architecture, OS type, python build or something else was meant

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I tried to give the 64-bit version a try, but I might have encountered a more general difficulties. I tested this on Windows 7 Home Premium (Czech), the system is 64-bit (or I've hoped so sofar :-), according to System info: x64-based PC I installed P

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Well, of course, the surrogates probably shouldn't be handled separately in one module independently of the rest of the standard library. (I actually don't know such narrow implementation (although it is mentioned in those unicode quidel

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I like the idea of the general "new" flag introducing the reasonable, backwards incompatible behaviour; one doesn't have to remember a list of non-standard flags to get this features. While I recognise, that the module probably can't work

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Just another rather marginal findings; differences between regex and re: >>> regex.findall(r"[\B]", "aBc") ['B'] >>> re.findall(r"[\B]", "aBc") [] (Python 2.7 ... on win32; regex - issue2636-

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thank you both for the explanations; I somehow suspected, there would be some strong reasoning for the conservative approach with regard to the backward compatibility. Thanks for the block() and script() offer, Matthew, but I believe, this might clutter the

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Not that my opinion matters, but for what is it worth, I find it rather unusual to have to use special flags to get "normal" (for some definition of normal) behaviour, while retaining the defaults buggy in some way (like ZEROWIDTH). I would

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thanks for the update; Just a small observation regarding some character ranges and ignorecase, probably irrelevant, but a difference to the current re anyway: >>> zero2z = >>> u"0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\]

[issue2986] difflib.SequenceMatcher not matching long sequences

Vlastimil Brom added the comment: I guess, I am not supposed to post to python-dev - not being a python developer, hopefully it is appropriate to add a comment here - only based on my current usage of (a modified) difflib.SequenceMatcher. It seems, the mentions of text comparison in that

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thanks for the prompt fix! It would indeed be nice to see this enhanced re module in the standard library e.g. in 3.2, but I also really appreciate, that also multiple 2.x versions are supported (as my current main usage of this library involves py2-only wx

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I just noticed a somehow strange behaviour in matching character sets or alternate matches which contain some more "advanced" unicode characters, if they are in the search pattern with some "simpler" ones. The former seem to be ignored

[issue2986] difflib.SequenceMatcher not matching long sequences

Vlastimil Brom added the comment: I just stumbled on some seemingly different unexpected behaviour of difflib.SequenceMatcher, but it turns out, it may have the same cause, i.e. the "popular" heuristics. I hopefully managed to replicate it on an illustrative sample text - in as i

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I am not sure about the testsuite for this regex module, but it seems to me, that many of the problems reported here probably don't apply for the current builtin re, as they are connected with the new features of regex. After the suggestion in msg914

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Actually I had that impression too, but I was mainly surprised with these requirements being on the lowest level of the unicode support. Anyway, maybe the relevance of these guidelines for the real libraries is is lower, than I expected. Probably the

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I just noticed a cornercase with the newly introduced grapheme matcher \X, if this is used in the character set: >>> regex.findall("\X", "abc") ['a', 'b', 'c'] >>> regex.findall("[\X]&

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thanks, its indeed a very nice addition to the library... Just a marginal remark; it seems, that in script-names also some non BMP characters are covered, however, in the unicode ranges thee only BMP. http://www.unicode.org/Public/UNIDATA/Blocks.txt Am I

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Wow, that's what can be called rapid development :-), thanks very much! I did'n noticed before, that \G had been implemented already. \X works fine for me, it also maintains the input string indices correctly. We can use unicode character properties

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Is the issue2636-20100222.zip archive supposed to be complete? I can't find not only the rst or html "features", but more importantly the py and pyd files for the particular versions. Anyway, I just skimmed through the regular-expressions.inf

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thanks for fixing the argument positions; unfortunately, it seems, there might be some other problem, that makes my code work differently than the builtin re; it seems, in the character classes the ignorcase flag is ignored somehow: >>> regex.find

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I just tested the fix for unicode tracebacks and found some possibly weird results (not sure how/whether it should be fixed, as these inputs are indeed rather artificial...). (win XPp SP3 Czech, Python 2.6.4) Using the cmd console, the output is fine (for

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Thanks for the quick update, I confirm the fix for both issues; just another finding (while testing the behaviour mentioned previously - msg91917) The property name normalisation seem to be much more robust now, I just encountered an encoding error using a

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I'd like to add another issue I encountered with the latest version of regex - issue2636-20100204.zip It seems, that there is an error in handling some quantifiers in python 2.5 on Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Hi, thanks for the update! Just for the unlikely case, it hasn't been noticed sofar, using python 2.6.4 or 2.5.4 with the regexp build issue2636-20100204.zip I am getting the following easy-to-fix error: Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19)

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I'd like to add some detail to the previous msg91473 The current behaviour of the character properties looks a bit surprising sometimes: >>> >>> regex.findall(ur"\p{UppercaseLetter}", u"QW\p{UppercaseLetter}as") [u

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: Sorry for the dumb question, which may also suggest, that I'm unfortunately unable to contribute at this level (with zero knowledge of C and only "working" one for Python): Where can I find the sources for tests etc. and how they are ev

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: I'd like to confirm, that the above reported error is fixed in issue2636-20090810#2.zip While testing the new features a bit, I noticed some irregularity in handling the Unicode Character Properties; I tried randomly some of those mentioned at

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Vlastimil Brom added the comment: First, many thanks for this contribution; it's great, that the re module gets updated in that comprehensive way! I'd like to report some issue with the current version (issue2636-20090804.zip). Using an empty string as the search pattern ends up

[issue5274] sys.exc_info()[1] - different handling from str() and unicode() - py 2.6

Vlastimil Brom added the comment: I just want to confirm, that the reported issue is the same in python 2.6.2, is it really the intended behaviour in python 2.6 (as opposed to 2.5)? vbr -- components: +Unicode ___ Python tracker <h

[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)

Vlastimil Brom added the comment: I just wanted to confirm, that there isn't a bug in idle nor tk, but somwhere in my istalled fonts. Now while testing python 3.1a1, when I also have a font containing ẞ LATIN CAPITAL LETTER SHARP S (DejaVu), it's more clear. Printing this charact

[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)

Vlastimil Brom <[EMAIL PROTECTED]> added the comment: I can confirm, that TCL displays the same character as Idle, hence it itsn't a bug in Python (cf. the screenshot). Unfortunately, I couldn't identify the font used here; I'm not able to modify and recompile Tk, as sugg

[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)

Vlastimil Brom <[EMAIL PROTECTED]> added the comment: I'm aware, that it isn't an issue of unicodedata, it was just the way I came to try such a "modern" unicode character. I also see, that tk works pretty well in finding an appropriate font (e.g. compared to wx, wh

[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)

New submission from Vlastimil Brom <[EMAIL PROTECTED]>: While experimenting with the new unicodedata for version 5.1 (many thanks for it!) I discovered some strange behaviour of Idle with regard to a character not available in any font on my system, namely Latin capital letter sharp

[issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2

Vlastimil Brom <[EMAIL PROTECTED]> added the comment: While I am not sure about the status of this somewhat older issue, I just wanted to mention, that the behaviour remains the same in Python 3.0rc1 (XPh SP3, Czech) Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500

[issue3815] Python 3.0b3 - Idle doesn't start on win XPh

Vlastimil Brom <[EMAIL PROTECTED]> added the comment: Sorry for the noise, somehow my search in the bug tracker didn't show this report; after fixing the mentioned line in run.py everything works ok. ___ Python tracker <[EMAIL PRO

[issue3815] Python 3.0b3 - Idle doesn't start on win XPh

New submission from Vlastimil Brom <[EMAIL PROTECTED]>: Using Python 3.0b3 on windows XPH SP2 (installed form python-3.0b3.msi) Idle can't be started. Using a windows shortcut, only an error-promt is shown "Subprocess Startup Error: IDLE's subprocess dien't make conn

[issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2

Vlastimil Brom added the comment: First sorry about a delayed response, but moreover, I fear, preparing a patch would be far beyond my programming competence; sorry about that. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2

New submission from Vlastimil Brom: While testing the 3.0a2 build (on Win XPh SP2, Czech), I found a possible bug in the input() function; if the prompt text contains non-ascii characters (even those present in the default charset of the system locale - Czech in this case) the prompt is

[issue1110] Problems with the msi installer - python-3.0a1.msi

Vlastimil Brom added the comment: I just installed python-3.0a2 and it works fine for me (Win XPh SP2 Czech; python3 directory C:\Python30). Sofar I haven't found any problems other than those mentioned in the release notes. Thank you very much for fixing

[issue1110] Problems with the msi installer - python-3.0a1.msi

Vlastimil Brom added the comment: The path to the python executable on my system is: "C:\Python30\python.exe" The path to Program Files is "C:\Program Files", but it doesn't matter in that case, I guess. And yes, I use the console window (i.e. the cmd window in Win

[issue1110] Problems with the msi installer - python-3.0a1.msi

New submission from Vlastimil Brom: I encountered problems installing python 3.0 alpha 1 from the MSI installer supplied on the python download page (python-3.0a1.msi). If the advanced option of the installer ("compile .py files to bytecode after installation") is checked - the