\N{...} Unicode Charachter Name Expansion patch

[btutt]

BPO	400642
Nosy	@malemburg, @gvanrossum
Files	None: None

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/malemburg'
closed_at = <Date 2000-06-28.19:25:45.000>
created_at = <Date 2000-06-27.06:44:06.000>
labels = []
title = '\\N{...} Unicode Charachter Name Expansion patch'
updated_at = <Date 2000-06-28.19:25:45.000>
user = 'https://bugs.python.org/btutt'

bugs.python.org fields:

activity = <Date 2000-06-28.19:25:45.000>
actor = 'gvanrossum'
assignee = 'lemburg'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2000-06-27.06:44:06.000>
creator = 'btutt'
dependencies = []
files = ['2468']
hgrepos = []
issue_num = 400642
keywords = ['patch']
message_count = 7.0
messages = ['32849', '32850', '32851', '32852', '32853', '32854', '32855']
nosy_count = 3.0
nosy_names = ['lemburg', 'gvanrossum', 'btutt']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue400642'
versions = []

[btutt]

No description provided.

[gvanrossum]

(Note the raw patch is a binary file. tgz? zip? Who knows!)

[malemburg]

It's a ZIP file originally called ucn.zip

[btutt]

New patch. It is indeed ucn.zip.
Fixed:

• I think the inclusion of strnicmp will cause more compiler
  problems than do good -- why not simply inline the code in
  the one spot that needs it in unicodeobject.c ?
  Went back to the mystrnicmp approach.

• The typedefs in ucnhash.h should probably have the _Py_
  prefix to make it clear that the code is part of the
  Python dist.

Done, altered the generation scripts and regenerated ucnhash.h/.c and fixed up unicodeobject.c

[btutt]

Oops, uploaded wrong zip file, lets try this again.

[malemburg]

Patch checked in. Please close ! MAL.

[gvanrossum]

Thanks, Marc-Andre!