Ebcdic compliancy in stringobject source

[jymen]

BPO	557946
Nosy	@loewis
Files	pyconfig.h.in.diff stringobject.c.diff: using HAVE_EBCDIC define diff

^{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 = None
closed_at = <Date 2002-07-30.15:40:04.000>
created_at = <Date 2002-05-19.14:20:36.000>
labels = ['interpreter-core']
title = 'Ebcdic compliancy in stringobject source'
updated_at = <Date 2002-07-30.15:40:04.000>
user = 'https://bugs.python.org/jymen'

bugs.python.org fields:

activity = <Date 2002-07-30.15:40:04.000>
actor = 'jymen'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-05-19.14:20:36.000>
creator = 'jymen'
dependencies = []
files = ['4277', '4278']
hgrepos = []
issue_num = 557946
keywords = ['patch']
message_count = 10.0
messages = ['40044', '40045', '40046', '40047', '40048', '40049', '40050', '40051', '40052', '40053']
nosy_count = 3.0
nosy_names = ['loewis', 'jymen', 'coli']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue557946'
versions = ['Python 2.2']

[jymen]

the printable character set test made inside
strincgobject.c is not compliant with EBCDIC
systems(OS390 or OS400)

[loewis]

Logged In: YES
user_id=21627

Is it really worth fixing this? Python assumes that the
character set of byte strings is an ASCII superset in many
places. If there is any change made here, it should be based
on C library functions, rather than on static knowledge of
the operating system.

[jymen]

Logged In: YES
user_id=513881

when porting to OS390(EBCDIC os) , the only place I found
a bad ASCII asumption which leeds to further python's
startup interpreter troubles is the one pointed here. When I
fixed it I have been able to use the python interpreter kernel
without troubles.Some modules like xmllib may make some
ascii asumption but modules portability is a different story
since those modules may be declared non EBCDIC
compliant.

On the second topic using a C library function I am 100% ok 
the only question is that I am persuaded that using for 
instance the isascii XPG C function will generate more 
complex and slower code when trying to keep it in 
compliancy both with EBCDIC/ASCII targets. Having a more 
generic #define like :
#define EBCDIC inside the config.h set by ./configure when 
platform is EBCDIC is IMO the best compromise here.

[loewis]

Logged In: YES
user_id=21627

I believe there are a number of places where the code
assumes that 'a' .. 'z' covers all Latin letters, and only
those, e.g. pypcre.c, regexpr.c, sre.py.

[jymen]

Logged In: YES
user_id=513881

I am still 100% with you on that ,my only remark here is that
those are mainly either modules or py lib which are not part
of python basic kernel. And the idea here is to be able to get
a running minimal python kernel on an EBCDIC machine.

After that when the basic kernel is up in EBCDIC mode you'll
need to deal with some module/lib EBCDIC portability and
decide wether or not to adress them if you need to use
them.... But the important idea here is to have the python
kernel running in order not to be obliged to use REXX if
you're prefering python :=)

[jymen]

Logged In: YES
user_id=513881

The last attached diff files contains a more robust patch by
defining the HAVE_EBCDIC inside the pyconfig.h and using
this file inside the stringobject.c

[loewis]

Logged In: YES
user_id=21627

Modifying pyconfig.h.in (alone) is a mistake: this is a
generated file, edit configure.in instead.

When producing patches, please produce a single file
containing all changes (e.g. with diff -r); this makes
processing the patch simpler.

I'm still opposed to singling-out a specific encoding;
instead, I believe that the approach taken in patch bpo-479898
is more general and ought to solve your problem as well. Can
you please study this patch, and see whether you can make it
work on your system?

[jymen]

Logged In: YES
user_id=513881

I look at the approach taken in patch bpo-479898 , looks fine
so I
made a quick test on OS390 EBCDIC platform just extracting
the
SINGLE_BYTE isprint based changed which works fine on OS390
too.

It works well and is definitivelly the best approach for the
problem.

I looked also at the PRINT_MULTIBYTE_STRING approach based
on iswprint. Looking at IBM's doc it should also work for
OS390 EBCDIC too , allthough I am not able to test it on my
OS390 box.

[coli]

Logged In: YES
user_id=586691

This is an ugly patch,
The pcre module elegantly avoids this issue by using isprint(),
why not do the same thing here ?.

[jymen]

Logged In: YES
user_id=513881

The pcre module elegantly avoids this issue by using isprint
(), >
why not do the same thing here ?.

If you look at my answer dated 2002-06-02 , I indicated that
the isprint is definitively the best approach to the problem , I
made a test with it on OS390 and it works fine.